cellvia

thank you for taking the time to explain all this, its very helpful!

i see what you mean now about equality checking. you are using it, but only in the cases that the observables do not already provide the mutatation check. it looks like you are using a great balance of mutating observables w/ equality checking, though i have to wonder how this marriage doesnt crop up with a large amount of edge cases.

still, exciting idea nonetheless!

one last question... are you saying an ideal mobx implementation has no opinion whatosever about how events / actions are handled as long as they result in updates of mobx observables directly?

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?

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?