view raw
Yaniv Efraim Yaniv Efraim - 1 year ago 70
Javascript Question

Redux - Component different approaches (Smart / Dumb / Container / Presentation)

So, I know that there is no one 'correct' approach to this, but I wanted to have a conversation about the pros and cons of each approach.

So, After reading Dan Abramov's post and comment, and going over this tutorial, I wonder the pros and cons for those two different approaches:

Approach A:

├── Smart / Container component
│ ├── Dumb / presentation component
│ │ ├── Dumb / presentation component
│ ├── Dumb / presentation component

Aproach B:

├── Smart / Container component
│ ├── Dumb / presentation component
│ │ ├── Smart / Container component
│ ├── Dumb / presentation component

The main difference here is how you manage your state. In option B the deepest component should be aware of redux (dispach, for example), which can be a disadvantage. In approach A you might need to pass props down the tree between many Dumb components.


A strange thing is that in Redux docs, on "Passing the Store" section, you can find a reference to the "magic" behind "Provider" (react context). In context docs it is clearly says:

Just as global variables are best avoided when writing clear code, you
should avoid using context in most cases


Before you build components with this API, consider if there are
cleaner alternatives. We're fond of simply passing the items as an
array in cases like this

So, as far as I can understand it is some kind of bad practice?? (Option B...)


It becomes a question of readability and re-rendering performance. Sometimes it may be more readable to explicitly pass down props through a couple levels. Other times it may be easier to understand if you start a new connection and pull in the data you need right there. Also, note that connect() does a lot of work to make sure that your own component only re-renders when it really has to, so you can actually get some potential performance improvements when a component is connected. In contrast, "dumb" components often do not implement shouldComponentUpdate, meaning they will re-render every time.

As you said, there is no single right answer - use connect() wherever it makes sense for your own application structure.


To answer your question about the React Context docs, React-Redux's <Provider> component specifically encapsulates the fact that it happens to use Context. That way, if there are any changes to the Context API or behavior in the future, your own app shouldn't have to worry about it, as it can be taken care of by updates to Provider.

In other words, don't worry about it :)