The short answer is at the bottom of this article, if you are interested in how I arrived at it, do read on.
Since Winter ’17, a new mechanism to load, edit, create and delete a record in Lightning Components was made available to Lightning developers (as a developer preview). This mechanism is called the Lightning Data Service (LDS). LDS removes the need for using @AuraEnabled Apex methods for database interaction but more importantly, improves performance and user interface consistency. This article looks under the hood of LDS to evaluate how these benefits are realised.
At a high level, LDS (currently in beta) is comparable to a Visualforce standard controller. Just by using mark-ups, a record and its relevant fields can be loaded into a Lightning component (like in a Visualforce page). Adding simple JavaScript controller methods in the Lightning component bundle, can enable edit, create and delete functions. The diagram below illustrates LDS architecture.
Where LDS differs from a Visualforce standard controller is that LDS has a built-in querying and caching mechanism, which optimises the database interaction. Consolidated requests are made and stored in a highly efficient cache, the caching is shared across components on the users’ browser, so server requests are not made on cache hits. LDS further optimises the cache, by only storing the fields that have been requested. If a component subsequently requires additional fields, these are loaded transparently and added to the local record cache.
When a component updates the viewed record, all the other components using that record on the page are notified, and in most cases refreshed automatically. This retains UI consistency and eliminates the need for a programmatic refresh.
To test out, I created four Lightning components; a simple component for account display and an edit, each using LDS and @AuraEnabled Apex controller. I replaced the default account view page to display these components, so that they open simultaneously (for simplicity, the view and edit components were grouped and placed in separate sections).
Upon opening an account view for the first time, a single request to the server was made to fetch data for both the view and edit LDS components, but two separate requests were sent out for the view and edit AuraEnabled components (even when they shared the same controller). On subsequent visits to the same record, no further requests were made for LDS components, but two separate requests were sent out for AuraEnabled components each time.
This load test clearly showed that when there are multiple components on a record page using the same record, the components built with LDS will load faster, as not all the components would have to make a server request. Also, the components built with LDS will load even faster on reopening the same record, due to the record made available in cache.
Let’s look at what happens when the record is updated:
As you can see, the update to the account name in AuraEnabled component, did not automatically update any of the display components but the update to the account name in LDS component, updated the LDS display component. This pattern hold even when there is a mix of standard and custom components on the page.
In summary, using LDS in Lightning components does provide benefits and should be a strong consideration before building your next component (even though it is still in beta). However, unless this service works with commonly used objects like Case & Opportunity, provides the provision for multiple operations in a single transaction and updates the local page/cache when the record is changed on the server, I would not consider it a big deal.
To gain some hands-on experience with LDS, complete the trailhead module Lightning Data Services Basic
Comments: