Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lifecycle hooks #30

Closed
yoshuawuyts opened this issue Jun 23, 2016 · 4 comments
Closed

lifecycle hooks #30

yoshuawuyts opened this issue Jun 23, 2016 · 4 comments

Comments

@yoshuawuyts
Copy link
Member

As per our twitter convo we should probably investigate the possibilities of adding lifecycle hooks to yo-yo / bel again ✨

@shama
Copy link
Member

shama commented Jun 23, 2016

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
Copy link
Member Author

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
Copy link
Member

timwis commented Jun 26, 2016

@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
Copy link
Member Author

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

@shama shama closed this as completed in 2a5ddc0 Jun 30, 2016
shama added a commit that referenced this issue Jun 30, 2016
Add onload/onunload lifecycle properties. Fixes GH-30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants