Hello Lightning Data Service

The Winter 17 Salesforce release introduced a lot of exciting new changes for Lightning Component Developers. One of the most significant, was the release of the Lightning Data Service (LDS).

The LDS is “kind of” like the standard Visualforce controller, but for Lightning components. Even after the Spring 17 release, it remains in developer preview. This means you cannot use it for Production apps  and it will likely change names before it’s release. However, this represents the direction of where Lightning development is headed in terms of making it easier on the developer. Expect to see more things like this.

The LDS can be really cool if you are putting together a really simple component that will just access a single sObject and do some CRUD with it. The biggest benefit with using the LDS is that you do not need to use Apex code (think no unit tests). And most importantly, you do not have to include CRUD access checks in that code. You also get great performance benefits because components using the LDS all share a highly efficient local storage, so they should run faster.

Unfortunately, most of the Lightning component samples out there do not include Apex code to check for CRUD and FLS permissions and this is a big mistake because for Lightning components, this is not automatically enforced. CRUD and FLS security was automatically enforced in Visualforce pages, so most Salesforce developers will not even think about adding these checks. But in the world of Lightning, if you are using Apex code, you need to add access checks. Period!!!!

If you have no idea what I am even talking about, take a look at this sample Apex code, which includes the necessary access checks:

public with sharing class MyController {
  @AuraEnabled
  public static List getAccounts() {
    String [] accountAccessFields = new String [] {'Id',
      'Name',
      'AccountNumber',
      'AccountRevenue',
      'CreatedDate'
    };
    // Obtain the field name/token map for the Account object
    Map<String,Schema.SObjectField> m = Schema.SObjectType.Account.fields.getMap();

    for (String fieldToCheck : accountAccessFields) {

        // Check if the user has access to view field
        if (!m.get(fieldToCheck).getDescribe().isAccessible()) {

            // Pass error to client
            throw new System.NoAccessException()

            // Suppress editor logs
            return null;
         }
     }

     // Query the object safely. This is the only code you will see in most 
     // Lightning code samples that do not include the access checks
     return [SELECT Id, Name, AccountNumber, AccountRevenue, CreatedDate 
              FROM Account];
  }
}

By using the LDS, you avoid having to include ALL of this apex code and you still get a secure Lightning component. See now why using the LDS is so cool?

Now, I have to be honest and tell you that using LDS is not all unicorns and rainbows. It has some serious limitations (besides the fact that it is still in developer preview) such as:

• Only works with a single record and does not support operations that need to go against multiple sObjects
• Cannot be used to perform queries using anything other than the recordID.
• Even after it is released, it will probably not work in Communities, Lightning Out or Lightning Components for Visualforce

Despite these limitations, I still think the LDS is cool and that it’s introduction indicates more good things to come. I hope you take the time to check it out.