Hacker News Reader

Comment by cellvia | Hacker News Reader

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?

View on HN

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.

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?

For your first question: nope, the important edge case is that deep changes on _non_ observable objects won't be observed. But that is no different from the edge that deep changes on (conceptually) immutable objects are not observed.

For the last question: yes exactly. Note that the observables can (should) usually be updated from a 'nice' place, for example from controller or class methods, as directly manipulating data inside event handlers (as done in the tutorial for brevity) will quickly result in your code becoming a mess. But besides that state should be updated in the most straight forward way possible :). So MobX is unopiniated from a technical perspective, but you should have some opinion about it so that code is regularly structured and easy to grasp by others.

Reply on news.ycombinator.com