Earlier quoted context omitted.
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://githu…
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?