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