Does Redwood have a preferred state management paradigm?

Get Help and Help Others
1

Redwood uses React on the front end, it would make sense for state management to be handled through something like Redux, but there are a lot of different ways to do this. I think it would make sense for Redwood to have a preferred pattern for doing state management, so that this can be integrated into the examples / scaffolded code that’s generated.

Does a preferred pattern exist? If not, are there plans to add one?

4 Likes
2

We had a chance to discuss this today. And as of now, the answer is “No, not yet.” Ideally Redwood will be opinionated about state, caching, offline, etc. But the reality is this won’t happen near-term.

Currently, we are leaning heavily into React Hooks ourselves. Here’s an example article.

We know Hooks doesn’t cover every need now or to come, so we encourage people to implement what they’re comfortable with as needed for their apps. For those doing research, the three main contenders are Redux, MobX, and React Context – Redux is the most popular by far (per downloads).

We helped add Apollo Server Response Caching for the predictcovid.com site, which is working really well. I’ll try to create an example with instructions here in the forums soon.

And please keep this conversation thread going and let us know what is and isn’t working along the way.

3 Likes
3

Apollo recommends using the Apollo Client cache for local state management over Redux/MobX, was this considered as an option?

We want to be able to access boolean flags and device API results from multiple components in our app, but don’t want to maintain a separate Redux or MobX store. Ideally, we would like the Apollo cache to be the single source of truth for all data in our client application.

Apollo Client (>= 2.5) has built-in local state handling capabilities that allow you to store your local data inside the Apollo cache alongside your remote data. To access your local data, just query it with GraphQL. You can even request local and server data within the same query!

https://www.apollographql.com/docs/react/data/local-state/

2 Likes
4

:thinking: How do you planning to handle auth? Because that’s usually a task for the global state.

1 Like
5

If you take a look at the example-blog codebase you can see how I did auth with Netlify Identity. I use useState to keep track of a currentUser locally: https://github.com/redwoodjs/example-blog/blob/master/web/src/layouts/AdminLayout/AdminLayout.js#L6-L24

6

Facebook has an experimental library called “recoil”, here’s a demo of why thye built it and how it works:

It looks super promising.

8 Likes
7

@peterp - I just watched, I love that! Seems simple and like it would be a great fit for Redwood!

1 Like
8

Initially I looked at useContext + useReducer because of ease of use. However now I have learned that useContext will rerender whenever the context value is changed.

They are two patterns that solved this,

  • Splitting context: if storing everything in a monolith context is problematic, we can split context separating unrelated data, and what’s more, we can keep state as close to where it’s needed as possible.
  • Using containers: we can wrap our components by containers that filter out undesired global state updates. This solution mimicks what was done by Redux containers: listening to global state changes, but only passing down the desired part of the state through props. Although containers will re-render on every context update, they are very light and cheap components to minimize performance issues

This two libraries are also quite interesting


https://easy-peasy.now.sh

1 Like
9

I was thinking of throwing together an example with zustand, which is just the right level of abstraction for my global state needs. Would that be helpful?

5 Likes
10

I’m experimenting with mobx – will share my observations once I have enough experience with it.

1 Like
11

Urm… while it looks like Recoil is being used heavily at FB (Meta) they will not release a version one RSN.

My vote is for XState https://xstate.js.org/ which now has statecharts

12

I’ve been using Recoil in a couple of projects, it’s been great.

1 Like
13

I loved the video – I’d love to try it before trying [again] to understand XState – which sounds cool every time I read into it, but bends my old brain the wrong way… (Like Obective-C did!)

How do you feel about it’s reluctance to go to v1.0 ?

14

Sorry for reviving this thread but I’m wondering whether there’s any discussion around handling server state on the web side.

I’m fond of solutions like react-query where you can easily manage promises without necessarily having to manually create state values for each thing (i.e creating loading and error states, creating cache logic, etc).

For client state I much rather have Redwood be unopinionated, at least for now, but server state seems like a thing that’s inescapable as soon as you start interfacing with third party services from the web side.

15

Have you been using it in combination with Redwood cells?

I’m writing an app where users search for an address, and they might change it to search for another.

Whenever the address changes I want to update various other states, and this seems to fit with the atom->selector paradigm from recoil. I’ve decomposed by app so the other states each require getting something from my API (which typically gets data from some other third party API).

I’m looking for a way to combine recoils dependency tree with Redwood Cells, which I’d really like to use to avoid writing a bunch of boilerplate. Any tips?

16

You could tie into the beforeQuery() and afterQuery() functions that are available in cells and update some state in those?

17

Dusting off this thread once again, as @spqrix asked about the topic on Discord.

I’ll add a note: In Redwood apps, I have observed less of a focus on app-wide state management tools. Instead,

  1. push the limit of React’s useState, useContext, useReducer.
  2. grab data and post data frequently to/from the API/server/database via GraphQL. (more of an emphasis on frequent GraphQL data transfers, vs. prior apps where I stored everything in Redux and posted/received data in big chunks).
  3. Then use a state management tool when the limits of the above are being felt.

Just my two cents and observations. Any thoughts?