[lion-button] How to apply class names when extending

[jdelight]

Assuming there will be users migrating to Lion from a (React/Vue/Angular) design system, it's likely that users will already have CSS and a class name convention. E.g.

.acme-button {}
.acme-button--primary { background: blue; }
.acme-button--secondary { background: white; }

So when creating a new <acme-button> component (extending LionButton) - how would these classes be applied to the Lion rendered elements so as to reuse existing CSS.

Most examples of styling I've seen suggest using the :host selector - however using custom class names is a little clearer for other developers.

I'm looking specifically at the LionButton component where it's not entirely clear how to do this (perhaps it's a little easier with others). Is there a way to override the button template?

As suggested here it's beneficial to extend the base class rather than render a lion-button element. But can the template be amended - and crucially how do you avoid "breaking" changes (e.g. destroying important a11y attributes).

In effect I want to merge my custom CSS class names with other attributes from LionButton.

export default class AcmeButton extends LionButton {
  constructor() {
    super();
    this.type = "primary";
  }

  static get properties() {
    return {
      type: { type: String },
    };
  }

  static get styles() {
    return [
      super.styles,
      css`
        .acme-button {
            ...
        }

        .acme-button--primary {
            ...
        }
      `,
    ];
  }
  
  // how to render with custom class names, is something like this possible?
 _buttonTemplate() {
   return html`<button  class=${classMap({ 'acme-button': true, [`acme-button--${this.type}`]: true  })}></button>`
 }
}

customElements.define("acme-button", AcmeButton);

Update: Noticed this potential solution from Material Design Web Components which might actually work for a number of scenarios like this. A protected method on the base class which returns classes to be applied to the element. Anything extending can then override or merge with the base classes.

[jorenbroekema]

With LionButton and also other Lion fields that wrap native fields, it is a little bit special indeed. This is because we spawn the native <button> or native <input> in case of LionInput for example, inside the LightDOM. This is for accessibility reasons, because the field has to be in the same DOM as the label. For button, it's mostly for supporting (native) form submission.

The usual way would be to just override the styles:

static get styles() {
  return [
    super.styles,
    css`
      :host {
        background-color: blue;
      }
    `,
  ];
}

But as you mentioned, it requires you to pull the CSS rules out of your CSS blocks and paste them into :host selector in your extension.

---

The other option is indeed to adjust the template to have the classes applied to them, so you can just copy the ready-made CSS entirely.

static get styles() {
  return [
    super.styles,
    css`
      .acme-button--primary {
        background: blue;
      }
      /** etc. */
    `,
  ];
}

render() {
  return html`
    ${this._beforeTemplate()}
    <div class="button-content acme-button--primary" id="${this._buttonId}"><slot></slot></div>
    ${this._afterTemplate()}
    <slot name="_button"></slot>
  `;
}

Although for your use case I suppose it will be a little different, since the styling applies to the host element, so you need the class added on the host:

constructor() {
  super();
  this.classList.add('acme-button--primary');
}

Which in some ways is simpler.. and you could potentially do something like that to your rendered content as well in the firstUpdated callback.

---

The example from MWC is pretty neat, because it allows you to easily add in your own classes without overriding the template, because you have this class map hook in your component. The problem is that you need such a method for every DOM element in your templates if you want this approach usable everywhere, and you'd also still face the problem that you can't apply this to the host element itself. So I think extending & overriding is still unavoidable.

I get the concerns about breaking changes. If Lion changes something fundamental about the _beforeTemplate (e.g. the name) and you are overriding the render() method, you run the risk of having your button being broken by a lion update.

Extending and overriding may seem scary but it is the main use case for Lion. Methods, props, templates, that are not prefixed with a double __ are okay to override in an extending class, and we will do our best not to break you without the proper semver bump (minor for v0.x.x, major for v1.x.x and up)

[jdelight]

Thanks @jorenbroekema 👍 this helps a lot. I think this is where I was a little confused. There are components where the main HTML is in the shadow dom and others (like Button) where it's in the light dom for the reasons you outlined.
So I was looking at examples of how this is done for components where the _renderTemplate approach can be used and couldn't see an equivalent for Button (because as you say it needs to be the host that's overriden in this case). I'll give this a go thanks 👍