Support multiple portals sending content to one target at the same time

[gleam-ru]

I'd like to be able to append multiple portals to single portal-target (like Jade-blocks does).

Here are some examples:

<portal-target name="under-nav">
  0
</portal-target>
<!-- if there are no "from-portals" content of portal-target is "0" -->

<portal to="under-nav">
    1
</portal>
<!-- the default content is overwritten so portal-target is "1" now -->

<portal to="under-nav" append="true">
    2
</portal>
<!-- appends to existing content => "12" -->

<portal to="under-nav" prepend="true">
    3
</portal>
<!-- prepends to existing content => "312" -->

My use-case.

I have a page like:
http://joxi.ru/E2pbGWvF98nNdr

And I want to create under-nav panels dynamically:
http://joxi.ru/DrlpJ7aFvJWw3r

[LinusBorg]

Hey, thanks for your request!

I have thought about this as well, good to see there's a use case for this.

However, I have to think how to implement this, or a similar API. I don't think that append and prepend will suffice, because then someone will come up and request the possibility to add 4 or more source portals.

So if we implement this, it should be possible to add any number of portals and give each one a position number, priority or something.

Will think about this, but will be offline for pretty much all of the next week due to vacation.

Thanks again!

[LinusBorg]

I think I found a nice API for this, currently testing...

[tmorehouse]

Is it possible to have multiple <portal>s use the same <portal-target>s?, i.e. overwriting the content of the portal-target set by a previous <portal>?.

I'm thinking of a re-usable modal, where multiple content would be able to use the same modal base structure?

Or maybe have a <portal-container> container that <portal-target>s can be a child of? It would be nice to be able to dynamically instantiate the <portal-target>s if they don't exist (and the <portal-container> is the default location they get rendered into.). This would save having to alter your HTML template for new out of app <portal-target>s.

[LinusBorg]

Yes, you use the same target even right now.

Just make sure that only one source portal is active at a time, because theblatestbome will always overwrite the previously rendered ones' content.

This issue here is about offering a possibility to render multiple sources portals in the same a target together, which I am still working on

[trainiac]

Looking forward to this feature!

[LinusBorg]

I may still take a while, it's a bit tricky to get right.

[LinusBorg]

I've moved this to the 1.1.0 Milestone, because it's really more of a complete rewrite of the core functionality and I want to take some time to test this through properly.

Will now concentrate more on finally getting rid of the beta status and release a stable 1.0.0

[d13r]

I would love to see this too. My use case is a <select> replacement (like Select2 or Chosen) where the dropdown needs to be outside the container (to deal with overflow: hidden).

My current solution is to dynamically create target elements for each instance. (I'm using jQuery, but it could be converted to use document.createElement() instead.)

<script>
    import $ from 'jquery';

    let portalNumber = 1;

    export default {
        data()
        {
            return {
                portalId: null,
                showDropdown: false,
            };
        },
        mounted()
        {
            this.portalId = 'form-select-portal-' + portalNumber++;
            $('<div>').attr('id', this.portalId).appendTo('body');
        },
        beforeDestroy()
        {
            $('#' + this.portalId).remove();
        },
        // ...
}
</script>

<template>
    <div class="form-select">
        <div class="form-select-current" @click="toggleDropdown">
            ...
        </div>
        <portal :target-el="'#' + portalId" v-if="showDropdown">
            <div class="form-select-dropdown">
                ...
            </div>
        </portal>
    </div>
</template>

[roshecode]

@LinusBorg I have the same idea as @davejamesmiller described. It would be very nice)

[LinusBorg]

I'm working on it, now that 1.1 is out and the internals are cleaned up.

It might take a while though, I wanna get the API right for different use cases.

[roshecode]

Thanks @LinusBorg ) Your plugin is really useful!

[rickbolton]

Hey @LinusBorg, great work on this package.

Another use case for this would be for an overlay modal on top of another modal. I just tried it and like you explained the portal is re-rendered.

Thanks!

[reinink]

I'd just like to add my 👍 to this request. Using portal for modals would be perfect, however this isn't possible right now when you have more than one modal on a page.

[rickbolton]

@reinink I've kinda hacked it for now by doing the following:

<portal-target name="modal-level-1"></portal-target>
<portal-target name="modal-level-2"></portal-target>
<portal-target name="modal-level-3"></portal-target>

So I now select the different levels depending on whether it could conflict etc. An idea maybe for now? :)

[mattixittam]

I just want to add my use-case for this: I have multiple select dropdowns and tooltips which need to be appended to <body> ideally (or a target-el which is a direct child of <body>), to solve the problem of a container with overflow: hidden chopping them off.

The selects and tooltips are components in a library, so they need to dynamically create their portal-target as they cannot assume one is already present in whatever app they are used in. Portal-vue would have to either use an existing target-el or create it if not present.

For this scenario I really don't care what order the elements are in in the portal-target.

We are now using vue-dom-portal, and were hoping portal-vue would be able to solve some issues we had with that plugin :)

[gewisser]

Faced the task of putting content from different components of vue into one target. This functionality is very necessary.

[reinink]

For what it's worth, I've managed to sidestep this requirement by using v-if for my modals instead of v-show. With v-if, only one modal actually lives within a portal at one time, and everything works as expected. Obviously this is okay with modals (since you only ever have one visible), but may not be a suitable solution in other situations.

[LinusBorg]

I will close this in favour of #76, where I outlined how I intend to solve this.

Further discussion can take place in the new issue. Thanks for everyone that joined in so far!