LWC Lightning Base Components Has Problem

Problem with Lightning Base Components

Lightning-based components are great at building Salesforce UI, but what happens when you want to build a UI that doesn't look like Salesforce? Its extremely difficult.

I have been working on Lightning Web Components development since 2018, the time when it was initially launched. 

Over the years there were many instances where I had to take the SLDS blueprint and re-build a base component from scratch.

As a core part of the framework, LWC gives options to compose components, expose the properties, and recently they also added design tokens. But creating genuinely custom components with custom design still requires a lot of CSS and markup work, which is not difficult with the Lightning Base Components.

If you are working with LWR OSS, like building an independent website using Lightning Web Components, it is notoriously complicated, and there are so many quirks around using the base components in the LWR OSS. 

That's why I created this Fandry UI, an opinionated component design system layer on top of the LWC framework. It is not actually meant  to replace the Lightning Base Components, but it has a different use case, like building a custom UI that doesn't look like Salesforce. 

The base Lightning components are black box by design, you cannot see what is the behavior inside the component other than the properties that are exposed by the components. Overriding the default behavior of the Lightning Base Components is very difficult. 

That's why, while building Fandry UI, my main goal was to give preference for extension and composition over properties. Working with components which has 10 or 20 different properties is difficult, but simple components which can be extended or overridden with the help of slots, parts, and CSS token. 

The idea is composition rather than dozens of configuration properties. 

Example: Styling fandry button with Parts

Let's take a look at one simple example, how I have applied this composition and extensibility over the properties and blackbox components. I have built certain base components on the Fandry UI. Let's check how the button looks like. So if you go to the button component, this is what Fandry ships out of the box.

 
It is pretty simple and basic stuff. But imagine you want to give your button a different look. This is very good use case for building external experience sites on top of Salesforce, like D2C or B2B website which are selling some stuff online. In that case you want your website to look like your brand, so how does Fandry UI gives you ability to change the behavior and the look and feel of the components?

See this screenshot:

You might think that these are different components built from scratch, but these are not. This is just the same Fandry button that is provided by the library but stylized with the help of Parts. 

Parts is a standard browser API that exposes the internal elements so that they can be styled out of the shadow boundary, specifically the parent component.

You can see the example code here: fandry button component, and how the button has been styled differently. As you can see, customization is pretty straightforward with Fandry UI. The library exposes parts so that they can be styled outside the shadow DOM.

Fandry uses native shadow DOM, not the synthetic shadow DOM unlike Lightning-based components. Styling these components is easy and you can see it's just the CSS. Best part is that you still retain the default implementation and behavior of the component.

You know its not easy to get that rainbow button out of the standard Lightning Button!

Example: Changing behavior with slots

How can you change the behavior of the button? Fandry UI exposes relevant slots for each primitive component, they have built-in "batteries-included" default behavior. Which can be overwritten with the help of slots.

If you click on the button from the Example: A loading state, with a slot section. It changes the state to "Saving", the label reverts to "Save" once the saving is completed. The change was simple. I just used the same Fandry button component, but with a slot inside that, I added a slotted element a Fandry spinner.

The spinner is displayed whenever the is saving is true. No blueprint needed, no need to build the component from ground.

Architecture of the Fandry UI vs Lightning Base Components

Lightning Base Components

Now let's talk about the architecture of the library. See the Lightning-base-components section. Lightning-base-components provide three ways to customize those components. The first and the most flexible way is to rebuild component from scratch using the SLDS blueprint. 

This means you handle all the events, behaviors, all the accessibility and everything in your custom implementation.

Then the second way of extend customizing those components was using properties, but this was also limited because you can customize only the properties that are exposed by the base component library.

And, third part is the SLDS design token, which basically can only change the appearance but it still has some limitations for animation and some CSS props. 

Talking about the upsides of the Lightning-based component, it gives you enterprise stability and they are optimized for building the standard Salesforce UI. 

Fandry UI

Now, let's talk about Fandry UI, it is a new experimental library, and it provides three different ways to customize the components. 

First is using parts: You just saw the button example, like how the button can be styled differently using the parts. 

Second thing is slots. Slots are basically extending or overriding the behavior of the component, like swapping the entire HTML markup inside a component. 

And third is tokens. Tokens are very similar to the SLDS design token, but they are also used for theming.

One more option with the Fandry UI is that the component is source available. You can download the code for those base components and customize those components. If you need heavy customization and flexibility, similar to rebuilding the component from SLDS blueprint. 

What are the downsides of the Fandry UI? First one is it doesn't look like Salesforce, and it is still in the developmental phase and it is not as stable as the Lightning base components. But I'm continuously working on the library to make it stable. 

Do you see any use cases where a library like Fandry UI can be used?

Related

Give Modern Look to Your Experience Sites with custom LWR Component Library