[WIP] [FEAT] converts -in-element to -render-portal

[runspired]

Tracking PR, requires bumping glimmer first, still figuring out why tests are failing locally.

[mixonic]

@runspired can you provide some context and/or links to other issues related to this?

[mixonic]

Looks like glimmerjs/glimmer-vm#334 is the upstream item related to this.

[krisselden]

This should be relabeled as a FEATURE

[mitchlloyd]

@runspired I was curious about using -in-element in Ember Islands, but first wanted to understand more about the deficiencies you listed in the related issue:

in-element deficiencies

• no support for renderInPlace
• no ability to move the DOM from one remote target to another remote target or from a remote target to in-place.

I spiked a change to Ember Wormhole using -in-element to learn more: mitchlloyd/ember-wormhole@a70eea5

So said another way, it seems the issue is that Ember Wormhole guarantees that the yielded DOM will remain stable when changing the destinationId whereas -in-element does not. For 99% of use cases this is probably fine, but it's definitely a breaking change. Awesome that you're taking this on!

The wormhole concept has often been referred to as a "portal" or "portal-ing" in other frameworks and in talks. I'm also particularly partial to the game Portal.

I wanted to weigh in with a strong preference for the name in-element over render-portal. in-element might not be as fun as render-portal but {{#in-element sidebar}}... expresses the behavior better than {{#render-portal sidebar}}.... If we are leaning toward render-portal then I'd like to suggest render-portal-2. Most critics agree that that although Portal was innovative, Portal 2 is a stronger game overall 😄

[runspired]

@mitchlloyd

If we are leaning toward render-portal then I'd like to suggest render-portal-2. Most critics agree that that although Portal was innovative, Portal 2 is a stronger game overall

LOL

I wanted to weigh in with a strong preference for the name in-element over render-portal

so @rwjblue's objection to in-element once my proposed changes were in place was more or less "but if you can render-in-place this name makes no sense", which I sort-of-ish agree with.

[mitchlloyd]

I'll try to save any more of my bike-shedding for an RFC, but I do want to clarify:

but if you can render-in-place this name makes no sense

It looks like this change is all about making sure the DOM stays stable and there is nothing specifically about "rendering in place". I believe these assertions show the primary issue you're solving: https://github.com/tildeio/glimmer/pull/334/files#diff-793e7c01665aa0549d057403a3859c15R256. Is that true or am I missing something?

[runspired]

@mitchlloyd if you look at those assertions you will notice that when the element is null the assertion always tests that it was rendered in place :P (which is also a requirement of wormhole)

(this is also discussed in the conversation for that PR)

[pixelhandler]

@runspired will this need feature flags as well?

[homu]

☔ The latest upstream changes (presumably #14633) made this pull request unmergeable. Please resolve the merge conflicts.

[mmun]

I believe this should be closed as the discussion has moved to emberjs/rfcs#287. Let me know if I missed something and need to reopen.