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:
github.com
if (pair.key === 'insertBefore') {
assert(
`Can only pass null to insertBefore in in-element, received: ${JSON.stringify(
pair.value
pair.value.type === 'NullLiteral' || pair.value.type === 'UndefinedLiteral'
Then it seems to ‘just work’. I can pass an element to
insertBefore
, and
{{#in-element
will render its content before that element. Perfect!
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
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.
