use of template parts in recursive templates

[reinholdk]

To render a tree view, I have built a custom element with the following recursive HTML template.

treeview.html

<template>
  <ul repeat.for="item of items">
    <li>
      <div>
        <template replaceable part="item-text">
          <span>${item.text}</span>
        </template>
      </div>

      <treeview items.bind="item.children">
        <!-- how to pass the part "item-text" to the recursive call of the template -->
      </treeview>

    </li>
  </ul>
</template>

Users should be able to overwrite the default text rendering by providing a custom HTML template. For the top level items, this can be easily achieved using a template part (called "item-text" in my example). Is there a way to pass the same template to the recursive instantiation of the element so that the text of the children is rendered in the same way?

[Alexander-Taran]

stale from 2015 no discussion, no planned actions

[Alexander-Taran]

@fkleuver is going to look after this for vNext

[fkleuver]

I haven't actually tested this, but from a compiler/renderer perspective it could potentially be accomplished like this:

<template>
  <ul repeat.for="item of items">
    <li>
      <div>
        <template replaceable part="item-text">
          <span>${item.text}</span>
        </template>
      </div>
      <treeview items.bind="item.children">
        <template replace-part="item-text">
          <template replaceable part="item-text">
            <span>${item.text}</span>
          </template>
        </template>
      </treeview>
    </li>
  </ul>
</template>

A single replace-part can be used by multiple replaceable controllers in the custom element template. By wrapping a replaceable inside a replace-part with the same name inside the custom element declaration, what this more or less says is: Get the replace-part template provided by the parent element (one treeview up) and replace both replaceables with it. Now the passed-through replace-part is both visible where it's meant to be, and also wrapped inside a replace-part for getting passed to the child

What's important here is both the compiling and rendering order - I'm not sure yet if it works in vNext and need to test it. In the meantime, two questions:

• Did I understand the scenario correct?
• If so, do we in fact want to support this if it's possible (seems like potentially confusing)?

[Alexander-Taran]

@reinholdk ??