Category Archives: Lightning

Lightning Data Service Goes Beta in Summer 17

For the past two Salesforce release cycles the Lightning Data Service (LDS) has been in developer preview, but starting in Summer 17, it moves to Beta. The biggest thing to be aware of is that if you have created any code using the LDS, the markup will need to be changed. Prior to Summer 17, the LDS used the force:recordPreview tag, but this has been replaced with force:recordData.

If you have created code using the Lightning Data Service when it was in preview and named force:recordPreview, you will have to change your markup before that code will work in a Summer 17 org.

So what is the LDS?  (you may be asking yourself)

The LDS is on it’s way to becoming the standard controller (used in Visualforce) equivalent for a Lightning Component. It makes working with data in a Lightning component super easy (as in all you need to do to use it is add a single line of markup code). No Apex code is needed.

Another thing that makes the LDS so cool is that all Lightning components that utilize the recordData tag will have access to a shared data cache. This ensures that they return data as quickly as possible.

LDS.png

If you have not yet checked out the Lightning Data Service (LDS), this is definitely the time to do so. And if you are interested in seeing an example of how a Lightning Component can be greatly simplified using the LDS, go over to Pluralsight and check out my latest course titled,  Customizing Salesforce with Lightning Components. I have an entire module dedicated to Working with Lightning Data Service.

Lightning Best Practice: Conditional Rendering

For WhichMethoda long time I thought the best way to conditionally render elements in a Lightning component was to use CSS toggling. I thought this because if you look at the official Lightning Developers Guide where it talks about Dynamically Showing or Hiding Markup, the guide actually writes,

“Use CSS to toggle markup visibility. You could use the tag to do the same thing but we recommend using CSS as it’s the more standard approach.”

I have since learned that this is not really a best practice and the best method might be to use the built-in aura:if component. I discovered this by reading through a recently published article about Lightning Best Practices by Salesforce technical Evangelist, Christophe Coenraets in which he writes,

“The general guideline is to use the aura:if approach because it helps your components load faster initially by deferring the creation and rendering of the enclosed element tree until the condition is fulfilled. Components inside an aura:if with the value of its isTrue expression evaluating to false aren’t created and aren’t part of the DOM. Event listeners aren’t created either.”

So, which method is better for conditional rendering?

I do believe that Christophe is correct in stating the aura:if approach should be used generally. But there is a gotcha you really should be aware of when going down that path.

Ok, so let me explain this better with an example. Let’s assume you wanted to either render an error message if one was encountered while accessing data, or a table listing the data that was retrieved. You might use some markup code such as this:

AuraIfMarkup.png

The errorMsg attribute would be initially set with a value of blank in the doInit action. It would only have a value other than blank when an error was encountered.  And this would cause the message to be displayed. Makes sense, right?

The solution above will certainly work, but if you examine your console output, you will see a message such as the following:

Screen Shot 2017-05-30 at 5.37.15 PM

So, what is this message about?

Well, it is a performance warning message telling you that you have an aura:if tag that was switched from true to false in the same rendering cycle and this can cause avoidable work for the framework that slows down rendering time.

But, didn’t I start all this by suggesting that using the aura:if for conditional rendering was a better alternative?

It’s ok, there is a simple fix for this.  Instead of checking to see if the errorMsg attribute has a blank value, what you need to do is to add a second attribute called isError and make sure it uses a default of false, like this:

<aura:attribute name=”isError” type=”boolean” default=”false” />

You can then change the markup code to look like the following and you will no longer receive the warning message in the console.

Screen Shot 2017-05-30 at 6.23.41 PM

The message I am hoping to get across here is that, you really need to be aware of what is happening in terms of the Lightning Rendering Lifecycle, as that can have a big impact on performance.  AND most importantly, you need to always check your console log to look for performance warnings.

Good tip: Always check your console log for performance warnings.

I have no doubts that Lightning development is the future of all Salesforce development and that the future does look bright. And amazingly fast. It is just going to take a little time to work out all the kinks. And time for us developers to learn about what best practices are needed to make it really run that fast.

If you liked this post, then you might want to checkout my new course about Lightning development on Pluralsight titled, “Customizing Salesforce with Lightning Components: Getting Started”

 

 

 

New Customizing Salesforce with Lightning Components Course Released

SecondCourse.pngI am proud to announce that yesterday my new course for Pluralsight titled, “Customizing Salesforce with Lightning Components: Getting Started” was released.

Here is the long description:

In this course, you’ll learn how to easily customize Salesforce with the new Lightning Component framework, which includes all the tools and technologies needed to build responsive and efficient components for any device. First, you’ll cover the basics of building Lightning Components, and how to work with data using built-in components such as the Lightning Data Service. Next, you’ll explore Lightning alternatives for the traditional JavaScript buttons that so many orgs have now. Finally, you’ll learn about the most efficient way to migrate from Visualforce to Lightning. Although, many things have changed during the evolution of the Lightning Component framework, don’t worry, you’ll learn what you need to know to get up to “lightning” speed. By the end of this course, you’ll be well on your journey towards customizing your org with Lightning components.

Specific topics I cover are:

  • Base Lightning Components
  • Lightning Data Service
  • Extending SLDS
  • Lightning Actions
  • Migrating from Visualforce to Lightning

Hope you like the course. I worked really hard on it, dedicating every weekend for the past 7 months. I wanted each module to be special and I hope my efforts show.

If you see the course, I would be really interested in your feedback – good or negative. All of it helps me to create better courses.

Why Lightning Base Components are so Awesome

When Lightning development was first introduced, the Salesforce developers thought UI components (which you have probably seen used in a lot of sample code) would meet all the needs of component developers. They were wrong. Although the UI components, which include things like ui:inputText/ui:outputText, ui:button, ui:menu, ui:message are very useful, they have some serious drawbacks.

