My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.
This is why integrations for Redux and MobX place a reference to a static value (i.e. it doesn't change during the entire lifetime of the application) that enables components to subscribe to update notifications inside the context. The subscription also allows components to select/filter update notifications to those that are actually relevant to that component's state - avoiding unnecessary renders.
(Given that a state value is exposed via a provider there is a good chance that some components are only interested in part of that state value - so ideally those components would only want to re-render if the relevant part of the state value has been updated.)
So while placing state values in a context seemingly "just works" in small applications, performance problems can manifest themselves when the shared values are updated too frequently and/or once the application becomes large enough so that too many components are re-rendered whenever the context value is updated.
👋 I enjoy programming in JavaScript. My industry experience is in Angular and Ionic Framework. I teach fundamentals of JavaScript and front-end frameworks in Oslo.
P.S. I love hamburgers. 🍔
I wholeheartedly agree with everything you’ve said here. Personally, I also believe that Context is NOT a state management tool. As the blog post also mentions, Context is a form of DI and state is managed by the code being written by the developer.
The goal of this experiment was mainly to learn more about the ContextAPI, I think that was mentioned in the previous article where I made a bit of a mess of the code.
I’ve read the post you’ve share and it was super helpful to better understand the difference between context and tools like Redux.
👋 I enjoy programming in JavaScript. My industry experience is in Angular and Ionic Framework. I teach fundamentals of JavaScript and front-end frameworks in Oslo.
P.S. I love hamburgers. 🍔
Reading the post again, I’ve actually come to a very similar convulsion in the original referenced article linked at the top of this one. But I think mine might have been a bit unclear in the last conclusion that I don’t believe context should be used as a state management tool.
I’ll update this later this weekend to give more clarity. Thanks for the help.
On a side note, I much prefer the way Vue/Vuex works, and find it hard to adapt to the react way of immutable values. 🤷♀️
Coming from Angular that isn't too surprising and lots of people find Vue's reactivity more natural. In the React ecosystem MobX/Valtio fill that niche.
👋 I enjoy programming in JavaScript. My industry experience is in Angular and Ionic Framework. I teach fundamentals of JavaScript and front-end frameworks in Oslo.
P.S. I love hamburgers. 🍔
From Sebastian Markbåge:
This is why integrations for Redux and MobX place a reference to a static value (i.e. it doesn't change during the entire lifetime of the application) that enables components to subscribe to update notifications inside the context. The subscription also allows components to select/filter update notifications to those that are actually relevant to that component's state - avoiding unnecessary renders.
(Given that a state value is exposed via a provider there is a good chance that some components are only interested in part of that state value - so ideally those components would only want to re-render if the relevant part of the state value has been updated.)
So while placing state values in a context seemingly "just works" in small applications, performance problems can manifest themselves when the shared values are updated too frequently and/or once the application becomes large enough so that too many components are re-rendered whenever the context value is updated.
For more details see: Why React Context is Not a "State Management" Tool.
I wholeheartedly agree with everything you’ve said here. Personally, I also believe that Context is NOT a state management tool. As the blog post also mentions, Context is a form of DI and state is managed by the code being written by the developer.
The goal of this experiment was mainly to learn more about the ContextAPI, I think that was mentioned in the previous article where I made a bit of a mess of the code.
I’ve read the post you’ve share and it was super helpful to better understand the difference between context and tools like Redux.
Thank you very much 🙏
Edit: Typos
Reading the post again, I’ve actually come to a very similar convulsion in the original referenced article linked at the top of this one. But I think mine might have been a bit unclear in the last conclusion that I don’t believe context should be used as a state management tool.
I’ll update this later this weekend to give more clarity. Thanks for the help.
On a side note, I much prefer the way Vue/Vuex works, and find it hard to adapt to the react way of immutable values. 🤷♀️
Coming from Angular that isn't too surprising and lots of people find Vue's reactivity more natural. In the React ecosystem MobX/Valtio fill that niche.
I recently discovered Redux Toolkit and I think I’m in love 🥰