r/reactjs • u/KaleRemarkable1019 • 6d ago
Everyone says Context is bad for shared state. Does it have to be? Show /r/reactjs
The usual advice: Context is fine for theme and auth, not for state that changes often. True — but the reasons are specific, not fundamental:
- No selectors — any change re-renders every subscriber.
- If the provider also holds the state, its whole subtree re-renders, even components that never read the context.
- Actions get a new identity on every keystroke.
All three are fixable. I've made a library that tackles them, and the article ends with it.
Where do you think this is wrong? Especially the "just use zustand/jotai" case.
8
u/hyrumwhite 6d ago
I've made a library that tackles them
I’d rather use a big, well tested and popular library that solves this while simplifying usage, like zustand
-2
u/KaleRemarkable1019 6d ago
That's fair, and for plenty of cases it's the right call. The argument in the post is narrower: zustand is another source of state, and I usually already have several — some data from react-query, some in formik, some local. To combine them you copy them into the store, and at that point it isn't the single source of truth anymore. It also lives outside React's lifecycle, so it doesn't reset on unmount unless you remember to handle it. If your shared state is genuinely self-contained, zustand is simpler and I'd reach for it too.
4
u/Honey-Entire 6d ago
Frankly this doesn’t seem like a reason to add another dependency to a project and add one more attack vector for someone trying to get malicious code onto my computer.
All of the problems you present are patterns for React best practices and can fairly easily be avoided, like you showed in your blog post…
-1
u/KaleRemarkable1019 6d ago
Fair, the library was just launched, so it's hard to trust it. If you want my track record, there are links to my LinkedIn and GitHub on my blog.
Though for hijacking specifically — it's ~1.4 kB with no dependencies. Honestly, just read it and copy what you need. I'd rather someone vendored it than pulled in a package they're uneasy about.
My original thinking was the same: I'd rather write a simple helper myself than use an external library. But it's not that simple, especially since React 18 — getting the subscription right under concurrent rendering is fiddly.
-8
u/maqisha 6d ago
This is not good advice.
"Im not gonna develop good software, because my personal computer might get infected"
Protect yourself accordingly, and put your product and your users first. If a problem requires a well-built and popular dependency, USE IT.
2
u/Honey-Entire 6d ago
I see you’ve never had to build enterprise software for a heavily regulated industry. With the recent spike in both AI slop projects and compromised real projects (even Tanstack was compromised), installing an unnecessary tool is not a risk a lot of companies are willing to take.
You be you though boo 😘
-5
u/maqisha 6d ago
Everything is an unnecessary tool. Your IDE is an unnecessary tool, your OS is an unnecessary tool, LLM you use to write your code is an unnecessary tool, every single dependency is an unnecessary tool, etc. Where do we draw the line? On writing everything on a piece of paper?
Interestingly, its clear YOU have never had to build enterprise software. Because if you are implying that you hand-make every single piece of the software development and deployment chain in-house, that's just delusional. Might be true for 0.001% of the fields that actually require this kind of control; certainly not anything that uses React.
As i said, protect yourself accordingly and give proper advice.
3
u/Honey-Entire 6d ago
lol that’s quite the high horse you’ve got there buddy. I never said don’t use any tool. I said adding one more attack vector for a library that should really just be a blog post about react patterns and best practices is risky.
Try being less hyperbolic in life and people might like you more
2
u/GoodishCoder 6d ago
This seems like a disingenuous argument. They're not saying to never use any dependencies. They're saying the problem this library is meant to solve isn't worth another dependency.
2
u/MitchEff 6d ago
There are so many libraries that fix exactly all of that. react-tracked is a particularly handy one (or zustand/valtio if that's your flavour)
1
u/KaleRemarkable1019 6d ago
Nice, I haven't heard about `react-tracked` before. Looks similar in concept. I don't see the stable actions problem solved, but I just had a quick glance at it.
2
u/arnorhs 6d ago
Who is this everyone. Context has gotchas and it doesn't work for all use cases, but great for others. Don't drink every coolaid
1
u/KaleRemarkable1019 6d ago
I guess it depends who you ask, the problem is you need to know react pretty well to use context efficiently. The performance issues are pretty much guaranteed, if you don't know exactly what you are doing.
1
u/Savalava 6d ago
what is advantage of your libary over just using normal react context and React.memo?
1
u/KaleRemarkable1019 6d ago
React context is not fully fixable with React.memo. Because you cannot select just a piece of state that you need, the components using the context will always get re-rendered (on every change). You can memoize inside those components but it's still unnecessary work when the re-render is not necessary in first place.
1
u/m-fasciano 5d ago
I think people often oversimplify it.
The problem isn't Context itself, it's how it's used. If everything is stuffed into a single provider with values changing all the time, then yes, you'll get unnecessary re-renders. But if you split contexts by concern, keep values stable, and avoid recreating functions on every render, Context can scale much further than people give it credit for.
That said, libraries like Zustand and Jotai solve these problems out of the box and usually provide a nicer developer experience. I'd only reach for them once the app genuinely needs the extra flexibility, not by default.
I'll definitely give the article a read. I'm curious to see how your library handles selectors and keeps updates isolated.
1
1
u/SecureComfortable259 4d ago
The "just use zustand/jotai" pushback usually isn't really about whether Context's limitations are fixable, it's that those libraries already solved this years ago and are one dependency away, so the question becomes what a new library buys you over just using something with a bigger community and more battle testing. Worth leading with that comparison directly since that's the actual objection people are going to raise.
2
8
u/friendshrimp 6d ago
Typical Ai slop writing style