-
Notifications
You must be signed in to change notification settings - Fork 306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for template cascading #315
Comments
Another approach could be about referencing templates (so they could be re-used across the document), similar to how resources work for XAML templates. 😋 <template name="person-card-template">
<mgt-person-card inherit-details>
<template data-type="additional-details">
<div>My additional details</div>
</template>
</mgt-person-card>
</template>
<template name="loading-template">
<div>loading...</div>
</template>
...
<mgt-person template-loading="loading-template" template-person-card="person-card-template"...>
</mgt-person>
<mgt-agenda template-loading="loading-template">
</mgt-agenda> |
Yeah, template referencing also makes sense in addition to cascading. I don't think it solves the issue alone as you still have to define template in a template |
After a good chat around the various approaches, we have decided to go with approach 2, with |
Description
The toolkit components should allow templates to cascade to children components to avoid multiple levels of re-templating.
Rationale
For example, to template parts of the person-card, the current approach forces the developer to define a template in a template. This also makes it difficult to use the
templateRendered
event as the developer needs to assign the event multiple times at each level.This proposal simplifies defining templates to children components by allowing the developer to define them higher up.
Here is an example on how to update the
additional-details
template on amgt-person-card
today:person-card
template onmgt-person
mgt-person-card
.mgt-person-card
, the developer defines a newadditional-details
templateNote: I've also included a loading template in this example for completeness which will become relevant in the solutions below.
Preferred Solution
I've been thinking about the solution to this problem for a while now and I've outlined how my proposed solution has evolved here
Approach 1
This approach allows all templates to cascade down to the children of the component. Any template that is defined on the parent component would be passed down as templates to all the children components. :
In this scenario, the
mgt-person-card
would get all templates defined for the parentmgt-person
.This approach is very simple and straightforward. It also allows templates to be defined at the root element and to cascade to any component in the tree. However, this approach also introduces several issues:
additional-details
is intended for themgt-person-card
component.loading
I believe these issues make this approach a non-starter and that is why I continued thinking about the problem.
Approach 2
This approach defines a new attribute on the template element:
data-part
. Thedata-part
attribute values would be defined by the parent. For example, templating just theadditional-details
template of the person card in the person component would look like this:Where
mgt-person
has mapped the valueperson-card
to themgt-person-card
and therefore all templates withdata-part="person-card"
would cascade down to themgt-person-card
.This solution is not much more complex than solution 1 but addresses the issues from solution 1 by scoping the template to a specific part. However, templates only cascade a single level.
Approach 2.5
If we want to take this even further and solve the cascading issue of solution 2, the
data-part
attribute could act as a selector (similar to CSS selectors).For example, imagine the scenario of templating the person-card inside a person inside the agenda component. Ex:
Here,
data-part="attendee > person-card"
applies the template to themgt-person-card
inside themgt-person
component used for the attendees in the agenda.And if we wanted to have the flexibility of Solution 1,
data-part="*"
could act as a selector for all components.What about the
templateRendered
event?So far, we have not addressed how the
templateRendered
event would work. Today, the developer needs to register the event multiple times on the component:The solution here is for the event to bubble up through the children components and contain the
data-part
attribute in its details so the developer can confidently identify which template was rendered, Here is how I'd rewrite the event listener:The text was updated successfully, but these errors were encountered: