Source
r/reactjs•
RogueToad

Which state management tool should I use for a large global object?

Needs Help

Pretty much title. I tried asking in the beginner's thread but didn't get any takers unfortunately...anyway, if you can help, I'm basically making something like a D&D character creator SPA where multiple characters are stored and switchable between at any time. So my plan was to have several objects, one for each character, and nested inside those would be deeply nested objects containing the character stats, info, etc. E.g. something like this, but with a lot more fields & nesting:

const character = {
  stats: {
    strength: 20,
    dexterity: 32,
    ...
  },
  abilities: [
    {
      type: "type1",
      effects: {
        physical: "Something physical",
        mental: "Something mental"
      }
    }
  ]
}

I would use react context (perhaps using rambda lenses to edit the nested fields), but as far as I can tell it's not meant for state that updates a lot, since I think it causes everything in its tree to re-render? (Not 100% on that though) And as for other state libraries, I was considering zustand but I'm worried it's not meant for my use case of having monolithic objects, since I imagine that makes it hard to tell which components should be re-rendered on a change, which would then kinda defeat the point.

If you have any ideas, please let me know!

TL;DR: which state management tool do I use for an app with lots of regularly changing input fields that edit a nested global object?

Edit: Thanks for all the responses! But I suppose I should have also asked "and why?"

Posted Feb 8, 2022, 2:24 AM UTC · edited

724
MedicatedApe•

Redux.

14
acemarke•

Heh, I actually just wrote an answer for you over in the beginner's thread :) But I'll paste it here for visibility as well.

Feels to me like this is a couple different questions:

  • How to handle sharing state between components
  • How to handle form state and inputs

How many of these inputs will be on screen at once? What does the general component structure look like?

