Nested templates not resolving

aurelia / templating

An extensible HTML templating engine supporting databinding, custom elements, attached behaviors and more.

MIT License

116 stars 104 forks source link

Nested templates not resolving #493

Open evenflow58 opened 7 years ago

evenflow58 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Any news?

fedoranimus commented 6 years ago

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 commented 6 years ago

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

JontyMC commented 6 years ago

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 commented 6 years ago

We're having the same problem.

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

artmasa commented 5 years ago

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

EisenbergEffect commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

Excellent. Glad we've got that tracked!