lwc 301 composition

Composition is the preferred method to tackle your component tree.

In LWC, inheritance doesn't work well because you are limited to a single extension. Currently, there is no way to allow for multiple mixin inheritance like other frameworks. In other words, it can be very limiting to design for inheritance due to current limitations. You are setting yourself up for headache going this route, if you are coming from a more mature front-end framework.

There are two main topics:

• Flexipage composition (high level)
• LWC Template composition (low level)

Flexipage Composition

Salesforce wants you to be using the Flexipage as the container for your SPA. While actual SPAs written with LWC still have their place, there are too many advantages of Flexipage composition to disregard as a primary tool under your tool-belt.

Many declarative tools (Component Visibility, Dynamic Actions, Dynamic Forms etc) can only be accessed at the App Builder level and your LWC solutions can be scaffolded into those, saving you time to worry about the critical user journeys rather than the implementation details. Leveraging the flexipage also allows you to make rapid updates from user feedback with very little code.

Understandably, coordinating multiple LWCs on a single Flexipage can be challenging. Some of those challenges (inter-component comms) are addressed in other sections.

For now, understand that Flexipage Composition allows for you to target user experiences in silo-ed Lightning Web Components. The emphasis is mine, it wants you to design individual components in the grand scheme of things.

This, by virtue of its intended use, makes LWC almost second class citizens to the overall tooling landscape and that is totally OK! This is the direction where SFDC is going and it would be prudent to align to that.

LWC Template Composition

If you are using Flexipage composition to tackle high level solution (layout) design, this section will be better aligned.

When thinking about individual LWC composition, consider the rule of 3. Try to keep your component tree to 3 levels, including base components. This is not counting container/orchestration components: top level parents whose sole purpose is to drive data down to children and to coordinate events. Arguably, if you're using flexipage composition then that is your top level container. But I digress...

For the above, consider the following:

parent
├──baseComponentOne
├──childOne
└──childTwo
   ├──baseComponentTwo
   └──grandChild

Having a simple component tree makes event bubbling and communication to siblings more predictable and maintainable. If you leverage Flexipage Composition, it's relatively simple to create additional components in the form of additional LWCs, dialog / modal pops, component visibility, nesting components in the native tab component, or a combination of any of these.

Note: If grandChild is a custom "base" component authored explicitly for reusability, we can ignore the depth there because from the perspective of the parent, your specific implementation, it is simply another "base" component to reuse.

Note 2: The Hierarchy Communication section covers knowledge around how to coordinate comms from parent to child or vice versa. The next section Inter Component Communication will cover sibling and inter component communication, which is needed for complex lwc design.

Finally, the last topic relating to composition is better discussed in API Design where we will cover concepts like api design in the form of slots, properties, methods and touch on events as well.