DEV Community

Discussion on: From Redux to MobX

Collapse
 
mbarzeev profile image
Matti Bar-Zeev

Thanks for the reply.
Could you please elaborate or add a resource link to what you've mentioned about using functions instead of classes in MobX?
Also how do you see instantiating a store for each request, or using Electron affecting whether to use the context or not?
BTW, I am not attempting to "sell" MobX :) This is my way of getting to know it.
Appreciate your feedback.

Collapse
 
romeerez profile image
Roman K • Edited

Regarding functions approach, there is a useLocalObservable which is calling makeObservable under the hood. Example is here: mobx.js.org/react-integration.html...
(Click on "useLocalObservable hook" tab)
Another option is to use const store = useMemo(() => makeAutoObservable({ ...store definition }), [])
Because makeAuto is a bit different from make and is preferred in some cases.

So I create a file myFeature.store.ts and write a hook in there useMyFeatureStore where I call useLocalObservable, and then call this hook in component and put the store to context - when need a context. And when don't need it - just export const myStore = makeAutoObservable({ ...definition of store })

On one hand, well, maybe classes looks more accurate. But on the other hand, in React everything is usually written on functions and hooks and we get used to it.

Also how do you see instantiating a store for each request

When the store is instantiated in the component during rendering, we can be sure this store will be available only for current user of next.js. In Electron or when no next.js we can be sure there is only one user using the app, so it's usually fine to export const myStore = makeAutoObservable({ ...definition of store }) and to use the store by simply importing it from store file.

BTW, I am not attempting to "sell" MobX :)

I know, you are learning and sharing experience, and this is great. I just wish MobX to be more popular to not see Redux on every project.

Thread Thread
 
mbarzeev profile image
Matti Bar-Zeev

interesting... I still think that having the state in a separated class, which can be tested quite easily as well, is a better approach.
It's nice, though, that MobX gives the flexibility to split the application state according to business contexts, but I believe it is more applicable to large scale application.
Great input, I will keep on digging into this :)

Thread Thread
 
romeerez profile image
Roman K

It's nice, though, that MobX gives the flexibility to split the application state according to business contexts, but I believe it is more applicable to large scale application.

Well, let's imagine simplified dev.to: article with "like" button and comments. And two MobX stores are serving this: Comments.store.ts and ArticleButtons.store.ts. It's hard to name this site "large scale application", but still splitting business contexts makes it cleaner. So, in my opinion, the way you write react should not be different depending of the size of the app. Writing state of every aspect of the app to the single store is just the same as writing all JSX in the single App file.