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

Add parent parameter to Component's mounted function #616

Closed
Wodann opened this issue Aug 26, 2019 · 7 comments
Closed

Add parent parameter to Component's mounted function #616

Wodann opened this issue Aug 26, 2019 · 7 comments
Labels

Comments

@Wodann
Copy link
Contributor

Wodann commented Aug 26, 2019

I'm submitting a feature request for the addition of a parent: &Element - that implements the IParentNode trait - to the fn mounted(&self) of a Component:

fn mounted(&self, parent: &Element)

Instead of having to look through the entire document tree to find the current element, we'd be able to use the parent node to execute any desired JS, resulting in a significant speed up.

@davidkna
Copy link
Contributor

Something like html! { <div onmount=|element| Msg::Mounted(element) /> } for regular elements would also be nice.

@jstarry
Copy link
Member

jstarry commented Sep 5, 2019

@hgzimmerman @Wodann would refs solve this issue? We could potentially enforce those at compile time

@hgzimmerman
Copy link
Member

I don't have a full comprehension of how refs work in this context, but if you think an alternative approach instead of my quick and dirty solution can more accurately constrain possible misuses of the API, or ultimately offer something simpler to use, please favor that instead.

@Wodann
Copy link
Contributor Author

Wodann commented Sep 5, 2019

A Reference (doc) should be sufficient for downcasting to an Element - or any type of HTML element for that matter. However, Element already implements IParentNode and thus makes ergonomics easier.

For me, the question is whether we could ever have a parent that is not an Element? No right? So then we might as well use Element. That can then be converted to specific element types using try_into, which still has a check built in.

@jstarry
Copy link
Member

jstarry commented Sep 27, 2019

@Wodann @hgzimmerman this is what I had in mind: #665

@Wodann
Copy link
Contributor Author

Wodann commented Oct 1, 2019

@jstarry That seems like an efficient solution 👍

@jstarry
Copy link
Member

jstarry commented Nov 28, 2019

Closing in favour of refs approach

@jstarry jstarry closed this as completed Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants