This way view state is kept outside of my global store, my UI component and its state controller is fully composable and extractable (meaning more reusable), and any other UI element within the same context can view and update my UI component as it pleases.

Another great thing about this is that you can scope your view state (or context) however you want. You can put it on the page level, the app level, or really wherever you want. You don't have to worry about cleaning up or resetting state because the context provider will be unmounted when the user navigates away (unlike a redux store).

Now, if any components you build in the future also need access to P's state, you can easily implement it as a new pure component that is a descendant of P. Since it has access to the callbacks, it will be able to update our original component C by invoking them.

With this setup, your app is basically separated into two "classes" of components, providers and consumers. Each provider holds the state and callbacks specific to itself only, which means you can easily pull out an individual provider and consumer to reuse in a new place (instead of being dependent on a global store).

The biggest benefit here is that future components can interact with P and by extension C without changing any code in P or C. Furthermore, if you want two parallel widgets with independent state, you can just create two instances of P as siblings, with C as descendants of both of them. If you wanted to do the same with a global store, you would most likely have to update your implementation to support parallel state tracking.

Another benefit is that you don't have to "clean up" the state when P is discarded. For example, if you are using a global store, and you navigate to a new page, you have to implement a callback to clear the widget state from the global store or risk loading stale state when the user navigates back. With this approach, since P has been removed from the tree, its state will be discarded along with it.

The only stuff I put in my global store is stuff that is actually relevant to my entire application. For example the user's username and preferences.

I'm not advocating for any ground breaking paradigms here, I guess my only point is that the common advice to just throw everything into Redux (global store) is bad advice. You should only put global state into your global store. The common alternative is to silo state and functionality/UI into one component. I'd argue the third alternative, taking the best of both worlds, enables far more productivity. Basically creating mini-Redux stores that are only focused on one bit of user interaction. These are far more reusable, and since they're scoped locally they eliminate a lot of edge cases (and they're composable!).

Imagine you have a React tree with a 100 node depth. You would then need to walk all the way up those 100 nodes, but using the context api you can put in context consumer at the branches of your tree where it makes sense, so instead of walking up 100 nodes you walk up 3 nodes to input into the global context.

Hope that is a reasonable high level explanation of a thing that can be complicated without experience of it.

Very true. My interpretation of the article was that it refers to "core data only". If you re-read the article as "How storing core data in a structure that is coupled to the UI increases accidental complexity" then I think you'll find it more agreeable.

Personally I throw stuff like popup state into local component state and the global important stuff into redux. Perhaps the author implicitly assumes that everybody does this.

Here's one I've run into: say you have a list of things that can be edited and then when you click "Save" it saves them all to the server. Each of those would need to track a "saving" state to drive its loading spinner. That saving state is transient and UI-specific, and it is tied to each instance of a list item in some sense, but it can't just be local to the list-item component because it needs to be a) set as part of global app logic, and b) read by, for example, the "save" button so it knows when you're allowed to click it again.

There's an entire spectrum of these gray cases and there's no single answer for "how far up to hoist things". You're always making compromises. This is one reason I prefer MobX over Redux, because the latter basically locks you into "global state" and "local state" and doesn't allow for a lot of in-betweens.

The dropdown would act in the same way, no? It mostly sets some local state, and your can then derive the data you need from the store (let’s say the drop down was just an on/off filter). But yes, you are right, you would need to think about a way to abstract this out as a data flag and not a ui state flag.

I frankly think that this complexity is not accidental. It is the real complexity of the UI, which is often not realized. All the little things that need thought and, at least once, an implementation.

HTML event-listeners like on-blur, on-focus, on-click, etc. handle this very nicely. I've found that they're frequently disregarded in component libraries, unfortunately.

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...