Planning for Version 3.0: Removal of Base Classes

[zeroedin]

A place for a discussion around the removal of Base classes.

We had good intentions with the Base classes, but we have been leaning towards their removal where it makes more sense to replace shared logic with controllers.

However there are certain cases where lighter weight components such as pf-label, pf-badge that might not need or have any logic to abstract to a controller, whereas components like pf-tabs and pf-accordion do.

An example of this abstraction can be found in the tabs controller PR #2577

There is a couple questions I asked there:

Answer question: Should we reintroduce BaseClasses with an implementation using the TabsController? ( I have this saved as a stash atm, need to have a conversation regarding this approach and breaking changes in general). If we reimplement BaseTabs using TabsController should pf-tabs extend this BaseClass or should it extend from LitElement given discussion here: #2578

I am now working on the simple pf-banner component and I'm hesitant to create Base classes for the component. #2579

Do components like this that lack the complexity need to provide that surface to extend upon? Does adding the Base classes in turn increase the overhead of maintenance of those components long term?

[bennypowers]

We've seen that exporting base classes from pfe can cause headaches when types don't line up or where features are not exactly congruent, and in other circumstances. Having each component start from LitElement helps to 'level the playing field' or 'align expectations' in that the type of the base class is uniform, there's less docs to look up, less need to go spelunking in the base class code to remember what the name of that superclass method or property was, etc.

So from that perspective, alternatives to base classes are preferred:

• reactive controllers (for 'has-a' relationships)
• directives (for templating)
• mixins (for 'is-a' relationships, but suffers from many of the same issues that plague base classes)

But duplicating templates and class logic isn't very DRY!

I think it's worth paying that price to avoid the maintenance / complexity problems described above. As the design systems mature, we can work in a measured way to reduce duplication of code, but that shouldn't be the top priority - how often will <pf-tabs> and <rh-tabs> coexist on the same page in such a way that a few extra bytes of JS will make all the difference?

[bennypowers]

👉 Consider the following as initial brainstorming, rather than hard-and-fast rules for immediate implementation 👈

There will be times that we will prefer to express an "is-a" relationship without duplicating code. A case that jumps immediately to mind is text-field inputs. In those cases, we will always want to set up and sync up element internals and expose aria and validation apis on the element instance.

Although mixins are cumbersome and retain some of the abovementioned issues with inheritance, I think it makes sense for pfe-core to ship mixins which fulfill the following criteria:

• Mixins represent features (like text input validation)
• Mixins do not represent UI patterns (like typeahead search with chips)
• Mixins have no template or styles

So no AccordionMixin because that's equivalent to BaseAccordion and would likely be coupled to the shadow DOM, but perhaps we'd choose to ship an ActiveItemMixin (or some such), which would expose RTI/select controller apis on the element instance. (this is just an example, we may choose not to ship ActiveItemMixin specifically)

[zeroedin]

choose to ship an ActiveItemMixin (or some such), which would expose RTI/select controller apis on the element instance.

Definitely would like to explore this more and how we can break some of the commonalities between components that have "active" tabbable/keyboard navigation state. Maybe a mob programming sesh during office hours.

[bennypowers]

IMO We should seek to do as much as possible with controllers and directives, and only implement mixins when a clear need presents itself

[bennypowers]

Tabs

[zeroedin]

PR: #2577

[bennypowers]

Accordion

[bennypowers]

Tile

[bennypowers]

Card

[brianferry]

#2586

[bennypowers]

Icon

[bennypowers]

Label

[bennypowers]

Button

[bennypowers]

Badge

[bennypowers]

Switch

[bennypowers]

Avatar

[bennypowers]

Spinner

[bennypowers]

Tooltip

[bennypowers]

Clipboard Copy