-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
Component re-creation and loss of $ref objects #294
Comments
I'm having the same issues with refs that are the same. I have a number of "nodes" which when selected send content to a sidebar. The first selected node hangs on to the ref permanently even when it is no longer drawing/owning the sidebar. (I have a v-if on .). It gets the correct data, but the ref isn't relocated from the previous owner of the portal to the new one. I've tried with and without slim which does not seem to help. |
@LinusBorg: Can you confirm this issue or offer guidance? |
I can confirm that this is indeed an issue, but so far couldn't find out what exactly is causing it or how to work around it. I likely won't have enough time to look deeply into this in the coming weeks, which would likely be required as it seems this is a combination of a few different things happening. So unfortunately this will stay an open issue for the time being, and might be unresolvable if the reason is tied to Vue internals handling of refs. |
By adding unique keys to the elements, vue gets all the refs on the correct element, but it does still have end up with a lot of re-create and destroys. |
This is a step in the right direction. portal-vue could automatically add keys to (root level?) descendants of the And then there is the issue of the extra component creations and destroys. I know that I have created a lot of components that tap into the |
Anyone found a way to make refs work? |
We have been having issues within our single-page application where similar pages that use the same portal-assigned components are getting their
created
callbacks called when they should be being destroyed. I'm not certain if it is related or not, but there is also an issue when these components have aref
assignment that matches that on a different page/component.Here is a reproduction app of the situations: https://jsfiddle.net/uerLm1o0/10/
The text was updated successfully, but these errors were encountered: