Why does {{#in-element}} only allow null/undefined for insertBefore

Questions General
1

The docs for {{#in-element}} say:

insertBefore – by default the DOM element’s content is replaced when used as destinationElement . Passing null to insertBefore changes the behaviour to append the block content to the end of any existing content. Any other value than null is currently not supported.

Being able to pass an element reference to insertBefore would be very useful for my use case. So I was trying to work out why this restriction exists.

If I comment out this assertion in the template compiler:

Then it seems to ‘just work’. I can pass an element to insertBefore, and {{#in-element will render its content before that element. Perfect! :tada:

But… I assume there must be a reason this restriction was introduced. Does anyone know why? I can’t see any mention of it in RFC287 which promoted in-element to public API :thinking:

3 Likes
2

So i can’t remember fully but im fairly sure glimmer-vm supported insertBefore but there ember didnt support it and that would have been an additional RFC so it was explicitly made to only accept null. It looks like this assert can likely be removed now.

Im just speculating but i remember there being a thing with ember and glimmer that cached the dom and if the dom was changed by something non ember it could cause the rendering to error as the node would no longer match the cache.

if you give me more context i might be able to help with an alternative.

2 Likes