Implement Shadow Part

[jorgecasar]

Could be interesting implement Shadow Parts to be able style Shadow DOM.

We could discuss about part names and which parts we would like to expose.

First approach I suggest is to declare parts with the end of the class name, the part after "__".

For example in the FormControl would be something like:

<div part="group-one" class="form-field__group-one">
  <div part="label" class="form-field__label">
    <slot name="label"></slot>
  </div>
  <small part="help-text" class="form-field__help-text">
    <slot name="help-text"></slot>
  </small>
</div>
<div part="group-two" class="form-field__group-two">
  <div class="input-group">
    <div part="before" class="input-group__before">
      <slot name="before"></slot>
    </div>
    <div part="container" class="input-group__container">
      <div part="prefix" class="input-group__prefix">
        <slot name="prefix"></slot>
      </div>
      <div part="input" class="input-group__input">
        <slot name="input"></slot>
      </div>
      <div part="suffix" class="input-group__suffix">
        <slot name="suffix"></slot>
      </div>
    </div>
    <div part="after" class="input-group__after">
      <slot name="after"></slot>
    </div>
  </div>
  <div part="feedback" class="form-field__feedback">
    <slot name="feedback"></slot>
  </div>
</div>

Related PR: #1138

[jorenbroekema]

@jdelight Brought up some good points in the PR. I think the 3 ways he outlined are correct indeed. To summarize:

1. Extend component. Overwrite static get styles / render methods where needed. Use case: Design System (DS) built on top of lion. Disadvantage: more maintenance in the DS, and with overriding render, could mean that you might miss some updates from lion side e.g. when some extra semantic html is added for a11y for example. Less likely with styles as CSS cascades and you'd always include the super.styles, with render this is not always practical..
2. CSS Parts. Style exposed parts directly without the need to extend. Use case: Using Lion elements directly, but also in a DS it saves having to create an extension, when a wrapper with some CSS to address the parts might be enough. Disadvantage: requires DS to unexpose parts if they don't want their app/feature developers to be able to use the parts to make variations that are not intended by the DS. Need a POC on this to see how unexposing parts would work, @jdelight suggests also looking at exportparts.
3. CSS custom properties. See recent Chrome dev summit. Use case: only expose CSS rules that you want to expose, and have stricter Design Compliance in your DS. Disadvantage: more CSS custom props needed than the amount of parts that would be needed to create the same flexibility.

I agree with @jdelight that 3 seems like the best way for design systems, and this will always be the main use case for Lion. Yes you'll need more CSS custom props, but parts seems like more maintenance and tricky to get strict design compliance for our users that build design systems on top of lion.

[jorgecasar]

Ummm, I not sure how to detect if the class is a Lion or extends from it and decide to check exposeParts or not.

Are you thinking in something like this?

class LionPartExample extends LitElement {
   static get exposeParts() {
      return this.name === 'LionPartExample' ? ['one', 'two'] : [];
   }
   
   render() {
      return html`
         <p${this.renderPartOne()}></p>
         <p${this.renderPartTwo()}></p>
      `;
   }
   
   static checkexposePart(name) {
      return  this.exposeParts === 'all' || name in this.exposeParts();
   }
   
   renderPartOne() {
      return this.constructor.checkexposePart('one') ? html` part="one"` : '';
   }
   
   renderPartTwo() {
      return this.constructor.checkexposePart('one') ? html` part="two"` : '';
   }
}

Without override:

class DefaultPartExample extends LionPartExample { }
DefaultPartExample.exposeParts(); // []

Override exposeParts;

class OnePartExample extends LionPartExample {
   static get exposeParts() {
      return ['one'];
   }
}
DefaultPartExample.exposeParts(); // ['one']

Using part you can access to the node attributes, then you have to expose all attributes as part to be able to style it. For example, in the calendar, we have to expose "today", "disabled", "selected", etc... Here you have the full example:

https://github.com/ing-bank/lion/pull/1138/files#diff-878ed2b6426fafeb430a5c460dc4a1f65d2901a98b33d2f2e77d2cdddd3b7565

[jorenbroekema]

Well I hadn't thought that far ahead yet on how to detect whether a class is a Lion class or an extension, but yes the idea would be to have something long the lines of like:

class LionField {
  static get exposeParts() {
      return this.isLionBaseClass() ? 'all' : [];
   }
}

I'm thinking LionField but perhaps we need a higher level class, perhaps our re-export of LitElement itself.. so the logic applies to all of lion elements. Not sure...

And then yes like you suggested, the rendering of the part would be conditional on whether the name of the part is included in the array or if the exposeParts returns the shortcut for all parts ('all' or true or similar).

A naive implementation of isLionBaseClass() could be this.constructor.name.startsWith('Lion') but the problem is that bundlers, transpilers, compilers, don't support this because when you do the transpilation/compilation, very often the name of the class is changed or removed :. So we need a smarter way there, not sure if there is one... if it's not possible we can do the blacklist way, so all parts always exposed (starting at lion), and in design systems you can opt-out. So we just reverse the proposal in that way 🙈

[jorenbroekema]

I discussed this with the team a bit. Seems like we're in favor if we can do the whitelist approach where by default parts are exposed on Lion base classes, but unexposed by default on extension classes, and you have to use the "parts exposure API" to address which parts you want to expose in your extension. It's a bit tricky with regards to technical implementation though.. will need to think of something smart.

---

If the above is technically not possible, we can do the blacklist approach where all parts are exposed.

Disclaimer: There is no consensus yet in the team that this would be an "acceptable" solution, since there were some objections.. so take with a grain of salt and just food for discussion.

If, on the extension, you don't want any parts exposed, you can just write a mixin:

const NoPartsMixin = (superclass = class {}) => class extends superclass {
  static get exposedParts() { 
    return [];
  }
};

class WoofInput extends NoPartsMixin(LionInput) {}

Maybe there's even a better API for this but it's the best I saw in our team chat :P feel free to suggest something better. Keep in mind our design system extension inside ING, and probably many others, are strict. This means they need parts to not be exposed, because they don't want their users to be able to "abuse" parts to create variations that are not design-compliant.

[jorgecasar]

I created a ShadowPartsMixin and I included it on FormControlMixin. You can see a demo in Theming/Combobox, there are 3 comboboxes:

1. lion-combobox, styled using Shadow Parts
2. parts-none-combobox extended from LionCombobox without exposeParts
3. parts-all-combobox extended from LionCombobox with exposeParts

[jorenbroekema]

I just realized today that a NoPartsMixin implementation could also be added on the base class of the extending design system.

import { LitElement as _LitElement } from '@lion/core';

const NoPartsMixin = (superclass = class {}) => class extends superclass {
  static get _exposedParts() { 
    return [];
  }
};

export class LitElement extends NoPartsMixin(_LitElement) {}

and then in a component, opt-in to the parts where needed.

Seems pretty acceptable to me.