[Feature Request] Make templates more extendable

[CubLion]

Decouple styling and logic

Let's make it easier for Sub Classers that want to extend a certain component to adhere to their Design System.

In most cases, extending a component comes down to:

1. overriding/extending the _xTemplate (for instance _inputTemplate) functions that define markup
2. overriding/extending the static get styles with Design System specific styles

Point 2 is straightforward.
For point 1 though, we currently have a lot of places where we mix logic and markup/styling. An example (slightly adjusted) currently in https://github.com/ing-bank/lion/blob/master/packages/calendar/src/LionCalendar.js:

Current implementation

_previousButtonTemplate(previousMonth, previousYear) {
    const previousButtonTitle = `${this.msgLit(
      'lion-calendar:previousMonth',
    )}, ${previousMonth} ${previousYear}`;

    return html`
      <button
        class="calendar__previous-month-button"
        aria-label=${previousButtonTitle}
        title=${previousButtonTitle}
        @click=${this.__myPrivateHandler}
        ?disabled=${this.isPreviousMonthDisabled}
      >
        &lt;
      </button>
    `;
}

If we can make the following assumptions:

• Lion layer takes care of logic like:
  • what should happen when we click on this button?
• Lion layer takes care of accessibility (including translations of purely functional aspects, like an alternative text for navigating to previous month), similar to how native ui elements in the platform would do this.
• Subclassers should not use private methods (__myPrivateHandler above)
• Classes on elements should never be used as functional hooks and can be interchanged for styling purposes. When our component code needs a reference to a certain element, it's best to give this element a 'data-' attribute that the extending party is required to implement

We can approach this using the spread directive: https://open-wc.org/developing/lit-helpers.html#spread-directives.

Decoupled implementation

_previousButtonTemplate({ prevButtonProps }) {
  return html`
    <button
      data-ref="prevButton"
      class="calendar__previous-month-button"
       ...=${spread(prevButtonProps)}>
      &lt;
   </button>
`;
}

An extension implementation

Let's say we want to create our own Material Design calendar. Our template function would look like:

_previousButtonTemplate({ prevButtonProps }) {
  return html`
    <md-button
      data-ref="prevButton"
      class="md-calendar-next-button"
       ...=${spread(prevButtonProps)}>
      &lt;
    </md-button>
  `;
}

As you can see, we abstracted away the logic in this template, so the extending party only has to worry about applying the right styles (in this example this means the md-button and the class supplied).
For clarity and consistency, a "data-ref" attribute was added, that makes it directly clear where the prevButtonProps should be applied.

Of course, our logic has moved to a different place now:

const previousButtonTitle = `${this.msgLit(
      'lion-calendar:previousMonth',
)}, ${previousMonth} ${previousYear}`;

const prevButtonProps =  {
      'aria-label': previousButtonTitle,
      'title': previousButtonTitle,
      '@click': this.__myPrivateHandler,
      '?disabled': this.isPreviousMonthDisabled,
}

// WIll be called anywhere from within a template
return html`
  ... 
  ${this._previousButtonTemplate({ prevButtonProps })}
  ...
`;

Advantages

This approach makes the Lion layer more flexible: it allows functional changes without breaking the extension layer.

• When an accessibility update needs to be done (a recent example is the datepicker input that needed to get rid of aria-haspop="dialog" if I'm right), it can be done in the Lion layer without having extra work or (unknown) technical debt on the extension layer.
• Also, if we decide to change the name of __myPrivateHandler, we can do so without breaking our extension layers.

What if we still need overrides?

If the button should call a different method, the extending party is still able to do so. Same for translations etc.

[jorenbroekema]

I agree with the proposal to decouple logic from templates for the reasons you point out :).

Perhaps we could start with going through everything that does return html in our codebase and make a list of templates that are not properly decoupled. Then it's easier for people to pick up work on this one by one, as it might be quite a lot to do all at once.

[jorenbroekema]

Closing as enhancements with votes needed. Our workflow with enhancements is that we close them and have people vote on them, then we sort our enhancements by most votes to see which ones should be prioritized: https://github.com/ing-bank/lion/issues?q=is%3Aissue+is%3Aclosed+label%3Aenhancement+sort%3Areactions-%2B1-desc