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