Investigate portal component

[thepassle]

Reach ui ships a portal component: https://reach.tech/portal/

It appends a node the end of the document body, and inserts some content. This can be useful for dialogs, but also things like a select+dropdown

Perhaps we can use a similar implementation for dialog component, and ship a portal component as well so people can more easily compose widgets such as a select, or even a tooltip once there has been a more clear pattern for it

[Matsuuu]

After running a few tests, wouldn't this be extremely easy to implement, by just appending the element to the document body in construction or connectedCallback?

export class GenericPortal extends HTMLElement {
    constructor() {
      super();
       this.attachShadow({ mode: 'open' });
       this.shadowRoot.appendChild(template.content.cloneNode(true));
       document.body.appendChild(this);
    }
  }

As the MDN says:

The Node.appendChild() method adds a node to the end of the list of children of a specified parent node. If the given child is a reference to an existing node in the document, appendChild() moves it from its current position to the new position (there is no requirement to remove the node from its parent node before appending it to some other node).

I ran a test of creating the element shown above and appending it inside a context similiar to the reach demo, and it seemed to work prefectly.

Is there some edge cases I'm not seeing, or would this be just that simple of a component? @thepassle

[thepassle]

Interesting, if thats all the implementation thats needed 😄 Did you look into the implementation of reach? It would be interesting to compare approaches there.

Some things to think about:

• Removing a portal. Example: open a dropdown menu -> render stuff into the portal -> close dropdown -> how to remove the portal from the body?
• Event listeners. Example:

<div>
  <div>
    <div>
      <generic-portal><button id="btn">click</button></generic-portal>
    </div>
  </div>
</div>
<script>
  btn.addEventListener('click', console.log)
</script>

Are events still attached to btn after moving it around in the dom?

[Matsuuu]

It seems that the Reach portal works on the same premise.

I'll try out different ways to remove the portal and pitch what would be the best for DX.

I'll also try out the event listeners and log my findings here, but they should stay in tact

[Matsuuu]

Tested eventlisteners with the following setup.

<generic-portal>
    <div class="portal-content">
        <p>This content is inside a portal, and therefore able to escape the closure created by it's parent div.</p>
    </div>
</generic-portal>
<script>
    document.querySelector("generic-portal").addEventListener("click", () => console.log("Foobar", this));
</script>

And it seems to work just fine.

What I'm wondering is how this will be used, and from which level styles will be added to the element.

In the above examples, I've added the styles to the document, making them accessible by the element, but what if the styles are in the wrapping view?

e.g.

html`
  <style>
    .my-portal-content {
        position: absolute;
        top: 20px;
        right: 20px;
    }
  </style>
  <generic-portal>
    <div class="my-portal-content">
        <p>Foobar</p>
    </div>
  </generic-portal>
`

Since the styles will in this case be inside a shadow dom of the implementing element (assuming there is one).

It's able to access the styles in the rendering, since it's a slotted element, but after it's moved to the bottom of the document tree, the styles will be gone.

^ the same ofc applies to events too, as you can't access this.shadowRoot.querySelector(".my-portal-content") , because it won't be inside the shadow root anymore

[thepassle]

Nice!

It would be nice to have a playground to try some things out, would you be interested in making a PR with a demo page with some different usecases (maybe even a quick implementation of a select, using generic-listbox)? (If you make a PR, netlify makes a preview deploy, makes it easy to try things out etc)

[Matsuuu]

I'll try to find the time this weekend, but at latest early next week.

I've already created a PoC PR in which I made the above findings but I'll try out making a few implementations and see what happens.

I'll see about creating the select example also in the PR. Should we approach making the select around the native -element to have mobile devices keep the native select's functionality or just build it from the ground up, by creating a div, which when clicked opens a listbox etc. ?

[thepassle]

I'll try to find the time this weekend, but at latest early next week.

No worries, only if you're up for it and have the time of course! 🙂 This discussion has already been super valuable.

I've already created a PoC PR in which I made the above findings but I'll try out making a few implementations and see what happens.

Did you submit the PR to this repo? 🤔 I dont see it https://github.com/thepassle/generic-components/pulls

Should we approach making the select around the native -element to have mobile devices keep the native select's functionality or just build it from the ground up, by creating a div, which when clicked opens a listbox etc. ?

For now lets just go with a simple implementation, just so we can try some things out/see how it works etc 🙂

[Matsuuu]

I've only forked now. I'll make a PR after implementing some test cases :)

[Matsuuu]

I'm creating some test cases currently for the portal.

I was wondering, if we have a situation where :

• We have a web-component with a shadow root e.g. "my-profile-view",
• "my-profile-view" has a portal inside it ( not slotted, so inside the shadow dom)
• "my-profile-view" applies some styling to the portal

In this case the styling will remain inside the shadow root, even when the portal is appended to the end of DOM.

If styles were applied to the portal, they will be most likely applied with a general selector generic-portal, or via an ID/class .profile-likes-portal

In any case, if we wanted to truly escape the portal from the context with the styles, we could copy the styles with the portal. Would this be wanted behavior?

This could be done with something like this:

export class GenericPortal extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
    this.shadowRoot.appendChild(template.content.cloneNode(true));

    const rootNode = this.getRootNode();
    const isInsideShadowRoot = rootNode !== document;

    if (isInsideShadowRoot) {
      const portalRules = this.findStyleRules(rootNode);

      portalRules.forEach(r => {
        // In real life this accessor is naive and shouldn't be used. A check for a sheet with permissions to write should be done
        document.styleSheets[0].insertRule(r.cssText);
      });
    }

    document.body.appendChild(this);
  }

  findStyleRules(rootNode) {
    const { styleSheets } = rootNode;
    const { className, id } = this;
    const componentName = 'generic-portal';

    let styleRules = [];

    for (const ss of styleSheets) {
      const rules = Array.from(ss.cssRules);
      const portalRules = rules.filter(rule => {
        const selText = rule.selectorText;

        return (
          (className && selText.includes(className)) ||
          (id && selText.includes(id)) ||
          selText.includes(componentName)
        );
      });
      styleRules = [...styleRules, ...portalRules];
    }
    return styleRules;
  }
}

What this would do, is copy the styles affecting the generic-portal from the web-component and copying them into the global DOM stylesheets. This means they would also be applied to other portals, if the user uses generic-portal -selector in their css.

This could be circumvented by appending a sort of identifier to our portal ( in the form of an attribute etc. )

Opinion in the style copying etc. @thepassle ?

[Matsuuu]

A slight nudge @thepassle :)

[thepassle]

Sorry for the late reply 🙂

I think the scenario you described should be okay, without the copying of styles. I think the portal should be more of a 'dynamic/adaptable wrapper' component that can be styled from the index.html, and for any other use case its probably good enough to render a web component inside it (so for example if you set the width on the web component inside the portal, the portal should automatically take the width of that). E.g.: The portal should just do one thing: render something to the end of the body. Styling shouldnt be taken care of by the portal, but rather a child of the portal