I would definitely avoid trying to have each input field knowing a lot of the details about where in the global state a given field lives. Instead, some possible options / thoughts:

  • Assuming that a given component is meant to edit specific subsets of the character attributes, you could feed in the initial object to seed the form, then let it trigger a single "update" behavior when the user is done editing that section. (For Redux especially, we specifically recommend against directly tying input fields to the Redux state - in other words, don't go dispatching actions for every keystroke. Do a single "updated" action after the user is done with the form.)
  • For the form and input handling specifically, libraries like Formik, React Final Form, and React Hook Form are all good choices for removing boilerplate from dealing with form fields
  • I haven't used Zustand, but I would assume it's a reasonable choice. You could also go with a useReducer hook in the parent, and let the child components dispatch actions to update it. (I will note that if you are going to write a reducer of any meaningful complexity, it's worth using Redux Toolkit's createSlice to generate that reducer even if you aren't using a Redux store in the app.)
  • If you do need to do any actual nested state updates somewhere, be sure to use Immer to simplify that immutable update logic (RTK already has that built in, and the Zustand README shows how to use it there too.)
  • FWIW Zustand's docs give examples of "subscribing with selectors", so I would assume you can ensure that a component only pulls out the data it needs to

You are right that putting data into a context will cause all consuming components to re-render, although it's a lot more involved than that. I'd suggest reading my posts on this topic:

So, TL;DR: I think any of useReducer, Zustand, and Redux are reasonable options here, but you probably will want to do a bit more architecting beyond just "choose a state management tool".

11
RogueToadOP•

Thanks, you've cleared up a lot for me (and nice rendering article, thx, I'm making my way through it).

  • To answer your questions - a lot of inputs on screen at the same time, maybe ~20 max at a time. And my component structure breaks up the fields into groups based on degrees of relation, with larger categories broken up into different pages by react-router.

  • You make an excellent point about building 'update' behaviour - essentially forms - into components containing subsets of the data (I already have my fields grouped in this way anyway), and this would also be helpful later on as I plan to allow the user to enable automatic data 'saving' using the indexedDB api, which would work so much better with batched updates like you suggest. Plus, u/eggtart_prince pointed me to this part of the RTK docs and I'm inclined to take that advice.

  • Immer looks lovely, thanks! Great rec. And others here have me inclined to just go with RTK for now, I feel safer with a more mature toolkit, with a lot of resouces to point me in the right direction like YT, the docs, etc.

Ultimately, yeah, you're right, I'm going to have to change a lot. I very much appreciate the time you've taken to point me in the right direction :D

1
ashish_feels•

Zustand

5
tapetotapeDOTnet•

I would use mobx if I was you. You represent your data objects as classes so it maps naturally to a singleton structure, business logic lives beside the data as methods, and you won’t have lots of boilerplate and BS, just methods to invoke on classes with fields you can read directly. The parts of the UI tree which are reading those fields rerender and no other parts.

Check out MobX 6 docs, I use their RootStore pattern, representing groups / containers as stores that contain maps of class instances that represent important semantic objects

5
editor_of_the_beast•

I really don’t understand why Mobx isn’t more popular. It’s so much simpler than anything that’s out there. I feel like I just write regular code and add makeAutoObservable, and everything works.

2
N3HL•

I really don't understand why mobx isn't more popular

One big reason I didn't like mobx was the amount of magic going under the hood + the state mutations. Since they use proxies it means you could mutate state and let mobx take care of the updates of an entire tree. This is just not idiomatic imo, given that react promotes immutability (and redux made it insanely popular, though definitely not a new thing). Immutability makes stuff easier to test and reason about, and there are even some patterns that are easier to implement with it (like drafts). A plain reducer (or even a state machine) is just much more predictable and close to "day to day" js. For the component updates part, I prefer to rely on reacts default behavior and tweak as needed rather than mobx's. There are other factors too like class stores, decorators, the gotchas around reactivity, etc.

2
tapetotapeDOTnet•

> Since they use proxies it means you could mutate state and let mobx take care of the updates of an entire tree. This is just not idiomatic imo

Who cares about "idiomatic"? It's faster. A runtime dependency graph is inherently going to be closer to optimal performance than heavy stores and reducers rendering entire subtrees

> the amount of magic going under the hood

It's a really low amount of magic. Your changes on an observable are tracked by mobx; your accesses on observables are tracked by mobx. It can therefore update the UI when you change an observable that is accessed by a currently rendered component.

How is that magic, exactly? It's terse.

> For the component updates part, I prefer to rely on reacts default behavior and tweak as needed rather than mobx's

Why? It's slower and more redundant.

> There are other factors too like class stores, decorators, the gotchas around reactivity, etc

Decorators are long gone; long live MobX 6

"Gotchas" around reactivity are a very small price to pay for not having to write reducers and other BS instead of just invoking a method

Class stores? What is this?

1
N3HL•

The thing is the vast majority of web apps don't need "close to optimal performance" at the cost of readability, testability and predictability :)

The reducer boilerplate wasn't even that bad + people really needs to learn how to model processes with finite state machines, it will make their lives much easier.

I don't know if mobx 6 got better, but I don't plan to try it again.

It seems you made up your mind though. Use whatever you like.

1
jbergens•

Mobx State Tree might be even better in this situation.

1
tapetotapeDOTnet•

MST seems beautiful, but I found it incredibly awkward to set up, and dividing code between stores was confusing. I wish there was a more opinionated starter kit for MST because despite my MobX expertise I couldn't make it work as well / easily as MobX itself

1
SarcasticSarco•

Redux Toolkit man.. Go for it.

5
malokevi•

You're right about context. Any update to context value will result in all subscribers rerendering, which is hell for a complex app. I'd stick with redux, it can handle massive objects.

3
bobbyv137•

Use redux toolkit. Sure it’s messy to learn and isn’t as popular due to way more options. But it compliments react well. Lots of recent videos on YouTube. Once you grasp it it’s actually quite simple (tho I guess that applies to programming overall!)

3
tobiduh•

Redux toolkit. Redux was super messy, but toolkit makes it much easier

3
[deleted]•

[removed]

2
joelcorey•

Effector

1
slikk66•

+1 I'm a big Effector fan also high five

2
joelcorey•

High five back!! It makes life super easy. Nothing wrong with other state containers though.

1
eggtart_prince•

Do the nested fields need to be updated? If so, you need to reconsider the structure of your global state. For example, libraries like Redux recommends your state to be as pure and simple as possible.

https://redux.js.org/style-guide/style-guide#normalize-complex-nestedrelational-state

1
RogueToadOP•

I see, that helps a lot. Yes, the nested fields need to be updated, so I was worried I'd have to do this - to flatten my data - but it makes sense. Thanks.

1
Macaframa•

I would store each character in a backend, aggregate the character _id's into the current player's list of available characters, when you want to switch, your app makes a request to the backend and grabs the right character's information then loads them and stores the entire object in a state management system like redux. Although redux is incredibly cumbersome but the concept is pretty simple. You can also leverage the user's browser for localStorage, that is retrievable throughout the entire app. I'm just giving you options as implementing redux without a complete list of reasons who's value doesn't outweigh the overhead is a bad idea.

1
drcmda•

these flux state managers pretty much thrive on monolithic object state. because they use reference equality you can know at any time which subtree or value has changed and your components expressing these objects are very much render optimized. updating nested state can be a bit awkward because you form state via shallow equality, but things like mergeDeepRight or immer make that straight forward.

at work we use zustand in a massive in browser CAD application. the state, having to express user-made models, is arbitrarily and deeply nested and may contains hundreds of thousands of minute objects. since state is just javascript the server can even use json patch fragments to change nested items. and ofc only components render that are actually concerned, everything else stays put.

and i just notice, since your state looks like game state — zustand is being used for games running 120fps. in part it was developed for that usecase (it's pmndrs after all), to withhold fast re-occuring updates.

1
Select-Ad-8909•

For me, recoil is the best. It's simple and clear and has good documentation

plus, it's maintained by fb

https://recoiljs.org/

1