Update for insertBefore API change as per RFC287

[simonihmig]

• enforces insertBefore=null as only allowed value
• Adds implementation for default replace semantics

This is a breaking change!

Closes #5

To Do:

• Rebase after Ember Update #6 is merged
• Decide if supporting pre-Glimmer versions using ember-wormhole is still worth the effort
• Prepare to remove the -in-element-replace component from the build for Ember versions with public in-element support
• Refactor to use the helper approach

[rwjblue]

@simonihmig - Have you considered using a helper instead of a component? I think it has the right semantics...

I made a demo Code Sandbox with some basic tests here.

import { helper } from "@ember/component/helper";

export default helper(function clearElement([element] /*, hash*/) {
  while (element.firstChild) {
    element.removeChild(element.firstChild);
  }

  return element;
});

[simonihmig]

Have you considered using a helper instead of a component? I think it has the right semantics...

Yes, indeed I thought a while about it, but chose to use a component as I was not so sure if a helper would be the right abstraction here. Specifically, as it has no rendering related lifecycle hooks, I was not sure if it was safe to assume when it will run related to -in-element, if there could be some (future) Ember optimizations (caching, timing, lazy evaluation, what the heck) that could render those assumptions void etc.

I made a demo Code Sandbox with some basic tests here.

Ah, that looks really nice! What I specifically like here, being related to what I said above, is that by calling the helper as the target argument for -in-element and returning the element from the helper, we actually do have this guarantee effectively that the helper will have run before -in-element can do anything!

Will refactor my implementation later, thanks a bunch! 🙏

[rwjblue]

No problem! Was fun to hack on 😃.

[rwjblue]

Specifically, as it has no rendering related lifecycle hooks, I was not sure if it was safe to assume when it will run related to -in-element, if there could be some (future) Ember optimizations (caching, timing, lazy evaluation, what the heck) that could render those assumptions void etc.

Right, the thing about my implementation in the demo is that the private -in-element helper is passed the element by way of the helper. This ensures that by the time -in-element operates on it, it will have been cleared. It also guarantees that if the bound element value updates, the helper will be re-triggered and clear contents again (essentially with the same timing as if you had used {{-in-element this.someElement}} directly). Since -in-element and in-element are both permanently stable until the bound first argument changes, we have exactly the same stability guarantees with the helper solution that we do with in-element directly.

[simonihmig]

@rwjblue updated the PR with your helper approach. Ready for another review, if you have the time!

[rwjblue]

Looks great!