Check Out Lightning Component Development Best Practices on Pluralsight


I am so happy to announce that my third course about Lightning Component Development Best Practices was published on Pluralsight last night.

I worked extra hard on this course and have spent every weekend for the past 6 months toiling over every little thing I included. I am really hoping that effort shows through and I would love to hear your feedback (good or bad). All feedback is welcome. The good stuff makes me feel good and the bad stuff makes me better, so it’s all good.

Here is the description for the course and a listing of the specific things it covers:

Are your Lightning Components performing at the best level they can? Are they secure? Will they scale well as you start to build more complex Lightning Applications? In this course, Lightning Component Development Best Practices, you’ll learn the answers to these questions and more. First, you’ll find out what simple best practices you can incorporate to improve client-side rendering. Next, you’ll learn how to enhance server-side efficiency. Finally, you’ll discover what you can do to ensure your components are secure. When you are finished with this course, you’ll have the confidence to build Lightning Components that run “Lightning Fast”.


  • Improving Client-Side Performance
  • Enhancing Efficiency on the Server
  • Reusing Code in Complex Applications
  • Avoiding the Pitfalls of Inter-Component Communication
  • Enforcing Security and Mistakes to Next Make





Workaround for problem with lightning:input and datetime-local

EDIT: See important new update below in the Workaround

As I was preparing the code for my upcoming Pluralsight course about Lightning Best Practices, I ran into an error with the new lightning:input base lightning component that up until today had me banging my head on the desk. Since I would hate to see any of you go through all the agony I have faced with this issue, I am writing this up and hope it saves someone unnecessary grief.

The Problem


The lightning:input component creates an HTML input component and supports the datetime-local input type. This particular base lightning component is still in beta, so I am not terribly surprised that it has a few issues and I suspect that this problem will be resolved eventually.

In the meantime, if you attempt to use the input component and the datetime-local type, such as in the following code:

<lightning:input label="Date/Time"
                         value="{!v.newRace.DateTime__c}" />

And you attempt to save the record to the database, you will get back an error message similar to the following:


The following error has occurred: [{"fieldErrors":{"DateTime__c":[{"message":"Invalid data type.","fieldApiName":"DateTime__c","fieldLabel":"Date Time"}]},"pageErrors":[{"message":"The Record provided contains field(s) with invalid data."}]}]

Countless searches did not help find a solution and after playing around with it for a while, I determined that the problem was coming from the fact that the seconds (which should be optional) were not included in the string that was being sent to the server.

For example, if I were to print to the console log the value of the input date time after it had been entered, but before it was saved, it would look like this:


Notice the missing seconds?

The Workaround

Of course, you can always go back to using the ui:inputDateTime component, which does not seem to have this same problem.

EDIT: Turns out using the ui:inputDateTime is the only suitable workaround for this problem at this time. I was contacted by a member of the Salesforce team, who told me that using the workaround I describe below has one major drawback. It converts all dates to using GMT time and not the users local time and therefore is NOT a good workaround. They suggest just using the ui:inputDateTime until the fix is released as part of the Spring 18 release.

As looking for another option, I discovered that if I use the AuraLocalizationService to format the date time string and include the missing seconds, then the save to the database would work.

So, the code I needed to do that, resides in my client-side controller and looks like the following:

var rawDate = component.get("v.newRace.DateTime__c");
var formattedDate = $A.localizationService.formatDate(rawDate, "yyyy-MM-ddTHH:mm:ss");
component.set("v.newRace.DateTime__c", formattedDate);

Now if I print to the console log the value of the formattedDate variable, I see this and the record save successfully.


I suspect this is a bug (EDIT: YES, it is and it will be fixed in the Spring 18 release) and imagine it will soon be fixed, but hope this helps someone struggling with using the component in the meantime.



Lightning Best Practice: Handling FLS Exceptions Gracefully

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about base lightning components and a lot more.

If you are a Visualforce developer, then you may be surprised to learn that FLS (Field Level Security) and CRUD (Create Access Delete and Update) permissions are NOT handled automatically in your Aura-enabled code.

And in case you do not know, Aura-enabled code is the code used for Lightning components and most of this code is used to access the data in your Salesforce org. The gotcha here is that unless you are specifically checking permissions in this code, then it is possible your Lightning components could be unintentionally exposing sensitive data from your Salesforce org. 


The Problem

While there are code examples out there (such as this one on in the Lightning Developer Guide), I think there is a fundamental flaw in most of these examples. And that flaw is that they do not handle exceptions gracefully.

