Known Caveats

Admittedly, portal-vue uses a little bit of trickery to do what it does. With this come some caveats, which are documented below.

Local state lost when toggling disabled

When toggling the <portal> component's disabled state, components in the portal slot are destroyed and re-created, which means any changes to their local state are lost.

If you need to persist state, use some sort of state management


Due to the way that Vue resolves provides from parent components, it will look for provided objects in the parent of <portal-target>, so any provided objects of a parent of <portal> will not be available to components within a portal - but it will have access to those provided by parents of the <portal-target>.


For the same reason, this.$parent will not give you the parent of the <Portal>, instead it will give you the <PortalTarget>, so code relying on $parent might break.


<router-view> internally walks the $parent chain to find out how many (if any) parent


In rare cases, you might want to access a DOM element / component that is within the Portal content via a ref. This works, but sometimes requires a double $nextTick:

  this.$nextTick(() => {
    this.$refs.yourRef // element should now be in the DOM.

The reason is that depending on the secnario, it can take one tick for the content to be sent to the Wormhole (the middleman between <Portal> and <PortalTarget>), and another one to be picked up by the <PortalTarget>.