Components only receiving props that they themselves need has kept things clean in our massive codebase, and allows you to effortlessly move things about and easily re-use components wherever it makes sense.

[0] http://redux.js.org/docs/faq/ReactRedux.html#react-multiple-...

[1] http://blog.isquaredsoftware.com/2017/01/practical-redux-par...

[2] https://github.com/markerikson/react-redux-links/blob/master...

Another thing to consider is that one tightly couples components to stores when connecting. So reusability of these components is hampered.

This is one way I use redux, the connector watches for changes in state and then updates the component directly, rather than passing props down the tree.

Being that I was new to both, I didn't have any ingrained best practices, and it was hard to find any best practices around when to use redux.

Every example seemed to use it for everything, which seemed insane to me in a real web app. I could see that the size and clutter would grow terribly, and for no obvious benefit.

Your example above is similar to how many component libraries work (where you need to give the user flexibility).

In a dashboard app, I'll make good use of Redux because there are often sets of data you revisit in different ways.

In a more directory-like site I've recently built I use it to keep track of the logged in user information and high level information that dictates your experience (like user location), but nothing else.

Partially? No. The culture of side projects/GitHub/blog post had led people to over engineer their learning materials and side projects to look as employable as possible. Why make a todo list with just React when you can use Redux in it too and put it in your resume?

When I do a side project I often want to do fancy stuff and blog about it.

When I get paid for my work, I try to keep it simple, because I fear I could end up with too much intermingled stuff I won't understand anymore after a few months.

But for complex dashboards I would probably use some observable based solution.

One of them in the base components, which are in folders grouped by their corresponding REST service endpoint (so if you have 'Foo' and 'Bar' db tables, and API's, then I have 'Foo' and 'Bar' folders inside my 'components' folder.

The other folder is my views. It's more of the integration layer for all of my components. Since views typically correspond to a page route, that's where most of my react-router stuff is. It also is where I call the react-redux 'connect' HOC, to get data that is fed down into the components.

So far it's working pretty well for me. I think it works great for a medium-size type of app.

Let's say you have a background function, created with setTimeInterval, which after some time update an item. With Redux, you could dispatch an action UPDATE_ITEM, which would modify the items, and in turn update the connected component.

However, without Redux how is your component going to know about this item update and update the list? Do you use some kind of event listener/dispatcher?

so... not at all like Redux then. C# is essentially Python except it has different syntax and static typing.

It's that plus actions, reducers, dispatcher, middleware, and HoCs for connecting components to global state. So it's not basically the same thing at all.

At the moment I do React-Native projects, where every app is self contained. On the Web you often have more mashup.

But the approach still works for most Web UIs too, just not for all.

<List items={items} /> will re-render (or at least completely unnecessarily re-evaluate shouldComponentUpdate) the List itself whenever any item has changed.

<Item item={i} /> with a shouldComponentUpdate or better yet React.PureComponent will only re-render the single changed item.

If you have that separate `<List>` parent component, you can apply `sCU` there so that it only re-renders when some of the items have changed, and not when other parts of the application update.

If you don't have the `<List>`, the parent component will always re-render and always at least start the render lifecycle process for the `<Item>` components, but they can also implement `sCU` to skip the actual re-render.

The most optimized approach is to have normalized data in Redux. The parent component should retrieve an array of item IDs in its `mapState` so that it only re-renders when an item is added, removed, or reordered, and render children like `<Item id={itemId} />`. The `Item` components should be connected as well, and use their `mapState` functions to look up the corresponding item from the Redux state by ID. That way _they_ will only re-render when their specific item has changed.

getItem = i => <Item item={i}/>

...

<List> {items.map(getItem)} </List>

But in private mode I'd simply use an object as key-value-store.