To demonstrate, let’s see take a look at some code that is very similar to the code used in the official Lightning docs. This code is used in the Controller of a Lightning component which lists data from a custom object called Race.

String [] raceFields = new String [] {'Id','Name','DateTime__c',
'Location__c','Attended__c','Type__c','Results__c' };

Map raceMap =

for (String field : raceFields) {
   if (!raceMap.get(field).getDescribe().isAccessible()) {
      throw new System.NoAccessException();
         return null;

res.races = [SELECT Id, Name, DateTime__c, Location__c,
               Attended__c, Type__c, Results__c FROM Race__c
            ORDER BY DateTime__c desc
            LIMIT :pSize OFFSET :offset]; 
return res;

This code will first check to see if all the fields that need to be queried are accessible and if any one of the fields is not accessible, it will throw a NoAccessException.

Seems ok, right?

Well to begin, let’s take a look at what you would see in the browser if this code is run and the user does NOT have access to one of the fields:



Not only is this message ugly, it is extremely unhelpful.  Surely, there must be something better?

Option 1 – a Better Error Message

Well, the first option you have is to simply replace the code that throws a System.NoAccessException, with code that throws an AuraHandledException, such as this:

 for (String field : raceFields) {
    if (!raceMap.get(field).getDescribe().isAccessible()) {
        throw new AuraHandledException(
            'Were sorry, but you do not have access to this field: ' 
            + raceMap.get(field).getDescribe().getName());
        return null;

The message you will see now when one of the fields is not accessible is this:


Much better, don’t you think?

Option 2 – Handling the Exception Gracefully

But wait, it can get EVEN better…

Instead of returning null when a field is not accessible, we can instead make a few more changes to the code, such as this:

String [] raceFields = new String [] {'Id','Name','DateTime__c',
            'Location__c','Attended__c','Type__c','Results__c' };
Map raceMap = 

List fields = new List();
String query = '';
for (String field : raceFields) {
    if (raceMap.get(field).getDescribe().isAccessible()) {
if(fields.Size() > 0) {
    query = 'SELECT ' + String.join(fields, ',') + ' FROM Race__c';
    query+= ' ORDER BY DateTime__c desc LIMIT ' + pSize;
    query+= ' OFFSET ' + offset;
res.races = Database.query(query);
return res;

In this version, I am still looping through all the fields to see if they are accessible, but rather than throwing an exception when even one field is not accessible, I am instead adding the accessible field to a list I created called fields. I am then building a dynamic query string using only the fields that are accessible and finally just executing the query using the database.query method instead.

The result is that when the component renders, rather than seeing any error message at all, the user sees the list of races. But, any fields that are not accessible are just left blank.

Now, I happen to think this is the best solution. What do you think?

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about handling FLS exceptions and a lot more.

Lightning Best Practice: Storable Actions


Storable Actions are a GREAT way to enhance the performance of your Lightning components and implementing them is incredibly easy, but there is one big gotcha to seeing them work with a stand-alone Lightning Application.

Even though storable actions are automatically configured in Lightning Experience and Salesforce1, any Stand-alone Lightning apps that are used to host your components will NOT use caching by default.

For these apps to use storable actions, you must do these two things:

1.) Add a new component which you can name whatever you want, but I named mine AppTemplateComponent and have it use the following code:


2.) You then need to add the following attribute to the aura:application tag of your Lightning Standalone app:


Once you do this, you should be able to see the caching working for any component used in that app that calls the following line of code:


Isn’t that amazing?

Just one line of code is all you need to add to start taking advantage of caching in your server-side actions. The impact on performance can be amazing and perhaps the best place to see is when it comes to rendering a list of data (especially if that data is non-mutable and therefore will not be updated).

This best practice really is a no brainer that everyone building Lightning Components should consider using.

If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about storable actions and a lot more.

Lightning Best Practice: Adding Pagination to Lists


What happens to a Lightning Component that displays a list of data without pagination?

It is probably doomed to suffer from performance problems and who wants to build a component that is doomed? Certainly not you, right?

It’s possible that Salesforce might release a pagination component at some point in the future, but until they do, you will need to roll out your own. Fortunately, it is not too terribly complicated and in this post I will walk you through how to do it.

To begin, I must give credit where credit is due and acknowledge that the paginator component I am using in this post is almost identical to the one used in the Dreamhouse application (which if you have not checked out, you really need to do so).

The markup code for the Paginator component is as follows:


And the Controller code looks like this:

	previousPage : function(component) {
        var pageChangeEvent = component.getEvent("pagePrevious");;
	nextPage : function(component) {
        var pageChangeEvent = component.getEvent("pageNext");;

Additionally, I use a component event called PageChange which looks like this:

Ok, so I have a component that currently renders a list of race data. To make it work with the paginator component through, I will have to make a few changes to both the markup,  controller and helper, along with the Apex Controller it references.

The new version of the markup looks like this:


The Modified controller (seen below) now includes two new actions named onPagePrevious and onPageNext and these are referenced in the Paginator component.

    doInit : function(component, event, helper) {
    handleAddToRaces : function(component, event, helper) {
        helper.addToRaces(component, event);
    onPagePrevious: function(component, event, helper) {
	var page = component.get("") || 1;
        page = page - 1;
        helper.getRaces(component, page);
    onPageNext: function(component, event, helper) {
	var page = component.get("") || 1;
        page = page + 1;
        helper.getRaces(component, page);

And the getRaces function in the Helper file has been modified to look like this:

// Added new parameter called page to pass in the page number
// If no page parameter is passed in, it will just default to 
// a value of 1 and this is the case on the initial call for 
// the doInit action
getRaces : function(component, page) {
    var action = component.get('c.getRacesDB');
    // Added the pageSize variable which is passed in as an attribute
    var pageSize = component.get("v.pageSize");
    // Added code to set the new parameters that are now passed on 
    // to the Apex Controller Code
    action.setParams({"pageSize": pageSize,
          	      "pageNumber": page || 1
    action.setCallback(this, function(response) {
        var state = response.getState();
        if (component.isValid() && state === "SUCCESS") {
            // Instead of just returning all the data
            // as a list, I will get back a result
            // object which is defined in the Apex Controller
            var result = response.getReturnValue();
            component.set("v.races", result.races);
            // Added code to set the values for the page, 
            // total and pages attributes
            component.set("v.pages", Math.ceil(;
         } else {
            //Handle errors
            var errors = response.getError();
            if (errors) {
               if (errors[0] && errors[0].message) {
                   component.set("v.errorMsg", errors[0].message);
                   component.set("v.isError", true);
            } else {
                component.set("v.errorMsg", "unknown error, response state: " + 
                component.set("v.isError", true);


The last thing to do is to modify the code in the Apex Server Controller, which will now look like this:

public with sharing class ListRacesController {

    // Changed the return value from List to PageResult
    // which is defined in the inner class below Also added two
    // new parameters for the pageSize and pageNumber
    public static PageResult getRacesDB(Decimal pageSize, Decimal pageNumber) {
    	// Added new variables
        Integer pSize = (Integer)pageSize;
        Integer offset = ((Integer)pageNumber - 1) * pSize;
        Integer totalRows = 0;
        // Instead of just returning a List of races from a single
        // query, we are now returning a PageResult
        PageResult res = new PageResult();
        res.pageSize = pSize; = (Integer) pageNumber;
        // The first query is used to fetch the data that will
        // be displayed and it will be limited to return just 
        // the data for the particular page it needs to render
        res.races = [SELECT Id, Name, DateTime__c, Location__c,
		     Attended__c, Type__c, Results__c FROM Race__c
		     ORDER BY DateTime__c desc
		    LIMIT :pSize OFFSET :offset]; 
	// We have to do a separate aggregate query to get 
        // the total number of records since this will be
        // used to compute the offset = [SELECT Count() FROM Race__c];
        return res;
   // Added PageResult class which defines the 
   // results returned from the getRaces method
   public class PageResult {
        public Integer pageSize { get;set; }
        public Integer page { get;set; }
        public Integer total { get;set; }
        public List races { get;set; }

And that’s it. I now have a component that will by default only display 5 races at a time and allow the user to move between the pages using the arrow buttons.

And now I can rest – assured that my component (which honestly could use some other improvements), will not perform miserably when the number of races eventually climbs to a very high number.

Pretty neat, right?

Want to learn about other improvements? Well, the next one is to add caching to this same component and believe it or not, I can do it with a single line of code. Check out this post for more info. And stay tuned because this blog will continue to feature lightning best practices such as these.

EDIT: Below is the requested markup and code for the inner RaceV2 component, which actually includes the individual race data.

First, the Markup:


And now the Helper Resource:

	updateRace :function(component) {
        var race = component.get("v.race");
        console.log("Calling updateRace");
        var action = component.get("c.updateRaceDB");
        action.setParams({ "race" : race });
        action.setCallback(this, function(response) {
            var state = response.getState();
            if (component.isValid() && state === "SUCCESS") {
                console.log("Race successfully updated");
            } else if (state === "ERROR") {
                var errors = response.getError();
                if (errors) {
                    if (errors[0] && errors[0].message) {
                        console.log("Error message: " + errors[0].message);
                } else {
                    console.log("Unknown error");
            } else {
                console.log("Action State returned was: " + state);



If you found this article useful, you might want to checkout my latest course on Pluralsight titled, Lightning Component Development Best Practices, where I talk about pagination and a lot more.

Lightning is to Visualforce what .NET was to Visual Basic

When I began my programming career, Visual Basic (version 3.0) was just emerging as a popular alternative for creating Windows-based applications. Ironically, it was a component-based approach to development that brought forth an army of programmers developing third-party components. Programmers could quickly spin up applications by simply dragging and dropping components onto a form design surface and then wiring everything together with events.

Visual Basic grew in popularity and for a few wonderful years, it was the hot new kid on the block. It brought about a sort of programming renaissance and lowered the barrier to entry for many up and coming developers.

Of course, the reign of Visual Basic was not meant to last. No programming language (or platform for that matter) stays golden forever. In 2002, Microsoft launched the object-oriented successor to Visual Basic called VB.NET. I can remember being so excited when it was released and I dove head first into learning all about the new Framework.

I have a confession to make. In all my excitement over the introduction of the .NET Framework, I hurriedly convinced one of my clients to let me rewrite one of his VB applications using VB.NET. Unfortunately, I made a mistake that many developers at that time did. I assumed that rewriting an application like this would be a simple conversion process. That I would just go in and simply swap one set of code for another and magically everything would work wonderfully.

That did not happen. In fact, the application I rewrote started to fall down in production almost immediately. It experienced huge performance problems. In short, it was a disaster. I had actually taken something that was working quite well and turned it into soup.

The problem was that VB and VB.NET were so fundamentally different. Design patterns that worked well in VB, failed miserably in VB.NET.

What I should have done was to start slowly.  Rather than try to convert an existing VB application to using the new .NET Framework, I should have looked at what I needed to do to make the .NET application perform well from the very beginning. I should have learned about best practices and really understood how different the new object-oriented approach to application design would be.

Eventually, I did do all those things, and also switched to using C# (which is much better imho), but only after I messed up my poor clients original VB application. Live and learn, I say. No one is perfect and we all make mistakes. The trick is to learn from them.

I feel like I have learned from mine. But the funny thing is that I can see a familiar pattern emerging now in the world of Salesforce development. I can see how the introduction of the Lightning framework will bring about some of the same challenges for Salesforce developers transitioning from Visualforce as there was for Microsoft developers transitioning from VB to .NET.


Some VB developers transitioning to .NET were never able to make the transition successfully and their careers suffered as a result. I imagine this might happen in the Salesforce world too and there will be Visualforce developers that stay Visualforce developers.

Of course, Visualforce is not going away anytime soon. But, anyone that believes it will not go away eventually is just kidding themselves. Salesforce is firmly committed to Lightning and it is no doubt the future of Salesforce development.

So, what should you do if you are a Salesforce developer that knows a lot about Visualforce?

You should embrace the new Lightning development framework and seek to understand how it differs from traditional Visualforce development. It really is like comparing apples and oranges. Begin by checking out this excellent Trail called Applying Visualforce Skills to Lightning. It helps to warn you about some of potential pitfalls you may encounter.

Just like with VB and .NET, design patterns that worked well in Visualforce, will fail in the world of Lightning. You could easily make an application perform worse if you just attempt to swap one set of code for another.

And so this is a good time for me to tell you about a new course I just started to design for Pluralsight. It will be titled Lightning Component Development Best Practices and I hope to release it before the end of the year.

In the meantime, you can also check out my latest course on Pluralsight titled,  Customizing Salesforce with Lightning Components. I have an entire module dedicated to Working with Lightning Data Service and using Base Lightning Components, which are definitely best practices Lightning developers should be using now.

And stay tuned because I will be covering many best practice topics (such as this one about Conditional Rendering in Lightning) on this blog in the months to come.


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.


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:


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("");
   if($A.util.isEmpty(contact)) {
     validCase = false;
     console.log("Quick action context doesn't have a valid contact.");

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.