Nested templates not resolving

[evenflow58]

I'm submitting a bug report

• Library Version: 1.0.7

Please tell us about your environment:

• Operating System: Windows 10

• Node Version: 4.6.0

• NPM Version: 3.10.9

• JSPM OR Webpack AND Version webpack 2.1.0-beta.22

• Browser: all

• Language: TypeScript 2.0.9

Current behavior: As described here nested templates do not resolve as expected. Shortcut to gist: here

Expected/desired behavior: If a template has a template both should be resolved.

• What is the motivation / use case for changing the behavior? While the templating is nice and easy to use restricting templates to a single resolution (i.e. only 1 level of templating can be resolved) will limit the extensibility of plugins. It also goes against DRY principles as you'd have to recreate the entire template if you only wanted to change a small part. In the gist above you can see the unfortunate design pattern needed to append the grid's data with bad-app.

[evenflow58]

It should also be noted that slots also do not work inside template and vice-versa. I'm not sure they should as they seem to be elements meant to accomplish similar things so maybe one will be deprecated but if the templating engine were written to allow these to work together it could make for a more easy to use code base. Slots do work inside of slots but you lose all data binding, as noted in the documentation.

[EisenbergEffect]

Slots are part of the shadow dom spec and how they work is outside our control. The template replacement feature was added to handle scenarios that the slot spec didn't seem to cover.

[kvet]

Any news?

[Fedoranimus]

Has there been any update on this?

I'm running into a similar issue where I want to pass a replace-part template down to a child component. Is there a more sane way of doing this?

[adrinr]

We are having the same impediment... Some workaround?

[JontyMC]

Asked a question in the forum and was pointed here: https://discourse.aurelia.io/t/replace-template-in-child-component/745

Is this on the roadmap/being worked on? Seems like it's a fairly standard use case.

[Justin-Lessard]

We're having the same problem.

Any new on this? Does anyone have found a viable workaround?

[artmasa]

Is this being worked? @EisenbergEffect you marked this issue as an enhancement in 2016. Is this being considered for vNext?

[EisenbergEffect]

@artmasa We haven't added this to vNext yet as most of our work there has been around reaching feature parity with vCurrent. However, the vNext compiler has a much better architecture and is generally much easier to extend and add new features to. So, after we get all the basics in place, this seems like something we could address there. @fkleuver What do you think? Is this something that's pretty straight forward for us to add in vNext? Would it be ok if I moved this over to vNext repo as a feature request?

[JontyMC]

@EisenbergEffect this would certainly simplify our nested controls, where we want to provide defaults at different levels. At the moment we need to duplicate code.

[EisenbergEffect]

@JontyMC @artmasa One really cool way to contribute might be for you two to work on a brief RFC for this feature. The vNext work is going on here: https://github.com/aurelia/aurelia and if you create a new issue, there's an RFC template. There are a couple of example RFCs to look at as well. It's nothing super formal, but if we could flesh out some use cases, some examples of how it would be used, etc. then we could have a more in-depth conversation and @fkleuver can think through how it might fit into the compiler. Either of you interested?

[artmasa]

@EisenbergEffect Thanks for pointing us to the vNext repo. While looking at the issues there, there's already a feature request already submitted targeting specifically what I need. The idea is to reuse custom elements and inherit it's functionality on another custom element, but still allow the consumer of the inheriting element to replace templates within the base custom element. This would make extending custom elements so much easier without having to duplicate code and markup. The issue in vNext repo is aurelia/aurelia#479 There's an example using replaceable and another using slot. I really prefer your original idea on replaceable parts; slots have too many limitations and I'm 100% percent with you on not wanting to implement an aurelia slot solution but to adhere to the standard.

[EisenbergEffect]

Excellent. Glad we've got that tracked!