Design Patterns and Best Practices to build reusable Lightning Web Components

In this session we talk about Design Patterns and Best Practices to build reusable Lightning Web Components. Creating modular and reusable components is the key to creating scalable applications and must be incorporated during the app design phase itself, But did you know that over modularizing can be dangerous too?

In this session, we’re going to go over some best practices and design patterns when it comes to

  • Component Architecture and Composition
  • Styling Reusable components
  • Sharing components between LWC and LWC OSS
  • Packaging LWC and LWC OSS component

Reusable LWC components

Modularity is key to creating a scalable application by reusing components. We rarely write code that is abstract enough to be reusable everywhere. You should write components not to be reused out of the box, but to be abstract and composable enough to serve that purpose in a variety of implementations.

Component Composition

Components are the building blocks of a page. We should consider following point before dividing the components in LWC

  • Level 1: Based on its functionality
  • Level 2: Based on its reusability : Passing attributes becomes a pain when you need to pass lots of inputs to the component. Consider passing objects as parameters instead of having multiple attributes.
build reusable Lightning Web Components

Other considerations for Component Attributes

  • Make sure you document attributes, and object structure thoroughly and don’t overuse this as this can be hard to understand/configure.
  • Pay extra attention to public properties/function/events naming so that you don’t break the signature of shared components
  • Avoid booleans when there could be more options in the future.

Dividing Components base on Server Communication

  • Don’t lock a low-level component with an Apex endpoint.
  • Try to move server communication in upper layers when possible.
  • A reusable component should be as dumb as possible.

Considerations for App Builder

Components exposed to Lightning App Builder should be able to stand on their own. Over-modularizing components for App Builder leads to unnecessary usage of the publish-subscribe pattern. Compromise between the number of components in which you divide the page and the overhead of their communication mechanisms

Event Communication in LWC

Avoid using Lightning Message Service or pubsub when not needed

Event Communication in LWC
  • Avoid using LMS or pubsub when not needed
  • Use LMS or pubsub only when there is no common ancestor that you control

LWC Best Practices

  • Use UI API Wire Adapters and Lightning Base Components
    • Gives the admin the opportunity to configure your components without modifying code by configuring lists views, record layouts.
    • If required don’t hesitate to restrict your components visibility to certain objects
  • Think whether the component needs to be tied to an object, or can it be object agnostic
    • Don’t use static references
    • If needed, create object agnostic classes
  • Extract utility methods outside your LWC components
    • LWC components should only deal with UI-related logic.
  • Favor public properties over public methods
    • Properties can be set directly in the template, while a method requires the consumer to render the component first, retrieve it back from the DOM, and invoke the method

Component Variations

  • For component variations that are structurally different, use multiple templates
  • Use Slots to create component variants, when structure is dynamic

Styling Reusable Components

LWC encapsulates and isolates a component’s stylesheet. Does it mean it is hard to style a child component from a parent?

  • Spend some time at design time to think about possible variants of your component.
  • Use CSS Custom Properties for custom styles
  • Use Styling Hooks to override styling of Base Components.
  • Favor Styling Hooks and CSS Custom Properties over component attributes.

Error Handling

Error Handling in Reusable components

  • Adopt a common error reporting strategy for your components.
  • If your component is not standalone, throw errors to the parent component.
  • Create a reusable errorPanel component across the entire project.

Accessibility

  • You’re creating reusable custom elements
  • Reflect properties as attributes
  • Ensure the components expose relevant ARIA Attributes
  • If you’re using IDs for any HTML Elements in your component, accept it as an attribute.

Distributing Reusable Components

  • LWC components can be added to Managed, Unmanaged, Unlocked packages.
  • Currently you cannot embed an LWC from a Managed package in your own component.
  • Use Unlocked packages without namespace to share reusable components

Recording

YouTube video

Please note that we have limit of 200 attendees that can join the online sessions. However, recording will be posted on our YouTube channel. Please subscribe our YouTubechannel to get notification for video upload.

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates.

He is a active blogger and founder of Apex Hours.

Articles: 461

Leave a Reply

Your email address will not be published. Required fields are marked *