Mobx: Discussion on stores, singletons' constructors and patterns

[giacomorebonato]

I would like to share some thoughts about state that I had...
What I love about Mobx is that using the stores is really simple and fast.
I will say it with an example:

import { myStore } from '../stores

function MyTitle (props) {
    return (
        <h1>myStore.title</h1>
    )
}

export default observer(MyTitle)

So I am importing the stores modules in a lot of places... And I asked myself if this is wrong:

1. The stores are singletons...
2. I can still test the component mocking the singleton with a tool like Mockery
3. Dom nesting and Flux can drive you crazy
   ... so it is not so bad IMHO

I had some difficulties using this approach with server side rendering and hydration... and I gave up because of complexity.
Now I just print JSON data in a global object in a top script and then I look for it in the constructor of my stores.
In this way I avoid all the initial AJAX requests, but all the DOM is still built client side... and the code is still very simple to understand.

What can you criticise about this approach?

[hellectronic]

I always assign a store instance to a store property.

[markshust]

I have similar questions, however I think I'm close. What I'm doing is setting up individual stores, and then combining them into one master observable object. I'm wondering if this makes sense?

My main project sample code I setup is at https://github.com/markoshust/mantra-matui-mobx

Each separate state is a regular object:
https://github.com/markoshust/mantra-matui-mobx/blob/master/client/modules/core/states/header.js

And here's where I combine them into one master object:
https://github.com/markoshust/mantra-matui-mobx/blob/master/client/main.js#L8

I wanted to know if this is good and if there are any major downsides to this approach, and if it can scale well? I'm then updating each individual piece of state within actions:
https://github.com/markoshust/mantra-matui-mobx/blob/master/client/modules/core/actions/header.js

I really like the separation with Redux reducers, and am looking for a similar approach to organization with MobX.

Maybe @mweststrate can chime in 😉

[vinej]

I have also similar questions. As a 'Singleton' object as a global scope it's seem normal to use them directly.

I still prefer to pass them as props to components to keep the component with the minimum external references to help with unit test. If you pass it as props, it's possible to pass a mock object for testing purpose.

[giacomorebonato]

I get the point of Flux... but sometimes it feels too verbose to pass a property through a lot of components that don't care about it, until you reach the one you want...
We already have only one source of truth... and it is our singleton store.
My latest approach is to group all the stores into one object and make this object accessible through React context (although React discourages to use it).

[smiLLe]

In my app i have an outer component which creates a store instance and sets it into the react context. I also have a high order component which takes the store from the context and passes it as a prop to the wrapped component

[mweststrate]

Thanks for sharing all! I think this issue can be closed now?