Lightning Data Service – Standard Controller for Lightning Components

If you have worked on Visualforce and started playing with Lightning Component, you must have identified one important missing feature, which is standard Controller.

Lets assume a scenario, you have two Lightning Components on Account page. One Lightning Component is used to show some fields and other component is used to edit same record.

Problem 1 :

To achieve this, both Lightning components would invoke Apex method separately at the cost of performance, by issuing duplicate server calls. Below image depicts problem, where multiple Lightning component requests same content by making separate server calls.

Problem 2 :

If data gets changed because of any component, Other component needs to be informed with the help of Lightning Events. Again, it would cost performance, as every Lightning component may listen that event.

Problem 3 :

Data Inconsistency. It is quite possible that field updated but because of some defect / issue data not reflected everywhere.

Problem 4 :

Developer needs to write Apex code and handler many scenarios like SOQL, Field level security, writing test classes and many more.

To fix all of above problems, Salesforce introduced Lightning Data Service in Winter 17 as a pilot program and in Summer 17 (currently) its in Beta and expected to be GA in Winter 18.

Advantages of Lightning Data Service

• No need to write any Apex class
• No need to write SOQL
• Field level security and record sharing is inbuilt
• CRUD operation supported
• Shared cache is used by all standard and custom components
• Auto notification to all components
• Supports offline in Salesforce 1

In summer 17, we can use force:recordData Lightning component to declare Lightning Data Service. Following are important attributes

• RecordId – represents record to be loaded, deleted or updated. If its null then it indicates record to be inserted
• LayoutType – Layout from which field needs to be loaded. Currently it supports Full or Compact
• Fields– If Layout does not contains field, we can use this attribute. Either one of LayoutType or Fields is mandatory.
• Target* – attributes starting with target indicates values to be returned from Data Service. It can return record or error.
• Mode – Indicates Data Service should be used in View or Edit mode
• RecordUpdated – edit mode does not updates record by default, to update target* attributes, use this method handler

Read record using Lightning Data Service

Lets jump to source code, that could be used to read record with the help Lightning Data Service without writing single line of Apex code.

As we can see, force:recordData component is not rendered on user interface.

Update record using Lightning Data Service

Next source code is for Lightning component, which updates record with the help of Data Service.

There are two important observations in above source code.

1. Saving record in Data Service
   • We have to call saveRecord method on Data Service Lightning Component. Check code on JavaScript controller.
2. Refresh record in Data Service
   • Use method defined by recordupdate attribute on Data Service. We are using reloadRecord method and code can be seen in JavaScript Controller.

Using Lightning app builder page, we can add these two lightning components on record page. Below image shows complete demo of sample application.

Limitations of Lightning Data Service

1. It does not support bulk record operations. (think about StandardSetController functionality in Visualforce)
2. If record gets updated from outside page, like using Dataloader or some other user, it will not be refreshed. Means, it supports client side caching but not server side caching yet
3. Not all standard objects are supported (at the time of writing this post)
4. Its not yet GA

Please find slide of same presentation I gave in Boston developer group meet.