Thanks for that article. It explains the usage of the context API quite good, BUT...
In my opinion it is a bad practise. And I'll tell why: All components consuming a context provides will re-render if the value of the context changes. Quote from react documentation:
All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes.
This is why one global state is not recommended and context API is better suited for state which is not changing frequently (theme, localization, auth...). If you use context API you should split the context. See this comment of the redux co-author.
Maybe now you're asking yourself: What is the difference between using context API and redux (also using context API). As the maintainer @markerikson
has recently written on his blog it is a common misconception that redux is just some kind of a wrapper around the context API.
tl;dr
Do not use a single global context for state management.
Thanks for that article. It explains the usage of the context API quite good, BUT...
In my opinion it is a bad practise. And I'll tell why: All components consuming a context provides will re-render if the value of the context changes. Quote from react documentation:
This is why one global state is not recommended and context API is better suited for state which is not changing frequently (theme, localization, auth...). If you use context API you should split the context. See this comment of the redux co-author.
Maybe now you're asking yourself: What is the difference between using context API and redux (also using context API). As the maintainer @markerikson has recently written on his blog it is a common misconception that redux is just some kind of a wrapper around the context API.
tl;dr
Do not use a single global context for state management.
Thanks for pointing this out. I'll update the post with the performance implications.