The biggest drawback is that they do not handle validation for you automatically. The component developer is responsible for adding JavaScript code needed to validate data entered into these components. Another big drawback with UI components is that they do not handle Salesforce Lightning Design System (SLDS) styling for you. You have to know which SLDS tags to use around your UI components.

To understand exactly what this means, consider a “very simple” component used only for creating new cases. This is what the component looks like when rendered:

Screen Shot 2017-03-03 at 2.51.39 PM.png

Using UI components, this is how much code is needed to validate this very simple component:

validateForm: function(component) {
  var validCase = true;
  var subjectField = component.find("Subject");
  if($A.util.isEmpty(subjectField.get("v.value"))) {
     validCase = false;
     subjectField.set("v.errors", [{message:"Subject can't be blank"}]);
   }
   else {
     subjectField.set("v.errors", null);
   }
   var reqNumberField = component.find("EngineeringReqNumber");
   if($A.util.isEmpty(reqNumberField.get("v.value"))) {
     validCase = false;
     reqNumberField.set("v.errors", [{message:"EngineeringReqNumber can't be blank"}]);
   }
   else {
     reqNumberField.set("v.errors", null);
   }
  // Verify we have a contact to attach it to
   var contact = component.get("v.contact");
   if($A.util.isEmpty(contact)) {
     validCase = false;
     console.log("Quick action context doesn't have a valid contact.");
   }
   return(validCase);
 }

In addition to having to add your own validation code to the JavaScript controller, you will have to know which SLDS (or Salesforce Lightning Design System) tags to use and this is not always so obvious.

Most developers I know do not want to have to spend the time learning which CSS tags to apply to get the styling they need. They just want things to work. Out of the box. Simple like.

I hear ya and so did the developers at Salesforce.

In Winter 17, Salesforce released a whole new set of components known as Base Lightning Components. Similar to the UI components, these components do something fundamentally different. The validation code and SLDS styling is built right in. All you have to do is add the markup to your page and waaaalaaa!

The page will render the same with styling and will have built-in validation, but the code will be so much simpler.

If you have not checked out the Base Lightning Components, you might also want to check out my new course on Pluralsight, which has an entire module about Base Lightning Components.

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.

Winter 17: Replacing JavaScript Buttons With Lightning Actions

Winter 17 hasJS introduced a whole bunch of new enhancements for Lightning and I will be blogging about a lot of them in the next few weeks, but one of my favorites is the new Lightning Actions that provide the ability to replace all those JavaScript buttons you may have littered about your org.

Ok, now anyone that has an org with more than one JavaScript button, just read that last statementdreamstime_xl_25648715 and probably thought, “Say what? I have to replace JavaScript buttons with something new? What about just migrating the existing buttons to Lightning?”

Can’t do it.

Why? Well, in three words, “Big Security Concerns”

Yep. the kind that can bring an org to it’s knees and one that also can’t be resolved by providing some simple migration tool that converts existing buttons into Lightning actions automagically.

The bad news here is that you are going to have to do some real work to get all those buttons converted into Lightning actions. But, the good news is that once you do it, you will probably be very happy that you did and your org will certainly be more secure as a result.

And to help you get to that point, the Salesforce development group has started a new blog series titled, “JavaScript Buttons, Lightning and You“. This three part series will step you through what you need to know to move towards Lightning Actions. I also plan to cover this very topic as part of the new Lightning course I am working on (more on that later).

So, take some time to check out the new blog series and learn why you might be better off starting your transition to Lightning by first converting all those buttons to actions.

And stay tuned for more info about my upcoming Pluralsight course.

 

Can’t Miss Salesforce Security Webinar Series

vulnerabilities_checklistI know security is probably not your favorite subject. But these days, it seems like everyday there is another major story coming out about how some big company has a major security breach. A lot of companies use Salesforce because it is secure and trust is so important. But as a developer, you have to realize that there are MANY ways you can bypass all the terrific security features Salesforce has put in place.

Developers have lots of flexibility that gives them power, but with power comes responsibility. It is so important you are aware of all the ways you may inadvertently make your app vulnerable to attack. Unfortunately, most of the documentation on this subject is loooooonnnnnggg and how shall I say this….BORING!

Well, for all you visual learners that really love practical examples, your help has arrived. The Salesforce security team has begun a series of Webinars designed to get developers up to speed with some practical, code-based demonstrations that show:

  1. How we as developers can inadvertently bypass security
  2. What you can do to correct the mistake and make your app secure again

So far there are only 2 webinars in the series, but just watching these two will probably teach you more than you get by trying to pour through and interpret all that other boring documentation.

Hope you find these as helpful and enlightening as I did. And thanks to the Security team for taking the time to put the sample app together along with these webinars.

 

 

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).

 

 

More Info about the Apex Realtime Debugger

If you happened to catch my post last year about the release of the new Apex Realtime Debugger, then you might also be interested in checking out this demo recording which was made at the recent TrailheaDX conference last month.

The short talk was given by Greg Wester and if you are really just interested in seeing a good demo of the Realtime Debugger, then I suggest you skip the first 5 minutes of the 16 minute recording.

Greg also reveals at the end certain FAQ’s that you might be interested in which include:

  • The Debugger only works in the Sandbox and there are no plans to ever have it work in production.
  • Licenses are assigned via permission sets and you can only have one instance running per org.
  • It does not support asynchronous code. Only synchronous operations.
  • You can get a trial of the debugger if you contact your Account Exec.
  • This fall they will be doing a pilot with vendors that allows them to step through managed code. This should be of big interest to ISV’s out there.

ApexDebugger