Work with Data

Learning Objectives

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

Explain the benefits of optimizing data retrieval.
Describe the benefits of caching data.

Tackle Unique Performance Challenges

Lightning Web Components run on the client-side, in a single page, where they're created and destroyed as needed, alongside other components that work on the same data. This means Lightning Web Components can present unique performance challenges for developers. Let's discuss how these characteristics impact performance, and review best practices that can optimize the performance of your Lightning components.

First up, optimizing data retrieval and caching.

Optimize Data Retrieval

A component with no data is not a very useful component. With Lightning Web Components, there are several options available to you when retrieving data from the server. Here are some ways to optimize server round-trips.

Use Lightning Data Service or cached data whenever possible.
Before making a call to the server, make sure there's no other option to obtain the data.

When appropriate, consider passing data between components using attributes, events, or methods rather than retrieving the same data in different components.
If multiple components on a given page retrieve the same data, consider creating a service component that has no UI elements and can query data once so that it can pass data on to other components.

When making a call to the server, limit the fields and rows of the result set.

Only SELECT the fields you need.
Set a LIMIT on the query, don't return huge numbers of rows at once.
Implement pagination when queries may have large results sets.

Lazy load occasionally accessed data. Don't preload data that the user may never need; put least accessed components in a secondary tab that the user may not click.
Don't make a call to the server to filter or sort data you already have at the client-side unless you are working with paginated data. JavaScript arrays have built in functions to do things like sort, filter, and find values.
Instead of using Apex, leverage the Lightning Data Service and UI API to retrieve records—and also retrieve list views, metadata, and picklist values.
When using the getRecord wire adapter (part of the UI API), request only the fields that the component requires. Be explicit. For example, if the component requires one field, request only that field.
@wire(getRecord, { recordId: '$recordId', fields: ['Contact.Name'] });
Don't request a record by layout unless you absolutely need all that data. Layouts are a collection of fields managed by the administrator and can change at any time. Layouts are very expensive because they often contain hundreds of fields.
@wire(getRecord, { recordId: '$recordId', layoutTypes: ['Full'] });

Don't use getRecordUi unless absolutely required. The response includes metadata that is often 100–1,000 times larger than the data payload. If you need only record data, use getRecord.

Improve Data Caching

Application composition is a powerful way to build apps by assembling self-contained components. However, without proper planning, the autonomous nature of the components you assemble can have an adverse impact on performance. For example, if all the components you build make their own isolated calls to the server to retrieve the data they need, you'll have many calls to the server. It's more efficient to make a single larger call than to make many smaller calls.

Client-side data caching improves performance by sharing data among components, which significantly reduces the number of server round-trips. LWC has two built-in mechanisms for client-side caching: Lightning Data Service and cacheable Apex methods. If neither of these work for your purposes, you can also implement a custom caching solution.

Lightning Data Service

Lightning Data Service provides a managed record approach: You're not responsible for writing Apex data access logic. It also handles security for you by checking the accessibility of records and fields. The framework is responsible for managing records. This includes fetching them from the server when requested the first time, storing them in a highly efficient client cache, sharing them between all components that request them, and sending changes to the server and invalidated cache entries when dependent Salesforce data changes.

If another component subsequently requires additional fields, these fields are loaded transparently and added to the record in the cache. Unlike storable actions that can cache any type of response returned by an Apex method, Lightning Data Service caches many types of User Interface API data: records, schema, metadata, layout metadata, lists of records, list metadata, and so on. The Lightning Data Service also improves user interface consistency: When a component updates a record, all the other components using that record are notified and in most cases refreshed automatically.

Cacheable Apex Methods

If you can't use Lightning Data Service, use Apex. A Cacheable Apex method is a server action whose response is stored in the client cache so that subsequent requests for the same server method with the same set of arguments can be accessed from that cache instead of the server.

Cacheable Apex methods let you access data using a traditional remote procedure call (RPC) approach; you implement some logic in Apex that you expose as a remotely invocable method. Cacheable Apex methods let you cache virtually anything, regardless of the server method call returns. The general guideline is to cache (mark as storable) any action that is idempotent and nonmutating.

Creating a Cacheable Apex method is easy. Simply annotate your Apex methods with @AuraEnabled(cacheable=true).

In API version 55.0 and later, you can use the annotation @AuraEnabled(scope='global') along with @AuraEnabled(cacheable=true) to enable Apex methods to be cached in a global cache.

@AuraEnabled(scope='global' cacheable=true)
public static someObject getIceCream(String flavor) {
  // your code here
}

In the next unit you go over displaying the data only when it is needed using progressive disclosure and conditional rendering.

¿Necesita ayuda?

Descubrir más