Does Redwood have a preferred state management paradigm?

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?


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 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.


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!

1 Like

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

1 Like

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:

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

It looks super promising.


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

1 Like

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

1 Like

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?


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