4 ms·

This is reaaaally cool. It's pretty much exactly what I've been looking for in a JS framework. The cool thing is that rendering is totally separate. Virtual do

• bsimpson 12y ago
  The whole "single concern" analogy fell apart there. "View output: a Virtual DOM rendering of the model, and raw user input events" - it's the only component that does two things. Moreover, if this is just the virtual, unrendered DOM, where do the events come from?
  • staltz 12y ago
    DOM events are being delegated to Virtual DOM event handlers. This is what 'dom-delegator' does, it comes from mercury: https://github.com/Raynos/mercury/blob/master/docs/dom-delegator.md https://github.com/Raynos/mercury/blob/master/docs/dom-deleg... Still, the View doesn't "do" two things. It does just one: renders virtual elements. The virtual element output just happens to consist of two things: the element, and events coming from that element. In tests where the View is isolated from the browser and from the Model-View-Intent cycle, virtual DOM events will actually not exist at all, because there is no user interacting with the view. Virtual DOM events only happen, and only make sense, when everything is plugged in and executing in the browser with user interaction.