1. What is Lightning Data Service?

ANS:
 We built LDS to serve as data layer for Lightning.
 LDS is the Lightning Components counterpart to Visualforce standard controller, providing access to the data
displayed in the page.
 Without LDS each component within the app makes independent calls to the server to perform CRUD
operations on a record, even if all the components from the app pull from the same record data.
 Each server call reduces performance.
 Independent server calls also leads to inconsistencies, creating situations where a server call refreshes one
component, leaving other components out of date.
 LDS identifies and eliminates requests that involve the same record data, sending a single shared data
request that updates all relevant components.
 Not only does this eliminate inconsistent data between components, it also provides a way to cache data to
work offline incase the user gets disconnected, intelligently syncing the data once the connection is
restored.

IN A NUTSHELL LIGHTNING DATA SERVICES PROVIDES REUSABLE AURA COMPONENTS THAT:

a. Minimize XMLHttpRequests (XHRs).
b. Fetch records once, reducing network transfers, app server load, and database server load.
c. Cache record data on client, separate from component metadata.
d. Share record’s data across components.
e. Enable progressive record loading, caching, and merging more fields and layouts into the cache.
f. Enable proactive cache population.
g. Promote consistency by using one instance of the record data across multiple components.
h. Create notifications when record data changes.

One of the simplest uses of LDS is loading records.

To load a record on the client side, you have to add the force:recordData tag to your component, and set your recordId,
mode and layoutType or fields attribute.
 recordId: specifies the record to load. Records cannot be loaded without a recordId.
 mode: Mode can be set either VIEW or EDIT which determines the behavior of notifications and what operations
are available to perform with the record. If you are using force:recordData to change the record in any way, set
the mode to EDIT.
 layoutType: 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 for.

The fields or layoutType attribute must be provided to load a record’s field data. Since admins usually modify layouts,
using fields is 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.
On its own force:recordData doesnot include any UI elements, its simply a logic and a way to communicate with the
server.

Several aura methods are available to modify records.

 saveRecord() : inserts or updates the record loaded into force:recordData component.
 deleteRecord(): deletes the loaded record.
 getNewRecord(): loads a new record template that performs an insert when saved.
 reloadRecord(): reruns the loading code to override the current targetRecord with the current attribute values.

How to take actions when your record changes, so that your components can respond to a record load, change,
update or deletion. --------
To take an action when a record changes, handle the recordUpdated event.

When LDS detects a record change, it notifies the components that use the record of the changes.
If you don’t handle the change, the record is still updated, so any reference to the targetRecord or targetFields
properties automatically shows up in your components.

For every force:recordData component that references the updated record, LDS does two things:
  LDS notifies all other instances of force:recordData of the change by firing the recordUpdated event with the
appropriate changeType and changedFields value.
 It sets the targetRecord and targetFields attribute on each force:recordData to the new value. If targetRecord
or targetFields is referenced by UI, this automatically triggers a renderer so that the UI displays the latest data.

NOTE:
IF force:recordData is in EDIT mode, targetRecord and targetFields are not automatically updated when the record
changes. This is to avoid clobbering edits that are still in progress and to prevent unsaved changes from appearing in
other components.

[ ERROR HANDLING]:

The targetError attribute is set to localized error message if error occurs on load. An error occurs if the attributes in
force:recordData are invalid, or if the server is not reachable or the record isn’t in the local cache.

If the record becomes inaccessible on the server, the recordUpdated event fires with changeType = REMOVED, and no
error is set to targetError, because a record becoming inaccessible is sometimes an expected outcome. Records can also
become inaccessible due to record or entity sharing and visibility settings, or because the record was deleted.

Fields or layoutType can both be included inside force:recordData. With fields you have to specify which specific fields
you want to query upon, while with layoutType you just need to specify the record layout you want to use, either FULL
or COMPACT.
If you use targetFields to retrieve data, which is the preferred method, use the format v.targetFields.Name in your UI
else for targetRecord use v.targetRecord.fields.Name.value.