Ah sorry for the terse explanation before.
For the global state when I said foo_state
I just meant I can setup a global state with a shape that resembles something like this:
let make = (_children) => {
getInitialState: () => {
sidebar_state: {step: 1, currentStepName: "Shipping"},
modal_state: {modalText: ""},
current_theme: {type: "dark"},
},
}
...
And then you could pass this state and a setter function down via context. The setter function would ideally only update one piece of the state. The sidebar/modal/etc… isn’t a great example but in theory if you had some state that had to be global this could be something to use. I really try not to use context though unless it’s a maintenance win (like having 100+ form inputs).
For the second part, the local state, a parent component… lets say a “PostsPage” component could contain local state with the the state needed for posts and comments, and it passes it down (prop drilling) to all the children that need it. I did put setParentState
out of habit with React JS, but in Reason it would be more like dispatchParentAction and the child would use it to dispatch an action that would trigger the parents reducer to update it’s state… maybe something like this (just pseudo code, not sure if it compiles)
let component = ReasonReact.reducerComponent("PostsPage");
let make = (_children) => {
{
...component,
initialState: () => {/*...*/},
reducer: (action, state) =>
switch (action) {
| EditPost(newText) => handleEditPost(newText)
},
render: self => {
<div>
<Posts postsState=self.state postsDispatch=self.send />
</div>
},
};
};
This has gotten the job done for me but i’m still learning as well. @jasim had a better example of this, only they used a data structure outside of the React tree all together to separate business rules from the interface and passed it in and used that as the state (eg the data doesn’t actually have to be in the same file… which is great).
I would definitely checkout this whole thread but here’s the full context and an example of the methodology:
I’m going to try and refactor a side project (realtime crypto dashboard) to use this as I think it’s the best at separating business logic and making it more maintainable than having state types trapped inside of the component (not quite sure how this would work for projects with Apollo but that’s another story lol).