I agree. And that kinda brings us full circle back to the original point of this particular post. The typical flow seems to go like this:
Team wants to share state.
Team creates global store.
Team starts to realize all the headaches of unplanned use.
Team starts bolting a ton of extra controls on top of the global store to avoid these headaches.
The team's code is now a Frankensteined aberration of what they originally set out to build.
But this is why I'm excited about the Context API. By using that, you can keep full control of that value in its original component. No need to route all changes through a series of actions or reducers. In other words, you can let React's native setState() handle all state updates - just as it was originally designed to do.
It is true that, with the Context API, those value do have to be "exposed". But that should usually be quite painless. In the case of state variables, if you're passing all of state into the ContextProvider's value, there's no need to worry about making future state variables accessible. It's already done.
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.
I agree. And that kinda brings us full circle back to the original point of this particular post. The typical flow seems to go like this:
But this is why I'm excited about the Context API. By using that, you can keep full control of that value in its original component. No need to route all changes through a series of actions or reducers. In other words, you can let React's native
setState()handle all state updates - just as it was originally designed to do.It is true that, with the Context API, those value do have to be "exposed". But that should usually be quite painless. In the case of state variables, if you're passing all of
stateinto the ContextProvider'svalue, there's no need to worry about making futurestatevariables accessible. It's already done.