Scope

We have several components that have identical props, behavior or events, e.g. all buttons, all links or form (wrapper) components.
Currently this identical behavior is maintained, synchronized and tested manually for the most part and differences are easy to miss. We call it redundant puzzles.

Therefore, we want to give some software design patterns a shot in order to extract the behavior introduced in #3009 which is duplicated in like 6 components.

While inheritance would probably be the best choice, stencil does not support it, however it seems

• Composition, e.g. Error On Any Inheritance ionic-team/stencil#1060 (comment) and Error On Any Inheritance ionic-team/stencil#1060 (comment)
• Decorators, e.g. https://medium.com/stencil-tricks/stenciljs-creating-custom-decorators-d4d8e78c5717

are possible.

Some 3rd party custom decorators:

• @ConstructibleStyle (https://github.com/bodinaren/stencil-constructible-style) could replace manually calling attachComponentCss() in each render() lifecycle
• @ClickOutside (https://github.com/jarrvis/stencil-click-outside) is something we got at least in p-popover, p-select-wrapper and p-multi-select

Not sure if they would could be applied 1:1 but at least they can be used for reference.

Notes

• We shouldn't use 3rd party custom decorators due to maintainability risks but we can take them as blueprint to integrate them into our code base.
• If we like the results of this Spike we can already implement it for some scenarios and/or create follow up issues
• feat: add support for reactive controllers ionic-team/stencil#3162
• Feature Request : @Props OR component inheritance ionic-team/stencil#2844
• feat(@Mixin): new decorator ionic-team/stencil#2921
• https://gist.github.com/snaptopixel/82bc6b6e35c6a4a4c4127941242a7039#file-component-tsx-L94-L140
• https://lit.dev/docs/composition/component-composition/
• https://lit.dev/docs/composition/mixins/
• https://lit.dev/docs/composition/controllers/
• https://gist.github.com/menosprezzi/9d4de98960d343a4283e268073402b6c

Acceptance criteria

• Decorators and Composition are evaluated in how they can help us to reduce the "redundant puzzles"

Conclusion

• stencil decorators like @Prop, @Watch and @State need to stay in the stencil components, otherwise these don't work (most likely because of what happens in the stencil compiler which extracts decorated members only from components)
• @use decorator mixes objects or classes into the stencil component, duplicate members/functions get overridden because of prototype merging, but this could be worked around with proper typing like prefixing lifecycle hooks with _ like _connectedCallback which are then called via mixin
• reactive controller pattern hooks into lifecycles with one controller instance per component instance, no overriding or merging
• extracting a type or interface for shared props works (e.g. class Button implements IBaseButton) but optional modifier doesn't force one to specify them which has impact on typings in wrappers, however, this could be corrected upon wrapper generation
• demos: [SPIKE]: Software Design Patterns (Issue/3016) #3030
• nice description from lit docs

Component composition is the process of assembling complex components from simpler components. A component can use subcomponents in its template. Components can use standard DOM mechanisms to communicate: setting properties on subcomponents, and listening for events from subcomponents.
Although component composition is the default way to think about breaking a complex Lit project down into smaller units, there are two other notable code patterns useful for factoring your Lit code:
Reactive controllers are objects that can hook into the update lifecycle of a Lit component, encapsulating state and behavior related to a feature into a separate unit of code.
Class mixins let you write reusable partial component definitions and "mix them in" to a component's inheritance chain.
Both mixins and reactive controllers let you factor component logic related to a given feature into a reusable unit.