An opinionated way of managing the state in larger apps, having predefined places for all of your actions for example having a folder for you contexts and reducers.
Maybe even some cli command for creating new files related to this?
The core team what do you think?
Hey @guledali. Iām not a member of the Core team, but Iām interested in the topic of managing state in a Redwood app.
Can you describe in more detail what youāre proposing? Are you implying the use of Redux or Context or some other state management tool?
My assumption is that Redwood apps will mostly lean on the built-in Apollo Client for managing state in the app, at least as it relates to data coming from the server.
useContext and useReducer, just places to put these.
It does not matter if they pick hooks, redux, mobx or apollo. What Iām asking for, is a way of organizing this. This is what it means being āopinionatedā everyone that uses your framework do stuff similarly.
Imagine two companies using redwoodjs company A and company B both using redwoodjs but one is using redux and the other one is using mobx. Thatās two different architecture for managing state. That means you as developer if know one but not the other one you suddenly have to learn something else.
My vision is for redwoodjs is that every projects looks the same and you as developer starting at new company using redwoodjs. Youāre familiar with the basic structure of the application and able to contribute day-1.
Probably a directory like web/src/lib or web/src/utils could hold the code, which could then be imported into web/src/index.js, being opinionated about this, could feel restricitve IMHO.
I was thinking more like this image
How do people organize apollo state management in large apps. Any common best practises/pattern out there that people are following?
I just took a look at the code and redwood is managing apollo client currently. It is mostly the defaults right now using apollo-boost, take a look here redwood/packages/web/src/graphql/index.js.
Redwood may have to expose some of this configuration for developers to tweak the default apollo cache/state/network config. In which case - would it make it āopinionatedā towards apollo and not redux? What about devs who prefer redux or mobx. Maybe some core team members can share their vision on state management and what redwood would provide out of the box and if they have any opinion on that at this point.
Maybe including a apollo store file in pages directory?
When I look at something like https://www.apollographql.com/docs/react/data/local-state/
and compare it to https://reactjs.org/docs/hooks-reference.html#usereducer
It feels like the ālatterā is the easier one to understand and start implementing.
Personally I donāt think Readwood should tell developers what state management library to use, and in that case we cannot recommend a file structure for it. Redux, Mobx, Apollo or any other state management library have different needs, there could be actions and reducers, stores, ducks, etc.
@gfpacheco That means every redwoodjs app would looks different and we are back to a bunch of complexity which we are trying to eliminate in the first place.
Redwoodjs calls itself opinionated framework that means it makes the decision for the teams. State management is important one to make architecture wise and also about the file structure. Redwoodjs has pre-defined place for graphql, components, layouts and services why not for managing the state?
I donāt know how you guys are using graphql but in my company everything we get from graphql we put in a store that can be shared between components.
I can see context having a special place in Redwood. But personally I keep my reducers within the components that use them.
I donāt think Redwood should be opinionated about everything. I agree that state management is really important and thatās why I see people ditching Redwood if it enforces a state management that they donāt like.
I can definitely see some plugins for each of them though (redwood-redux, redwood-mobx, etc). And those plugins could even include some generators.
2 Likes