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.

Top 5 Lightning Tips for Visualforce Devs

#1- Transition does not have to be all or nothing

For Visualforce Developers, when it comes to transitioning to Lightning development, it does not have to be an all or nothing deal. Very few development shops/companies will go from doing all Visualforce development to doing all Lightning development overnight. That is just not realistic, nor a good idea, in my opinion.

The introduction of Lightning Out offered a lot of options for Visualforce developers wanting to slowly transition to Lightning. If you want to learn what options are available in terms of a transition plan, I suggest checking out this post and blog series by Salesforce Architect, Mike Topalovich. Mike does an excellent job, not only of giving a lot of background, but of detailing 5 specific migration paths that you will want to consider.

#2 – Watch your Casing

JavaScript is Case sensitive!!!

This is so important, I am going to write it again, “JAVASCRIPT IS CASE SENSITIVE”.

If only I had a nickle for every time I ended up discovering that the odd error I was getting in Lightning was actually caused by a casing error of mine. Seriously, I cannot tell you how many times this has tripped me up. More times than I would probably like to admit.

So anytime you are working with Lightning and you get an error that makes no sense, the first thing you should do is return to your JavaScript code and make sure you did not make a casing error. It really is VERY easy to do. Embarrassingly so.

#3- Security Works Differently

As Visualforce developers, you have been spoiled as far as security is concerned. Visualforce apps operate out of the Force.com domain, which is not shared with Salesforce code. But, Lightning apps and components run in a special domain that is shared with Salesforce-authored Lightning code.

This means that the security for Lightning components are subject to a Content Security Policy (CSP). The rules surrounding what is and what is not allowed with these components will just tighten as time goes on. Go here to learn more about all the concerns regarding Lightning Security.

One important thing that you need to know is that any of your AuraEnabled Apex classes must do an explicit check for CRUD and FLS permissions. This was handled automatically for you in Visualforce pages, but in Lightning, unless you are using the new Lightning Data Service, you will need to do this check manually. You can do so using the isAccessible(), isCreateable(), isDeleteable(), and isUpdateable() methods. You can learn more about how this is done here.

#4 – Install and Use the Lightning Inspector

For Chrome users, there is an excellent plug-in called Lightning Inspector that every Lightning developer should check out. One of the most useful features it offers is a component tree tab, which shows you how the Lightning Framework sees your component. You can use this as a tool not only for debugging components, but learning more about what some of the built-in ones are capable of.

#5 – Check out newest components/features added

The Lightning Framework has been out for a while now (over 2 years actually) and in that time there have been many new releases and lots of new features added. Building Lightning components today is not the same as it was when you may have run through a tutorial or article a year or two ago. If it has been a while since you took a look at what features and components are available, it is time to take another look.

In the last release (Winter 17) many new features were added such as the Lightning Data Service, which you can kind of think of as the equivalent of a Standard Controller for a Visualforce page. Currently this feature is still in developer preview, but using it allows you to eliminate the need for Apex code and also those manual security checks that I mentioned earlier.

I strongly believe that component-based development, such as what you do with the Lightning Framework is the future of web and device-based development. If you have not already dipped your toes in Lightning Development, it is not too late. Things are just getting really good for this modern development platform.

The Eclipse Force.com IDE makes an Epic Comeback – with support for Lightning!!!

I was so happy to see recently that Salesforce was refocusing it’s efforts towards improving the Eclipse Force.com IDE. It has also now gone open source. But I was MOST pleased to see that the beta version now offers support for Lightning components.

Developer Console is “ok”. Well, let’s be honest, as a serious development tool, it still sucks, although it is getting better with every release. There are also a plethora of other development tools that have popped up recently, but most of these are not free. Most developers I know use the freely available and very cool, MavensMate. Although, it’s creator Joe Ferrara has recently suspended development so he can focus on his newborn. Good choice by the way, Joe!!!.

But now, here comes Salesforce with something that not only includes Lightning support, but it also has some pretty nifty features that I think will make it a serious contender in the Salesforce IDE world. I really like the hover over documentation support that you see in the screenshot below. As well, as the outline pane over on the right, that allows you to quickly move back and forth between component bundle files.

ForceComIDE.png

But my absolute favorite thing is the auto completion, which is invaluable if you are just learning about Lightning. This missing feature almost made me not use Developer Console for my first Pluralsight course. But, I am so glad because not only can I use a free tool in my next course, I can use one that is fully supported by Salesforce themselves.

Way to go Salesforce! Much appreciated!!!

One big gotcha to keep in mind though is that you cannot run the Beta version of the IDE along with your prior version of the IDE (if you are indeed using it).

 

 

First Pluralsight Course About Lightning Published

Author-Badge_Sq-Black_SmallI am proud to announce that my first course for Pluralsight which is titled, “Getting Started Building SPA’s with Lightning Component Framework” was released last night.

Here is the course description:

Learn how to build single page apps (SPAs) with the new Lightning Component Framework.  This modern framework is built on the open-source Aura Framework and includes all the tools and technologies Salesforce enterprise developers need to build responsive and efficient component-based applications for any device. You’ll learn the basics of building Lightning components by stepping through building a single page app used to track race participation. You will also learn to apply professional styling, handle events with JavaScript client-side controllers and access data with server side controllers using Apex code. The course will finish off by showing you how to document your components and debug the Lightning App using browser tools.

I strongly believe that component frameworks like Lightning really are the future of web-based development. All of the major vendors, such as Google (with Polymer), Facebook (with React), Twitter (with Flight) and Mozilla (with Brick) are investing in component frameworks.

Lightning is also a JavaScript-based framework, but unlike the other JS frameworks like AngularJS, Backbone and React, Lightning is the only one of those frameworks that is designed specifically for enterprise applications.

So, if you do not know about Lightning and want to find out more, I hope you take the time to check out my new Pluralsight course. And, I would love to hear what you think about it.

 

 

Annoying Lightning Bug you want to be aware of

dreamstime_xl_25648715I just completed development of a new course about Lightning component development for Pluralsight, which I will be telling you more about soon. But, in the meantime, I wanted to blog about a very annoying bug that I ran into several times as I was developing the course that I thought you should be aware of.

The issue involves seeing Access Check Failed warning messages all over the console log in your browser tools. They indicate that there is a problem with components you have no control of (such as any of the ui controls, like ui:inputText, etc). For example, this is one such error I saw:

WARNING: Access Check Failed! Component.getEvent():’change’ of component ‘markup://ui:inputSelect {38:2;a} {Type}’ is not visible to ‘markup://c:RaceTrackerApp {1:2;a}’.

I did extensive research on this issue and did get a confirmation from the guy at Salesforce in charge of this area that this is likely a bug they have already identified, but not yet resolved (see the comments at the bottom of this post).

This error can be ignored, BUT you do not want to ignore all Access check failed messages because some are indeed valid. For example, any that involve components you do have control over. For these, you want to use an access attribute for your component, attribute or event. You can find more info about that here.

Hope this helps someone.

Learn Lightning with Siri

If you have heard about Salesforce’s new Lightning development platform and are curious to learn more about it, I strongly suggest you check out Teaching “Siri” Lightning Components: Building a Hello World Example at ElToro.IT.

ElToro (which stand for “The Bull”, by the way) is the alias used by the extremely talented Salesforce University Instructor, Andres Perez. Andres is producing a series of instructional videos that teach you all about Lightning. But, the really clever thing he has done is to not only make the videos informative, but also extremely entertaining. Throughout the videos, he banters with Siri, because the premise is that he is teaching Siri all about Lightning. Even though, he just has one video so far, I have no doubt that the rest will be just as good.

Great job Andres!!!