“Apexless” DML Operations Using Lightning Data Service

Hi Trailblazers!

If you are using multiple components together and they work on the same record, the process of communication between them can be exhausting.

The communication process generally contains these steps:

1. Use Server-Side Apex call to fetch a dataset
2. Perform DML operations using Apex
3. Notify other components using Lightning Events
4. Refresh other components manually
5. Check for FLS (Field Level Security) and CRUD (Create Access Update and Delete) security using code
6. Write unit tests

Through Lightning Data Service (LDS), Salesforce provides us an easy way to avoid these exhausting steps:

1. No separate Server-Side Apex calls
   LDS analyzes all the server-side requests of all components which are related to the same record and sends a single shared request which improves the performance.
2. Perform DML operations without writing Apex code
   It provides CRUD functionality
   1. getNewRecord() – Allows to Read record dataset
   2. getNewRecord() – Creates new record
   3. saveRecord(callback_function) – Saves record after updating it
   4. deleteRecord(callback_function) – Deletes record dataset

   For more exciting insights, you can click here.

3. Auto Notification
   Changes in any component automatically get notified to other components which help to get rid of the need to use events to notify each other.
4. Refresh Components and Cache automatically
   reloadRecord() refreshes other components in container. After saving changes in a record, LDS automatically refreshes the cache too.
5. Standard Controller
   Like Visualforce Standard Controller, LDS takes care of CRUD operations with FLS (Field Level Security) on record data.
6. Cache to work offline
   If the user gets disconnected and is working offline, it automatically syncs the data as soon as the connection is up.
7. Consistent Data
   If multiple components are working on the same data, LDS uses a single instance to make sure the data is consistent.

Fig. LDS removes Duplicate calls and uses Single Shared Request

Limitations

1. Bulk data is not supported
   We can perform only primitive DML operations (create, read, edit and delete) on a single record.
2. Server-side support is not available
   The Shared data storage of LDS provides notifications to all components that use a record whenever a component changes that record. It doesn’t notify components if that record is changed on the server. For example, if the record is changed by batch class execution, records changed on the server aren’t updated locally until they’re reloaded.

Pointers to Remember

1. No need to write any Apex class
2. No need to write SOQL
3. Field level security and record sharing is inbuilt
4. CRUD operation supported
5. Shared cache is used by all standard and custom components
6. Auto notification to all components
7. Offline support in Salesforce 1

So, to perform DML operations on a record in multiple components, try to use LDS which will provide an optimized solution within less time, enabling you to adhere to strict deadlines!

Refer the Salesforce Documentation to know the LDS Consideration