search

aurelia / templating-resources

A standard set of behaviors, converters and other resources for use with the Aurelia templating library.
MIT License
59 stars 55 forks source link

Conditional rendering breaks inside of templates projected through a slot. #384

Closed mxjp closed 5 years ago

mxjp commented 5 years ago

I'm submitting a bug report

Please tell us about your environment:

Current behavior: if.bind and else do not work as expected when used inside a <template if.bind="..."> that is directly projected into the slot of another custom element. When the conditions for if.bind change, elements are not removed or inserted at the wrong position.

Here you will find an example of the above: https://codesandbox.io/s/aurelia-templating-bug-o2f9s?fontsize=14&module=%2Fsrc%2Fapp.html

If the <template if.bind=".."> is removed or the custom element is replaced with a regular html element, it works as expected.

Expected/desired behavior: Elements with if.bind or else should be rendered correctly.

bigopon commented 5 years ago

@mxjp Thanks for filing this issue. This is a known issue with current state of templating, that is view slot is unable to stabilize the range of multiple nesting containerless/template elements. Your example is exactly that: an if (no element) is nested directly under a <template/>, making it fail to locate the range properly. It's fixed in vNext by @fkleuver

For vCurrent, I'm uncertain what can be done, because fixing it could also cause some breaking changes for people who rely on DOM nodes position/count.

A simple work around for the issue is make sure those containerless/template elements are not nested directly under each other, you can see it here https://codesandbox.io/s/aurelia-templating-bug-d5pt4

Thoughts?

cc @EisenbergEffect

EisenbergEffect commented 5 years ago

Unfortunately, this is one of the more rare cases that we couldn't easily fix in the current version. Definitely try the work around that @bigopon suggests. We've got these kinds of cases already addressed in vNext.

Another workaround would be to use native shadow dom on the elements. If the browsers you support don't all have that feature, you can include the shadydom polyfill and put it in emulation mode.

mxjp commented 5 years ago

Thanks for the reply. For now, we are just using an extra div to avoid the problem.