Lifecycle of elements

I’ve been trying to work out a sensible way to handle the lifecycle of elements. It would be useful to know when an element is added to the document, when it’s morphed, and when it’s discarded. Though this functionality exists (aside from creation), it’s not very well set up to allow you to respond to these changes on a per-element basis.

var button = document.createElement('button')
button.on('update', function () {
  button.focus()
})

Some other inspiration… https://github.com/substack/virtual-hyperscript-mount https://github.com/substack/virtual-hyperscript-hook virtual-dom: https://github.com/Matt-Esch/virtual-dom/blob/master/docs/hooks.md React: http://facebook.github.io/react/docs/component-specs.html

What do you think? I would like to put a library together that wraps morphdom to provide this functionality, but I’m not sure if I’ve got the wrong idea.

[patrick-steele-idem]

@callum

I like what you did with morphdom-hooks, but what are your thoughts on changing the API a bit:

constant morphdomHooks = require('morphdom-hooks');
const b = document.createElement('button');
morphdomHooks.on(b, 'add', console.log.bind(console, 'button added to page!'))
morphdomHooks.on(b, 'update', console.log.bind(console, 'button updated in page!'))
morphdomHooks.on(b, 'discard', console.log.bind(console, 'button discarded from page!'))

I realize that makes the user code dependent on morphdom-hooks wherever listeners are to be added, but maybe that is okay?

@AutoSponge

I would prefer an eventEmitter implementation here.

I think an EventEmitter API is better exposed as a wrapper to keep this library as small and as fast as possible.

@yoshuawuyts

The one thing it doesn’t allow doing, however, is setting the equivalent of React’s .shouldComponentUpdate(), which means that morphdom will always diff the complete trees. It’d be pretty cool if we could apply some smart heuristics to determining if a particular branch of a DOM tree should be diffed (perhaps by going full Merkle-tree? - idk)

As @AutoSponge mentioned, you can tell morphdom to skip parts of a DOM subtree by returning false in the onBeforeElUpdated callback.

Good discussion, but closing issue to do avoid keeping issues open for too long. If you have thoughts or comments please feel free to add here or open a new issue. Thanks all.

[AutoSponge]

@yoshuawuyts Agreed. shouldComponentUpdate would be helpful for large interfaces to either not render out-of-viewport or delegate it to a background/idle task. While I haven’t tried that yet, I suspect everything we need is already in morphdom via the #onBefore... hooks.

By returning false, I can prevent a node/tree from rendering. If I then cache that node in a map with the target that I would have rendered, I can create an idle worker to update cached nodes by calling morphdom on each cache pair.