Make state management simple again: Intro to MobX

Thank you for sharing this. I have been doing a lot of digging for an upcoming greenfield rewrite of our client side, and mobx+react is now tied w/ me alongside mercury.js, which shares a similarity in using nested observers as the nervous system of the viewstate. Have you had a chance to look at mercury and the way it achieves unidirectionality?

The documentation for mercury is sadly very poor, but the ideas are sound once you "get it"

here is the repo https://github.com/Raynos/mercury/

here are the rough docs https://github.com/Raynos/mercury/tree/master/docs

how would you compare the prescribed method of state management of mobx+react to mercury's immutable observer state-tree that sends observed changes up to the app root, then signals re-render w/ a immutable state emission to a cascade of renders below it?

Re: Make state management simple again: Intro to MobX

#8

Post by mweststrate » Sat, Mar 12, 2016, 3:34 PM UTC

cellvia wrote: post #7

Thank you for sharing this. I have been doing a lot of digging for an upcoming greenfield rewrite of our client side, and mobx+react is now tied w/ me alongside mercury.js, which shares a similarity in using nested observers as the nervous system of the viewstate. Have you had a chance to look at mercury and the way it achieves unidirectionality? The documentation for mercury is sadly very poor, but the ideas are sou…

I think it is quite different, at least if I read the docs correctly mercury is much closer to Redux / OM then MobX + React. MobX doesn't work with cursors and your tree doesn't have to be a normalized tree (it can be any (mutable) graph). In MobX data is not pushed through the root (which is when working with large collections still slow!) but rather each components observes exactly its own observables (deeply). This means that children can re-render without their parents and vice versa. This is done automatically and you don't have to write any cursors for it.

I'm not sure whether this answers your question completely, so just let me know if that is the case :)

Re: Make state management simple again: Intro to MobX

#9

Post by cellvia » Mon, Mar 14, 2016, 12:10 AM UTC

mweststrate wrote: post #8

cellvia wrote: post #7

Thank you for sharing this. I have been doing a lot of digging for an upcoming greenfield rewrite of our client side, and mobx+react is now tied w/ me alongside mercury.js, which shares a similarity in using nested observers as the nervous system of the viewstate. Have you had a chance to look at mercury and the way it achieves unidirectionality? The documentation for mercury is sadly very poor, but the ideas are sou…

I think it is quite different, at least if I read the docs correctly mercury is much closer to Redux / OM then MobX + React. MobX doesn't work with cursors and your tree doesn't have to be a normalized tree (it can be any (mutable) graph). In MobX data is not pushed through the root (which is when working with large collections still slow!) but rather each components observes exactly its own observables (deeply). Thi…

This definitely helps, thank you.

I suppose the main similarity is the chain of observables being a nervous system of sorts. In mercury the observers pass the update signal all the way back to root (and then needless re-renders are mitigated by vdom-thunks) , whereas w/ mobx the update signal is not passed up to root, just to the local component in question, and then that re-renders itself, so the rest of the app is not concerned

One cool thing about combining observables AND immutability as in mercury isyou get the equality checking via immutability, but you also get to deal w/ component updates locally. ...no dependence on a global event emitter or global event emitter abstraction like redux.

So 2 questions: w/ mobx + react how do you deal w/ events outside of a component?

And what, if anything, is lost from losing the uni-directionality?

Re: Make state management simple again: Intro to MobX

#10

Post by mweststrate » Mon, Mar 14, 2016, 7:10 AM UTC

cellvia wrote: post #9

mweststrate wrote: post #8

Earlier quoted context omitted.

I think it is quite different, at least if I read the docs correctly mercury is much closer to Redux / OM then MobX + React. MobX doesn't work with cursors and your tree doesn't have to be a normalized tree (it can be any (mutable) graph). In MobX data is not pushed through the root (which is when working with large collections still slow!) but rather each components observes exactly its own observables (deeply). Thi…

This definitely helps, thank you. I suppose the main similarity is the chain of observables being a nervous system of sorts. In mercury the observers pass the update signal all the way back to root (and then needless re-renders are mitigated by vdom-thunks) , whereas w/ mobx the update signal is not passed up to root, just to the local component in question, and then that re-renders itself, so the rest of the app is…

In MobX it actually doesn't matter whether the events happen inside or outside the component. Components themselves are part of the nervous system. They react to changing observables that are used in the rendering. Regardless how those observables are changed.

Note that MobX itself also uses reference equality checking (it applies PureRenderMixin), see this issue for an explanation why that is possible: https://github.com/mobxjs/mobx/issues/101#issuecomment-18987...

MobX is still unidirectional data flow: `events / actions => state => view` (although you could create React components that are bidirectional a recommend against that). But if you mean with unidirectional data flow that there is no action dispatcher; that is up to the developer. Having an action dispatcher might still be nice for your app. Or over engineering. MobX is unopiniated about these things.