Use Progressive Disclosure and Conditional Rendering

Learning Objectives

After completing this unit, you'll be able to:

Explain the benefits of progressive disclosure.
Describe conditional rendering.

Optimize Performance with Progressive Disclosure

Showing every available piece of data and every available tool on the screen is not generally considered a good UX practice. It can also significantly impact the performance of your application. Lightning components added to a page layout are instantiated when the page is loaded, contributing to the overall loading time of the page. Because of this, interactive design guidelines favor progressive disclosure.

“Progressive disclosure is an interaction design technique often used in human computer interaction to help maintain the focus of a user's attention by reducing clutter, confusion, and cognitive workload. This improves usability by presenting only the minimum data required for the task at hand.” (Wikipedia)

Put another way, according to Jakob Nielsen,“Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.”

In Lightning Experience, it's easy to implement progressive disclosure and defer data or features that aren't essential to the task at hand. There are several approaches to defer component creation, but let's take a look at two of them in detail: lazy instantiation (sometimes referred to as lazy loading) and conditional rendering.

Lazy Instantiation

Lazy instantiation (or lazy loading) means an object or component isn't created until first being used. You can do this in Lightning Experience or by leveraging different tab components.

Lazy Instantiation in Lightning Experience

Lightning App Builders can implement progressive disclosure declaratively by placing components within specific areas in the Lightning Experience where they are lazily instantiated. These areas include:

Standard tabs components, which allow information to be hidden and only loaded when the user selects that tab.
Lightning Component Actions or Quick Actions, which allow components to be loaded only when the user clicks on a button.
A Utility Bar, which can be added to any app and also includes buttons that can load components when the user clicks on them.

Lazy Instantiation in Your Own Components

You can leverage the set of tab components like <lightning-tabset> and <lightning-tab> that support lazy instantiation by default.

<lightning-tabset>
  <lightning-tab label="Item One"> Content for tab 1 </lightning-tab>
  <template lwc:if={showTabTwo}>
    <lightning-tab label="Item Two"> Content for tab 2 </lightning-tab>
  </template>
</lightning-tabset>

TabSet and the App Builder tabs component are lazy-loaded however the tabs within the Lightning Console are loaded as workspaces and sub-tabs are not lazy-loaded.

Conditional Rendering

Conditional rendering means an object or component will only appear once a state or behavior is matched. There are three options to conditionally render your Lightning web components.

Lightning App Builder dynamic component visibility
lwc:if|elseif|else
CSS

Lightning App Builder Dynamic Component Visibility

The first option is declarative and built directly into App Builder. Dynamic component visibility can control when a component appears on a Lightning page by adding filter conditions and logic to its properties in the Lightning App Builder. For example, you can construct a filter that causes a rich text component on an opportunity page to display when the opportunity's amount is greater than or equal to $1 million.

lwc:if|elseif|else

The second option allows developers to conditionally render DOM elements using lwc:if|elseif|else to lazily instantiate parts of the UI:

<template>
  <div lwc:if={something}>Conditional text displayed if something = true</div>
  <div lwc:else>Conditional text displayed if something = false</div>
</template>

In this case, if “something” = true, the first <div> tag and all its children are created, while the second <div> tag, and all its children, are not rendered. This would swap when the “something” expression changes to false. In this situation, the first <div> tag would be destroyed and the second would be rendered.

CSS

The third option leverages CSS styles to toggle visibility and can be implemented using the following template and JavaScript.

Template

<div id="error" class={className}>{error}</div>

JavaScript

get className(){
  return isError ? 'slds-show': 'slds-hide';
}

The <div> component and all of its children are created and rendered up front, but are hidden from the user until the JavaScript is run. Keep in mind that using CSS creates the component upfront so there's no performance gain on page load like there is with the other two methods. However, when the JavaScript is run, the component displays immediately to the user without the need to initialize or render.

An important difference between CSS hiding and if:true/false is that with the CSS approach, the component stays alive and so its state is maintained. Using if:true|false destroys and recreates the component so state is lost (reset).

You should use these options in the order presented. First use the declarative option discussed in option one, though this is only available on components configured for Lightning App Builder. Second should be to use option two's if:true|false approach, which works with all components. Both options help your pages load faster initially by deferring the creation and rendering of the component or enclosed element tree until the condition is fulfilled. The third option, CSS, should be used when developers want to preload a component and then show it in the UI when the condition is fulfilled.

Now that you know more about the major rendering options, let's learn about some other options that can help you improve performance.

¿Necesita ayuda?

Descubrir más