What we do use: - plain old React context - @tanstack.com query Having used React context at scale… I have to say the react team was cooking once again. Yet another case of weird ergonomics pushing you to work in a good way. Hoisting state to context being a bit of a PITA is a feature, not a bug!

Adding more and more to an enormous app means by and large, stuff gets implemented in the lowest friction way. This is where composition shines. You want state to be as local as humanly possible, so it doesn’t get everywhere.

Global state managers on the other hand have the opposite effect. The lowest friction path becomes making your stuff global. This does not scale well at all, and becomes increasingly incomprehensible.

The key with using Context correctly is to only put one thing in them at a time. Got two things? Use two contexts. The danger zone is when you start putting large bundles of stuff in there, like you would a global state manager. This is obviously gonna make your whole app rerender.

My heuristic is to only bundle stuff into an object when it’s stuff that isn’t gonna change: functions, for example. We have a useNonReactiveCallback hook which is great for this. This means you’re not gonna cause a rerender.

Then if you’ve got values that might change, put em in their own context. This means they won’t trigger rerenders of anything that doesn’t need them. I messed this up recently: the controls that opens the dialogs has the functions in an object from context. The mistake was I got lazy and needed…

to also pass down an internal value to another component, so I stuck it in the same object. This value changes every time you open a dialog, so even though it’s only *used* in one place it gets *consumed* in many many places, triggering unnecessary renders. This is such an easy fix: just move it out

Conclusion: react context is good actually and pushes you towards good code. You just need a bit of hygiene when using them: mostly just avoid bundling stuff together! pro tip: add a displayName to your contexts so you can tell wtf is happening in your profiler

is it a footgun? sorta. but with react context, it's usually a case of "you're holding it wrong". with global state managers, it's impossible to *not* hold it wrong. don't make stuff global!

so if i understood this right, the idea is to keep state local to each "component"? by component i don't necessarily mean the actual `.tsx` file, but just the particular module or something. i'm still figuring out frontend lol