This. I've been using React for the past 6 months or so to develop a hybrid app. Our team went with a hooks and context approach. We've found that Context API absolutely murders our component tree with re-renders. The whole idea of "use this so you can avoid prop drilling" gets completely thrown out as the only way to avoid unnecessary re-renders is to pass down props...
In the end I ended up adding redux just for a small portion of the app which rendered a big list.
Im not even a big fan of redux. The great thing about redux is react-redux which works out the selective rendering.
Writing yourself selective rendering is completely doable but maybe a daunting task. At that point the use of state management libraries is interesting since they have a lot of it figured out for you. The complexity of learning/using a state management lib pays of the complexity of writing yourself selective rendering.
Again, that doesnt mean that the state management lib has to be used in the entire applicationm, but at list in the sensitive parts.
PS: In angular contexts are dead simple. I miss viewProviders in react.
I don't have much experience with Angular (except AngularJS - shudder), but before this React project I used Vue for a few years with Vuex and never ran into such issues. Sure it required more wiring, but it was reliable and did exactly as state management should; give you the current state without any side effects.
I'd say selective rendering with contexts is painful bc a context will always rerender all of its consumers if the reference of the value passed to Provider changes (=== comparison).
So, for instance, passing an object built on every render will certainly trigger a mass re-render.
To fix this one has to break the data into multiple context providers.
If you inspect a redux application (with react dev tools) you may notice DOZENS of context consumers generated by the library wrapping an element.
I'd say selective rendering with contexts is painful bc a context will always rerender all of its consumers if the reference of the value passed to Provider changes (=== comparison).
Exactly right. It's the side effects of something updating in a context and that waterfall effect that makes them so painful.
Appreciate your concern. I understand where you are coming from.
Yes, I pointed out that passing down prop when we have few layers of component in-between is best. And that is the case of the Todos app used in this tutorial.
But there are scenarios where the Context is better. In the case where many deeply nested components need access to global data.
The focus here is how we can use the context API to retrieve data in these "nested components".
Again, thanks man for pointing that out.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Mindlessly using the context API without caring about the whole application re-rendering is fun.
Caring a bit about more selective re-renders - with the context API - is painful.
This. I've been using React for the past 6 months or so to develop a hybrid app. Our team went with a hooks and context approach. We've found that Context API absolutely murders our component tree with re-renders. The whole idea of "use this so you can avoid prop drilling" gets completely thrown out as the only way to avoid unnecessary re-renders is to pass down props...
Yeah, I also came to that.
In the end I ended up adding redux just for a small portion of the app which rendered a big list.
Im not even a big fan of redux. The great thing about redux is react-redux which works out the selective rendering.
Writing yourself selective rendering is completely doable but maybe a daunting task. At that point the use of state management libraries is interesting since they have a lot of it figured out for you. The complexity of learning/using a state management lib pays of the complexity of writing yourself selective rendering.
Again, that doesnt mean that the state management lib has to be used in the entire applicationm, but at list in the sensitive parts.
PS: In angular contexts are dead simple. I miss viewProviders in react.
I don't have much experience with Angular (except AngularJS - shudder), but before this React project I used Vue for a few years with Vuex and never ran into such issues. Sure it required more wiring, but it was reliable and did exactly as state management should; give you the current state without any side effects.
I'd say selective rendering with contexts is painful bc a context will always rerender all of its consumers if the reference of the value passed to Provider changes (=== comparison).
So, for instance, passing an object built on every render will certainly trigger a mass re-render.
To fix this one has to break the data into multiple context providers.
If you inspect a redux application (with react dev tools) you may notice DOZENS of context consumers generated by the library wrapping an element.
Exactly right. It's the side effects of something updating in a context and that waterfall effect that makes them so painful.
Hi Willian!
Appreciate your concern. I understand where you are coming from.
Yes, I pointed out that passing down prop when we have few layers of component in-between is best. And that is the case of the Todos app used in this tutorial.
But there are scenarios where the Context is better. In the case where many deeply nested components need access to global data.
The focus here is how we can use the context API to retrieve data in these "nested components".
Again, thanks man for pointing that out.