Skip to content
New issue

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

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

Already on GitHub? # to your account

Consider deprecating onDomRefresh #1887

Closed
jamesplease opened this issue Sep 14, 2014 · 3 comments
Closed

Consider deprecating onDomRefresh #1887

jamesplease opened this issue Sep 14, 2014 · 3 comments

Comments

@jamesplease
Copy link
Member

onAttach will serve the needs of most people, but is it enough to fully replace onDomRefresh? This issue is for us to think about that more.

An interesting thing to note is that if we get rid of onDomRefresh, we might be able to get rid of the internal _rendered and _shown properties.

@jamesplease
Copy link
Member Author

At most, onDomRefresh is a duplicate of onShow and onRender, as it is nearly triggered when both of those are triggered. However, it limits itself to be called only when the element is a child of the document.

Consequently, onAttach will handle the onShow case – and do it in a more robust way – than what onDomRefresh could ever do.

However, onDomRefresh is called when you run render on a view that already exists, whereas onAttach is not called. This is because onAttach only works in conjunction with a region, by design.

Given the primary use case of onAttach – sharing when nested view structures are attached – it'd be impossible to make it work within the render method. It necessarily needs to happen after rendering.

Because of this, I propose that we add a new event: onRefresh. This is called whenever a view is rendered and is a child of the document.

@moimikey
Copy link
Contributor

👍 certainly

@jamesplease
Copy link
Member Author

Moved to #1796

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants