Why You Really Need to Checkout the Open Source Base Lightning Components Now

As you hopefully know, Lightning Web Components (LWC’s) were introduced in 2019. Right away, Don Robins met with Salesforce expert, Chuck Liddell and they produced a free Pluralsight course, titled, “Play by Play: Understanding Lightning Web Components for Salesforce Developers“.

In that course, Chuck walked everyone through the Open Source Recipes Repo that Salesforce provided when it first released LWC’s. I remember in one part of that excellent course, that Chuck mentioned that we could not see the source code for any of the base Lightning components. Specifically, he mentioned the lightning:card component. In the course he said,

“And if I were able to look at the source code for that component, I’m sure that I would see that their attribute title is a type Aura Component Array…”

Well, the GREAT news is that Salesforce has released all those Base Lightning Components as open source on GitHub. So now everyone can see that code and learn about the best practices that Salesforce has implemented in those components.

Anyone can clone or download the source code and then follow the directions in the README to spin up these components in a scratch org. Once you do, you can open that scratch org and using the App Launcher, browse to the Base Components app. From here, they can select one of the tabs, such as the one for the Layout Components, and see first-hand how that lightning Card component works, as well as click the link to view the source.

Is that not the coolest thing in the world? I sure think so.

I would be remiss if I did not also mention the Pluralsight course I just released called, “Building Your First Lightning Web Component for Salesforce“. It is not free, but come on, Pluralsight is soooooo worth the subscription cost.

Accessing the Final Code for Building Your First Lightning Web Component though GitHub.

My Pluralsight course, “Building Your First Lightning Web Component for Salesforce” was just released. But, I have created a GitHub repo, where you can go ahead and download the final code solution (which includes a Jest test used to test the LeadList component.

Come see my Dreamforce talk about Lightning Fast Components

If you are attending this year’s Dreamforce, I would love for you to come see me talk about the 5 Ways to Build Lightning Fast Components.  The 5 tips I am presenting are the best ones I learned while doing the research for my upcoming Pluralsight course called, Lightning Component Development Best Practices.

Here are the details for the Dreamforce talk:

  • When: Thursday, November 9th (10:15 AM – 10:35 AM)
  • Where: Moscone West, Developer Theatre

This is my third time to speak at Dreamforce and it will be especially memorable this year as it is also going to be my first week as a Salesforce employee. Yep, if you haven’t heard, I am joining the Ohana and specifically, the amazing Trailhead team.

So please stop by and be sure to say hello…



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("v.page") || 1;
        page = page - 1;
        helper.getRaces(component, page);
    onPageNext: function(component, event, helper) {
	var page = component.get("v.page") || 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.page", result.page);
            component.set("v.total", result.total);
            component.set("v.pages", Math.ceil(result.total/pageSize));
         } 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;
        res.page = (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
        res.total = [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.

Natural Language Processing for JavaScript…Seriously

nlp.pngI would highly recommend anyone interested at all in Natural Language Processing (NLP) check out this newly released free course from the great folks at EggHead.io titled, “Natural Language Processing in Node.js“.

This short, but sweet course by programmer/artist Hannah Davis is based on work she did on a project to translate literature into music. The project, named TransProse would read in text using the natural library, which is available as open source here.

Hannah’s course gets straight to the point and shows you very quickly how you can start parsing text using the natural library and then do all sorts of things with it such as locating similar words, tagging parts of speech, and even classifying text into categories with machine learning.

The entire course takes only 38 minutes to watch. 

Come on. You can take the time to watch it.

But hurry, because it is only free until December 19th, as part of several courses Egghead.io is relasing for it’s 10 days of Giftmas.



What’s hot in tech? Reviewing the latest ThoughtWorks Radar

Great reference to a website that helps you stay current in this crazy moving fast industry.

Richard Seroter's Architecture Musings

I don’t know how you all keep up with technology nowadays. Has there ever been such a rapid rate of change in fundamental areas? To stay current, one can attend the occasional conference, stay glued to Twitter, or voraciously follow tech sites like The New Stack, InfoQ, and ReadWrite. If you’re overwhelmed with all that’s happening and don’t know what to do, you should check out the twice-yearly ThoughtWorks RadarIn this post, I’ll take a quick walk through some of the highlights.


The Radar looks at trends in Technologies, Platforms, Tools, and Languages/Frameworks. For each focus area, they categorize things as “adopt”  (use it now), “trial” (try it and make sure it’s a fit for your org), “assess” (explore to understand the impact), and “hold” (don’t touch with a ten foot pole – just kidding).

ThoughtWorks has a pretty good track record of trend spotting…

View original post 710 more words