lifecycle hooks about nanohtml

[shama]

I want to play around with how this will affect the ecosystem but I'm thinking we should implement as custom events for consistency with existing events:

var popover = bel`<div onload=${function () {
  document.addEventListener('mousedown', isMouseOutside, false)
}} onunload=${function () {
  document.removeEventListener('mousedown', isMouseOutside, false)
}}>hi</div>`

// Fire onload
document.body.appendChild(popover)

// Fire onunload
document.body.removeChild(popover)

I only chose the names onload and unload to correspond with the native event names on window.

---

Also atm I just want to stick with these two events. Each framework has an analog to these two, so when implementing interoperability later it will make it easy if we don't add any more custom events like onresize or onbeforeunload etc.

[yoshuawuyts]

ooh, yeah I really like that - means that there's no overhead unless explicitly opted in to. Might perhaps need some work with yo-yoify on that, but I think this would def be the right approach!

Yeah, also think that sticking to these two events would be good. Might be worth considering to pass the enclosing element as the first argument to the callback for onload so that any stuff like d3 can just attach itself to the node instead of having to do some odd hoop jumping to find the node it should append itself to. What do you reckon?

[timwis]

@yoshuawuyts the first time I read your comment, I thought you meant pass the parent element (misread "enclosing"). Reading it again, I think you meant the element itself (that probably makes more sense anyway). Right?

return bel`<div class="map" onload=${(el) => L.map(el)}></div>`

Because without a reference to it, you'd have to memoize the element, which could get a bit tedious. Unless this already references the element.

[yoshuawuyts]

@timwis yup, you got that right - apologies for not being clear enough