Motivation

The components included in this repo are designed to solve a few high level problems with LWC in general.

Complex component communication can be difficult to design with consistency

Natively, there are only a few officially documented ways for component communication:

1. Same component tree:
   • 
2. Different component tree:
   • Use Lightning Message Service.

Alternatively, roll your own messaging system (even though it's an aura article, the design patterns still apply).

Since there is currently no first-party supported state management lib (Redux, RxJs, Context API w React Hooks etc), we are left to our own devices.

My solution to reduce this friction?

messageService, which itself isn't a state management lib, but provides a consistent design pattern for just component comms until a first-party alternative is developed.

Datatables are useful but high effort to use

The lightning-datatable docs include very verbose boilerplate to create tables. There are quite a few moving pieces for lightning-datatable to work since it is a feature-rich, flexible component designed to bring various types of interactivity for multi-records, single-record, or individual fields.

IMO, it is one of the most powerful but least ergonomic components that a dev has access to in the official Component Library.

My solution to reduce this friction?

soqlDatatable and its variants.

Modals / Dialogs are useful but high effort to use

Modals are not a new concept, but for SFDC it is surprisingly difficult to create one. While it's technically feasible to copy-paste the Component Blueprint (linked above) to create your own reusable c-modal LWC, you still need to slot in content and include the c-modal in the template of your parent component.

That design pattern has a few problems:

• With one component requiring multiple modals, you bloat your template with either:
  • multiple slots, one for each variation of the modal body/header/footer etc.
  • multiple c-modal, same problem as above.
• Hard to maintain separation of concerns:
  • IMO, modals do not need to be part of the same component tree as the parent implementing / calling it.
  • As you add complexity of your UI interaction (more modal pops), you start impacting the point above.

Surprisingly, there is an answer that is "ootb", the rarely used lightning:overlayLibrary Aura API.

Unfortunately, this first-party lib has its own problems:

• No parity in LWC-land, however dynamic imports is in LWC-OSS so it may pave way to something similar to overlayLibrary.
• overlayLibrary creates disconnected (read: not same component tree) DOM elements, so communicating into/out of the modal body is difficult.
  • You run into problems like passing data into the modal body and extracting save/update results back out.

My solution to reduce this friction?

DialogService which greatly simplifies dynamically creating Modals and passing data in and out.