Hacker News Reader

Comment by Waterluvian | Hacker News Reader

I'm starting to lean towards holding ALL app state in a single store rather than having component local state because every so often I get burned by not seeing the future.

Example: okay I have a bunch of tabs that show different views. The state for which tab is selected can live with the tab container. Months later I find that I need other parts of the app to be able to switch to a different tab when user actions happen.

At this stage all I put in local state are the most basic things like dropdown open/closed state.

View on HN

If you're looking to retrofit something like this in, just for a simple piece of state like which tab is active, and don't want to refactor all your existing local state management code, Context is a really powerful tool for this.

I think of it like a dedicated state 'portal' - should I need to use one particular piece of local state in other components, I just write a quick dedicated Context for that one piece of data (super quick and simple and React-y using the new API) and simply set the context as well whenever I set that piece of state.

Won't work for everything, is a little hacky in a way and you wouldn't do it that way from scratch, but it's such a quick and easy solution to this issue compared to a major redesign of the global/local state.

Agreed, I use Context as a "store for UI stuff" and it always fitted perfectly. Keep data in the global store (Redux or whatever), component-specific state in the local state and inter-component state in Context.

And I wrap almost everything in hooks anyway, so the component doesn't care if it's local, Context or Redux: it's just data and I'm free to move it in different stores.

Tabs are typically the sort of thing that makes me think "context" immediately. Also implemented nested collapsable sections with this, TikTok-like feed where different components control the same UI component (sliding panel), tables...

I never find myself "burned" by locally stored state because it's trivial to move state up the tree and pass it down as props. But boy does it simplify an application a lot using locally stored state where it makes sense.

This is the way Elm works and I believe some people used or advocated for using Redux in this way early on. It never really caught on in React apps in my experience but it makes some interesting debugging methods easy to implement.

This is also how it works in Clojurescript (through Reagent/Re-frame). I don't have too much JS react experience, but I often read this kind of article and marvel at how huge the mental load is working on react projects in native JS.

You use a global db atom in re-frame for global state, but there's nothing stopping you from using a reagent atom local to a component, is there?

I never thought of the existence of the global db as the thing that ALL state should go in., or is that a community best practice?

Edit: after digging through the re-frame docs themselves, you can see here that local reagent atoms are used for local state even with the global app db: https://github.com/day8/re-frame/blob/69a3fcd411369fff65404e...

Author here.

You can try this, but I don't think it'll turn out well!

You don't want to have a bloated, disorganized global store...what you're doing now, moving state into global state only if needed, is the right way to go.

At some point, you might even want to only have one drop-down open across an entire site, so there goes your local drop-down state :P

Having everything in global state is cheap if you use Immutable.js data structures. In my experience, Immutable.js the only way to do the global store pattern e.g. Redux without making your app slow to a crawl.

Note that we specifically recommend _against_ using Immutable.js, and that there's many misunderstandings about the hypothetical performance benefits that Immutable.js provides:

https://redux.js.org/style-guide/style-guide#use-plain-javas...

Instead, we strongly recommend using Immer for immutable update logic, preferably as part of our new Redux Toolkit package:

https://redux.js.org/style-guide/style-guide#use-immer-for-w...

https://redux.js.org/style-guide/style-guide#use-redux-toolk...

I spent years with Immutable and discovering Immer was a game changer. Can't recommend it enough.

I didn't know about this new library but from my benchmarks it was a night and day difference moving to Immutable data structures all the way down. I understand not wanting to recommend it to newbies, but it's actually good.

If you can take a few minutes to read through https://redux.js.org/style-guide/style-guide#use-plain-javas... , and specifically the "Detailed Explanation" section there, I talked through all the perceived and actual perf benefits that you see with Immutable.js.

In short, most of the benefits people _think_ they get from Immutable.js are just properties of immutable updates in general, and there's actually some pitfalls of using it. The only real unique benefit is faster copies of _very_ large objects.

I'm not saying it's not helpful, just that it's not a silver bullet in and of itself the way some folks think it is, and that you can get similar benefits without the overhead of its API.

Immer is fantastic. It seems to be the best set of trade-offs to get as close as we can get in JavaScript to immutable reducers.

Reply on news.ycombinator.com