About the connect function: I fully agree that no harm is done by this function in and on itself. It's a nice way of separating the "dumb" UI code that does nothing else than the rendering from the logic that connects the UI with the store, that's perfectly fine. The issue lies within the fact that the connected component has an additional source of information (the store). If you have a junior developer using your component, they might not be aware of this fact.
In 99% of all cases, it simply doesn't even matter, I give you that. It's mostly an "academic" concern. However, the moment you employ connected components in your application, you absolutely should not use shouldComponentUpdate anymore. The reason for that is that you can never be sure which child components your component at hand will have in the future. Today, your child components might be "dumb" react renderers (stateless components in the ideal case). However, tomorrow, in the third nesting level, someone might sneak in a connected component. From that point onward, your shouldComponentUpdate function will potentially prevent an update that was actually needed by a child. This introduces very subtle bugs that are extremely hard to detect by the developers because they seemingly occur "at random". At least that's what your users will tell you: "Sometimes this thing here doesn't update". And good luck in figuring that out. If you use react-redux, every time you implement shouldComponentUpdate, you make the implicit (and very strong) assumption that all your children, now and forever, will be pure, non-connected components. There is no way to enforce that in the react API, and somebody eventually WILL break this assumption. Maybe you yourself because you haven't touched this code in a long time, or maybe the junior dev next to you, but somebody will. From the point of view of that person, they don't do anything "illegal", they just attach another component to a parent component.
So, why bother, if you can just skip shouldComponentUpdate? Well, because it's a very important tool for optimizing react apps. React is fast in rendering, no doubt about it. However, if you are writing really large applications where a react component tree consists of hundreds or thousands of components, you will eventually need to optimize it, and you lose this very important tool.
I'm writing react-redux apps myself. It's not a deal-breaker. But it is something that we as react devs absolutely need to keep in mind. It is a problem, and I'm not sure if there is a solution to this at all.
Hi!
About the
connectfunction: I fully agree that no harm is done by this function in and on itself. It's a nice way of separating the "dumb" UI code that does nothing else than the rendering from the logic that connects the UI with the store, that's perfectly fine. The issue lies within the fact that the connected component has an additional source of information (the store). If you have a junior developer using your component, they might not be aware of this fact.In 99% of all cases, it simply doesn't even matter, I give you that. It's mostly an "academic" concern. However, the moment you employ connected components in your application, you absolutely should not use
shouldComponentUpdateanymore. The reason for that is that you can never be sure which child components your component at hand will have in the future. Today, your child components might be "dumb" react renderers (stateless components in the ideal case). However, tomorrow, in the third nesting level, someone might sneak in a connected component. From that point onward, yourshouldComponentUpdatefunction will potentially prevent an update that was actually needed by a child. This introduces very subtle bugs that are extremely hard to detect by the developers because they seemingly occur "at random". At least that's what your users will tell you: "Sometimes this thing here doesn't update". And good luck in figuring that out. If you use react-redux, every time you implementshouldComponentUpdate, you make the implicit (and very strong) assumption that all your children, now and forever, will be pure, non-connected components. There is no way to enforce that in the react API, and somebody eventually WILL break this assumption. Maybe you yourself because you haven't touched this code in a long time, or maybe the junior dev next to you, but somebody will. From the point of view of that person, they don't do anything "illegal", they just attach another component to a parent component.So, why bother, if you can just skip
shouldComponentUpdate? Well, because it's a very important tool for optimizing react apps. React is fast in rendering, no doubt about it. However, if you are writing really large applications where a react component tree consists of hundreds or thousands of components, you will eventually need to optimize it, and you lose this very important tool.I'm writing react-redux apps myself. It's not a deal-breaker. But it is something that we as react devs absolutely need to keep in mind. It is a problem, and I'm not sure if there is a solution to this at all.
I think those are good points. There are always trade offs.