portal-vue
portal-vue copied to clipboard
LinusBorg
Docs indicate `passengers` is not required for `Wormhole.open`, but without them the call immediately returns
From what I understand on the docs here, when I'm using Wormhole.open I don't have to provide the passengers argument for Wormhole.open, which I assume would mean that the content sent would be whatever children are in the from portal when the open is called. However, after trying this, it doesn't seem to work (at least not the way I expect), and after digging into the source, I see this:
export const Wormhole = Vue.extend({
data: () => ({
transports,
targets,
sources,
trackInstances: inBrowser,
}),
methods: {
open(transport: TransportInput) {
if (!inBrowser) return
const { to, from, passengers, order = Infinity } = transport
if (!to || !from || !passengers) return // <---- Seems to imply passengers IS required
...
}
});
Anyways, here's a repro of what I'm trying to do. I would think it would toggled different portal contents into the given portal target, but it's not working as expected.
You're right, passengers is required, this is a mistake in the docs.
Thanks for bringing it up!
About what you are trying to do: That's not gonna work, the Wormhole isn't mean to actively pull from a <portal>
I think all you need it to use the disabled prop on your portals like this:
<portal :name="content1Id" :disabled="!content1Active" slim>
<div>The content of my portal when I send it</div>
</portal>
<portal :name="content2Id" :disabled="!content2Active" slim>
<div>The content of my portal when I send it</div>
</portal>
@LinusBorg, while that solution works in my trivial reproduction example, my real use-case is having a sharable flyout component that can be used by multiple components distributed across my app. So, managing enabled/disabled state of each content area sharing the flyout could become pretty non-trivial in that instance, though not necessarily impossible.
At the very least it, I think it would probably require some type of provide/inject usage, which I try to only use as a last resort.
If I understand correctly, the from fields of the transport objects used in the open and close functions map directly to a field of the sources object, which is just a VNode tree corresponding to the portal with the name supplied to the from field, right? And that VNode list always has a single root node that is a portal type VueComponent? If that's correct is there a particular reason why, if passengers isn't supplied, you've chosen not to use the content of the default slot of the portal component that corresponds to the from field? Does that just make the behavior too implicit and magical?
It seemed like natural functionality to me, and was how I was assuming it would work. In fact, I added about four lines of code to the dist file and it seemed to work that way reasonably well, but I understand if there are edge cases that would go haywire if you tried to do that. Or if you just think it's not explicit enough. Just trying to understand 👌
I only added The sources and targets properties in 2.0.0 quite recently and didn't even intend for them to be used this way, to be honest.
What you propose would indeed work with one caveat: the code calling Wormhole.open() has to assume that the source portal actually exists at the time of the call, otherwise there nowhere to fetch passengers from.
I'll think a bit about your proposal though, it might work fine.
Forrest for all the trees...
Ok, cool. Thanks for taking the time to read my thoughts. For now I'll try to figure out something elegant I can do to handle it in userland.
@LinusBorg small follow up, it looks like this commit, which was supposed to be released in 2.1.5, didn't actually make it into the deployed build, for some reason. As you can see here the distributed file is missing this change.
Sorry I'm making such a fuss 😭