Best practices for global state and some simillar cases in meteor react app?

Hey guys! With meteor being data - driven and with live data I find it very easy and simple to manage the state.
However there are few cases I think I need to do better.

The first one is some top level or global states. For instance in my app users are able to create projects and then navigate between their projects. So they choose their project from a dropdown in a top level Header component and then the whole app rerenders the containers re-subscribe with the new projectid. So with pure react I had 2 options.
The painful way - pass the projectId manually to all the children and children of children etc… Or use react context, which however is not recommended by the official react docs

Well there are redux and mobx for state management I know so far. But I think for a meteor app they just add complexity. In meteor everything should be simple!
For a case like this meteor’s session would have been perfect. You simple set it and get it wherever needed, however it seems to not be working with react well enough.

So what do you do in such a case, redux or mobx or what?

And another case I really wonder what you are doing is the following.
For instance I have a page with some toggles, texts and editable options etc… And I have a save button. So I want my options to go to the mongo db only when the user clicks save. Thus I need some place to store the current options. Where do you store it? In a global state? In some top level component state itself? In what format. Like state:{option1,option2,option3} or state:{settings:{option1,option2,option3}}
The later case may be useful if you have a hell lot of options and some other variables in the state. But in that case settings object would need some immutability.
And to make things even worse in some cases you have to implement undo redo functionality?

So what do you do in such and similar cases?

2 Likes