Redux: Where is "happy medium" between smart components and dumb components?

Created on 19 Apr 2016 · 3Comments · Source: reduxjs/redux

I've been watching Dan's Redux tutorials on egghead and remember one advice that if parent component doesn't use some data but need it just to pass to children - don't do it. Use connect over child component that need this data.

I like this advice because I hate passing tons of data through props. I thought this is commonly used approach but recently I was implementing "mini twitter" project as test assignment to the company which use redux in its project and that's why I want to work there.

But my code was rejected since "React-way is too have maximum of dumb components". Is that true?
Here is my code if someone want to take a look https://bitbucket.org/amorphius/minitwitter/overview
So, the reason it was recognized as bad code is that there are too many connect's in the code.

Where is happy medium?

question

Source

amorphius

Most helpful comment

We used to say that having less connected components is better in the earlier versions of docs but I didn’t anticipate how much of a cargo cult that would become. 😞 Yes, connecting every component is often an overkill, but so is putting everything at the top! Connecting just for the sake of getting dispatch is especially harmless so you shouldn’t feel bad about doing this often.

Your code looks absolutely fine to me. 👍

gaearon on 19 Apr 2016

👍4 ❤3

All 3 comments

Your code looks absolutely fine to me. 👍

gaearon on 19 Apr 2016

👍4 ❤3

Thank you. At least I have now strong argument that my code is fine and probably get job in better company :)

But still I can't imaging scenario where connect is overkill. How to develop this skill to know which rule I have to break either pass data from parent control that does not use this data to child control or to have another connect in the code (especially if it reads small chunk of data from the store)?

What kind of problems will arise with many connect's in the app?

amorphius on 19 Apr 2016

Redux's subscriber notification process is a simple loop that runs every subscriber callback, so that's obviously O(n). In theory, if subscriber callbacks are doing something complex, or if the number of subscribers grows _very_ large, that could become a performance issue.

In practice, it's probably not much of a concern. I suspect you'd have to have several thousand active subscriptions, with many actions dispatching a second, before it would realistically become a problem. I don't know of any specific benchmarks at the moment that I could point to to verify that, though (unless maybe the recent MobX/Redux comparison would relate).

Overall, I think you should be safe following the classic "make it work, make it right, make it fast" approach. Write code that makes your application's features work properly. Look at what you've written and adjust the structure if needed so it makes more sense. If it seems slow, measure and benchmark, and fix the parts that are actually slow.