Hacker News Reader

Also, when you do use Redux, as in your nesting example don't pass props through components that don't have any need for them except they propagate the prop to someone else. It's absolutely fine to connect() a component deeper in the hierarchy. Passing everything down is an anti-pattern with Redux, separation of concerns still applies and the props of a component defines the API, don't clutter that API with unrelated things.

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.

Yep, absolutely. See the Redux FAQ entry on "connecting multiple components" for more info [0] . I also discussed how connecting more components affects performance in my blog post "Practical Redux, Part 6 - Connected Lists, Forms, and Performance" [1], and there's many additional articles that discuss connected components and performance concerns as well [2].

[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...

I don't agree with the view that a component doesn't need a prop "itself" if it "only" passes it on to a child component. That child component is a part of the parent. If one decided that e.g. the child is too simple to warrant to be its own component and inlined its render() content in the parent instead, suddenly its used props would be needed by the parent "itself".

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

If was my understanding that if a component has a prop which changes, even if that prop is passed down the tree, the component will still update.

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.

I partially blame every tutorial and contrived example of how you should use Redux. When first starting with React & Redux I spent some time thinking of where and how I should use Redux.

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.

I try to keep it as simple as possible.

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

> I partially blame every tutorial and contrived example of how you should use Redux.

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?

He he true.

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.

Wanting to do fancy stuff for a side project is understandable. I'd prefer my team do that, so they can learn new stuff - and only bring the techniques/tools that actually work to paid projects.

For what it's worth, my links list has a very large section of articles on Redux architecture and best practices: https://github.com/markerikson/react-redux-links/blob/master... . Mapbox's post on "Redux for state management in large web apps" is particularly good: https://www.mapbox.com/blog/redux-for-state-management-in-la... .

I've been doing React for a while now and I've ended up with the same structure: 2 main folders.

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.

In this kind of setup, I'm wondering how you handle events that happen outside of the component?

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?

You have a root component. Run the interval within that component where you have access to state.

That's essentially redux: root state.

If that was "essentially redux", redux would have no reason for existence.

Except for the fact that it drastically lowers the amount of manual props passing you have to do, and allows you to achieve much better separation of concerns. It is essentially Redux, only much worse the more complex your app is.

> It is essentially Redux, only much worse the more complex your app is.

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

The entire Redux library is something like 300 lines of code, most of which is sanity checks. It is basically the same thing as having one root component handle all your state, it just adds a tiny bit of magic for convenience. If you're comparing that to using a completely different language, I encourage you to learn more about how Redux actually works, because it's really very simple.

It literally IS having a root component manage state. That's what the Provider class does (enables connect() to populate via a Redux store in context).

I understand Redux, have used it many times and have read the source code. I don't understand the argument that it is "basically is the same thing as having a root component handle all your state".

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.

Actions, the dispatcher, and reducers are effectively a few in/out functions around a thing stuffed into the React context when used by react-redux. You're way overstating things.

And if it's in a module outside the component tree?

As I said, my approach isn't a one size fits 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.

That approach may minimize props passing, but it also is going to cut down on chances to use `shouldComponentUpdate` to avoid unnecessary re-renders and improve performance. Depending on your app, that might not be an issue, but it's something to be aware of.

It's exactly the opposite. You want to make your props as specific to the component as possible to minimize re-renders and pass-through of props causes unnecessary work.

<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.

I think we're sorta saying the same thing, but in different ways.

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.

better yet - don't create functions, especially inside a loop, in your render function,

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

...

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

How will you solve two components deep down different branches that share state?

for shared state I used localStorage/AsyncStorage and added an event emitter to it.

What about scenarios where that's unavailable? E.g. Safari in private browsing mode?

I use them for persistence, so state is kept between visits.

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