Month: October 2018

Loading a Record using LDS

To load record using LDS is by including force:recordData in your component while specifying the recordId, mode and layoutType or fields attribute.

In the force:recordData tag, specify the ID of the record to be loaded, a list of fields, and the attribute to which to assign the loaded record. force:recordData must specify the following.

  • The ID of the record to load
  • Which component attribute to assign the loaded record
  • A list of fields to load

You can explicitly specify a list of fields to load with the fields attribute. For example, fields=”Name,BillingCity,BillingState”.

or, you can specify a layout using the layoutType attribute. All fields on that layout are loaded for the record. Layouts are typically modified by administrators, so layoutType isn’t as flexible as fields when you want to request specific fields. Loading record data using layoutType allows your component to adapt to layout definitions. Valid values for layoutType are FULL and COMPACT.


Lightning Data Service(LDS) in Salesforce

Lightning Data Service(LDS) will work as data layer in Lightning. It is like Standard Controller in Visualforce page, providing access to data without querying. Use LDS to load, create, edit or delete a record in your component without Apex code. LDS handles sharing rules and field-level security for you.

Without LDS each component make independent server call to perform CRUD operation on a record, even all components are pulling same record data. This independent server calls can also lead to an inconsistencies, lead to situations where a server call refreshes one component leaving other components out of date.

LDS identifies and eliminates requests that invoke the same record data, sending a single shared data request that update all relevant components. Not only does this eliminate inconsistent data between components, it also provide a way to cache the data to work offline in case the user get disconnected and sync the data once connection is restored

So LDS provides reusable Aura components that –

  1. Minimize XMLHttpRequests(XHRs)
  2. Fetch record once, reduce network transfer, app server load and database server load.
  3. Cache record data on the client, separate from component metadata.
  4. Shared record data across components.
  5. Enable progressive record loading, caching and merging more fields and layouts into the cache.
  6. Enable proactive Cache population.
  7. Promote consistency by using only one instance of the record data across multiple components.
  8. Create notification when record data changes.


To use LDS , you have to include force:recordData in your component.

To load record in client side, you have to add force:recordData tag to your component and set your recordId, mode and layout or fields attributes.

  • recordId – specifies the record to load. Record can’t be loaded without a recordId.
  • mode – can be set to either EDIT or VIEW which determines the behaviour of notifications and what operations are available to perform with the record.
  • layout – specifies the layout(FULL or COMPACT) used to display the record, which determines what fields are included. Using layoutType allows your component to adapt to layout definitions.
  • fields – specifies which fields in the record to query.

The fields or layoutType attribute must be provided to load a record’s field data. Since admins usually modify layouts, using fields is a more flexible way to get the fields you need.

The force:recordData tag also supports a set of target* attributes, which are attributes that force:recordData populates itself. The target* attributes can be used to allow access from the UI.

  • targetRecord is populated with the loaded record
  • targetFields is populated with the simplified view of the loaded record
  • targetError is populated with any errors

< force:recordData aura:id="forceRecordCmp"
< !-- aura:id is required to reference the component in your Javascript controller -- >
/ >