Post 1 – Customizing your Salesforce Community with Code

This will be the first of a series of posts I will be doing about a new Pluralsight course titled, “Developing and Extending a Salesforce Community Experience with Code”.

Community Cloud (now known as Experience Cloud) has been part of the Salesforce platform for years and it is used by many companies to actively communicate with their communities of customers, partners and employees. Hence the community name.

Developing and Extending a Salesforce Community Experience with Code

Selecting a Template

The first step in creating a new community involves selecting a template. The template determines what type of community is created.

The important thing to realize is that there are two basic template types.

  • Lightning-based
  • Visualforce + tabs

To help you decide which type might be right for you, here is a comparison of the two.

Compare Community Template Types
Compare Community Template Types

I would suggest you select lightning-based templates unless there is some compelling reason to use a Visualforce template.

What you will learn in this course

In this course you will be learning about..

  • Developing custom Lightning components to extend a Lightning-based community
  • Building a Visualforce community with standard Visualforce pages and Apex classes.
  • What code-based sharing and visibility customizations you can make to secure your community.
  • Opportunities to extend your community through integrations with other communities and clouds

Stay tuned for additional posts that will cover the remaining modules for this course. You can access the course on Pluralsight here. If you do not have a subscription, then you can sign up for a free 10 day trial.

Lightning Tip: Always Create Admin Friendly Lightning Components

In case you did not realize, Salesforce Lightning components can be one of two flavors:

  1. Aura components – Launched in 2015 and up until early 2019 were called Lightning components.
  2. Lightning web components (LWC’s) – Launched in 2019 and are considered the future of Salesforce development.

Design for Configurability

Whichever flavor you select, the tip in this post applies to both Aura components and the new Lightning web components.

So what does creating Admin friendly Lightning components mean?

In a nutshell, it means making your component as configureable as possible to anyone using it to assemble Lightning pages using Lightning App Builder. This is done by using a meta configuration file for LWC’s or a design resource file for Aura components.

Whichever flavor you chose, the tip in this post applies to both Aura components and the new Lightning web components.

To give you an example of how that is done for LWC’s, let’s look at the code for the eBikes sample app, which can be found here for the LWC version. This is what the HTML for that component looks like:

    <div class="slds-card slds-p-around_x-small">
        <template if:true={searchBarIsVisible}>
                label="Search Key"
        <template if:true={}>
            <template if:true={}>
                <div class="content">
            <template if:false={}>
                    message="There are no products matching your current selection"
        <template if:true={products.error}>
            <c-error-panel errors={products.error}></c-error-panel>

And here is the JavaScript controller file:

import { LightningElement, api, wire } from 'lwc';

// Ligthning Message Service and message channels
import { publish, subscribe, MessageContext } from 'lightning/messageService';
import PRODUCTS_FILTERED_MESSAGE from '@salesforce/messageChannel/ProductsFiltered__c';
import PRODUCT_SELECTED_MESSAGE from '@salesforce/messageChannel/ProductSelected__c';

// getProducts() method in ProductController Apex class
import getProducts from '@salesforce/apex/ProductController.getProducts';

 * Container component that loads and displays a list of Product__c records.
export default class ProductTileList extends LightningElement {
     * Whether to display the search bar.
     * TODO - normalize value because it may come as a boolean, string or otherwise.
    @api searchBarIsVisible = false;

     * Whether the product tiles are draggable.
     * TODO - normalize value because it may come as a boolean, string or otherwise.
    @api tilesAreDraggable = false;

    /** Current page in the product list. */
    pageNumber = 1;

    /** The number of items on a page. */

    /** The total number of items matching the selection. */
    totalItemCount = 0;

    /** JSON.stringified version of filters to pass to apex */
    filters = {};

    /** Load context for Ligthning Messaging Service */
    @wire(MessageContext) messageContext;

    /** Subscription for ProductsFiltered Ligthning message */

     * Load the list of available products.
    @wire(getProducts, { filters: '$filters', pageNumber: '$pageNumber' })

    connectedCallback() {
        // Subscribe to ProductsFiltered message
        this.productFilterSubscription = subscribe(
            (message) => this.handleFilterChange(message)

    handleProductSelected(event) {
        // Published ProductSelected message
        publish(this.messageContext, PRODUCT_SELECTED_MESSAGE, {
            productId: event.detail

    handleSearchKeyChange(event) {
        this.filters = {
        this.pageNumber = 1;

    handleFilterChange(message) {
        this.filters = { ...message.filters };
        this.pageNumber = 1;

    handlePreviousPage() {
        this.pageNumber = this.pageNumber - 1;

    handleNextPage() {
        this.pageNumber = this.pageNumber + 1;

Notice that the searchBarIsVisible and titlesAreDraggable properties use the @api decorator and that the developer has kindly added a TODO comment here suggesting that the normalized value may come as a boolean, string or otherwise.

The reason the values may some across differently is because these two properties are configureable in the design file, but only for Record Pages and Community default pages. This means that anyone can use Lightning App Builder to change those values (well, at least for Record and Community Default pages).

To see how this is done, let’s take a look at the meta configuration file for this component:

<?xml version="1.0" encoding="UTF-8" ?>
<LightningComponentBundle xmlns="">
    <masterLabel>Product Tile List</masterLabel>
        <targetConfig targets="lightning__RecordPage">
                label="Search bar visible"
                label="Product tiles are draggable"
        <targetConfig targets="lightningCommunity__Default">
                label="Search bar visible"
                label="Product tiles are draggable"

Notice there are two targetConfig entries. One is for lightning__RecordPage and the other is for lightningCommunity__Default, but they both define the same properties. Even though these properties have default values of false, anyone assembling the pages for the two targeted page types can change these values in Lightning App Builder.

Consider this Change to the Configuration

Not to be too critical, but I can see room for improvement in the way the productTileList component was configured. After all, there is always room for improvement in anything we do, right?

The first change I would make is to add a description for all the targetConfig properties. The description is typically a short sentence, but it appears as a tooltip in Lightning App Builder. This sentence could be used to indicate to the app assembler that the property value should be either true or false and not any other value perhaps?

The end result would look something like the following (notice the tooltip on the right):

Lightning App Builder used to configure the productTileList component.
Lightning App Builder used to configure the productTileList component.

For more tips about what you can do to make your components configureable, check out this great developer doc page.

Moving to Lightning? Should you learn about Aura or LWC?

EDIT: The following post was edited on 5/22/2021

I have had a few people ask me this question and I think it is a good one, so I wanted to answer it in a post. First of all, for anyone not sure what the difference is between Aura and LWC, you might want to checkout this post I did.

As for the answer….wait for it…..It depends. It depends on:

  1. How experienced you as a Developer or Admin with JavaScript and HTML5? If you are very experienced and have even done work with React or Angular, then I would suggest starting with LWC’s.
  2. How experienced are you with modern JavaScript or HTML5 or modern development tools such as Visual Studio Code, Command Line Interfaces, GitHub? If you are, then I would start with Aura components. My latest Pluralsight course will get you up to speed on the new modern development tools that Salesforce offers. Once you feel comfortable using these tools, then your transition to LWC’s will be much easier.
  3. Are you are already familiar with Salesforce development? If you are new to doing development on the Salesforce platform and have no need to support Aura components, but still do not know much about using modern Javascript or HTML5, then I would start with LWC’s. Developing with Aura components is a legacy method that Salesforce is not actively enhancing.

Like Salesforce Evangelists, I do think that LWC’s are the better alternative in terms of component performance, but if all you need to build are very simple components, then there is no reason why you cannot start with Aura and transition to LWC’s. To be entirely honest, LWC’s are more challenging to create for developers that are not already familiar with modern web development.

I hope this post helps anyone not sure about which technology to approach first. Feel free to reach out to me if you have additional questions or concerns.


New Pluralsight Course: Getting Started Customizing Salesforce with Lightning Aura Components

I am very proud to announce the release of my latest Pluralsight course, “Customizing Salesforce with Lightning Aura Components“. This is actually a total re-write of my most popular course, “Customizing Salesforce with Lightning Components”, released in 2017. The key word change in the title is the addition of the word, “Aura“.

New Pluralsight Course, which includes working with VS Code and the CLI
New Pluralsight Course, which includes working with VS Code and the CLI

This course is different because at the time that course was released, Lightning Components were not called Lightning Aura Components AND most importantly, the new modern toolset known as Salesforce DX was not yet available. There were also no Lightning Web Components available yet.

I personally believe that for many developers, transitioning to LWC would be much easier if they were to first learn to build simple Aura components using the new modern tools first.

In this course, all those great shiny new tools will be used to build very simple Aura Lightning Components. The original course used the online Developer Console, which is what Trailhead still uses in all their content about Aura Components. On Trailhead, the new tools are only used for Lightning Web Components.

So, if you want to learn about building Aura Components, while also embracing the new modern toolset, this course is perfect for you. And if you want to learn about Lightning Web Components (LWC’s), then you can check out the “Building Your First Lightning Web Component (LWC) for Salesforce” course that I released earlier this year.

Either way, you will be knowledgeable in all the latest that Salesforce has to offer. I personally believe that for some developers, transitioning to LWC would be much easier if they were to first learn to build simple Aura components using the new modern tools first.

This course includes a GitHub Repo that features all the code covered in the course. The material covered includes the following:

Understanding the Lightning Component Framework

Refer to the following blog post #1 . In this post/Pluralsight module), you will learn:

  1. Who Should be Building Aura Components?
  2. Where Can Aura Components Be Used?
  3. Anatomy of an Aura Component Bundle
  4. Creating an Aura Component Bundle

Creating Aura Components with the Salesforce CLI

Refer to the following blog post # 2 .

  1. Using an Interactive Development Environment (IDE)
  2. Getting Setup with an IDE
  3. Understanding Salesforce DX (SFDX)
  4. Creating an Aura Component in Visual Studio (VS) Code
  5. Exposing Aura Components to Lightning App Builder

Working with Data

Refer to the following blog post # 3 .

  1. Working with Controllers
  2. Working with Apex and DML
  3. Creating a New Open Cases Component
  4. Using the CLI to Load Data to Scratch Org
  5. Enforcing Apex Security
  6. What About Caching and Usability?

Working with Record Forms

Refer to the following blog post # 4 .

  1. Working with Record Form Base Lightning Components
  2. Creating a New Quick Case Component
  3. Creating Quick Actions

Working with Salesforce Mobile

Refer to the following blog post # 5 .

  1. Working with the new Salesforce Mobile App
  2. Using the Salesforce Mobile App QuickStart Page
  3. Wrapping Up

Post 4 – Customizing Salesforce with Lightning Aura Components Series

This will be the fourth of a series of posts I will be doing over the next few weeks. This particular post will cover working with the Record Form Base Lightning Component. The series will all lead up to the introduction of my new course titled, “Customizing Salesforce with Lightning Aura Components” from Pluralsight. This course is a total re-write of my most popular course, “Customizing Salesforce with Lightning Components: Getting Started“, which was released back in early 2017. It will focus on using the new modern toolset that Salesforce offers as part of Salesforce DX.

Working with Record Forms

The recordEditForm and recordViewForm components have been around for a while, but the recordForm component was introduced in Summer 18 and was a big improvement. In fact, I was so impressed with this component, I wrote about it on this blog.

The recordForm component represents the best of two other components and essentially merges them into one. This means you will need to write less JavaScript code in the form of handlers, such as onload and onsubmit because the new component will handle these automatically.

Along with less markup, since you will not have to use lightning:input or lightning:output, along with cancel and submit buttons. They are provided for you automatically. And finally, the recordForm component is exposable to more platforms, which at this time includes Lightning Experience, Lightning Communities, Salesforce Mobile App, along with Lightning Out combined with Visualforce.

And the Drawbacks? Well, it is slightly less flexible and as of now, there is a known issue involving validation that I hope you consider voting for (since that is the only way Salesforce will fix it).

Creating a New Quick Case Component

In this section, I will show you how to build a component that let’s users quickly create a new case. The end result will be a component like this:

Quick Case Create Component
Quick Case Create Component

This component will use the recordForm base lightning component. Here is the code for the markup:

<aura:component implements="force:appHostable,flexipage:availableForAllPageTypes,flexipage:availableForRecordHome,force:hasRecordId,force:lightningQuickAction" 
    <aura:attribute name="fields" type="String[]" default="['Status','AccountId',
                                    'ContactId','Origin','Type','Reason','Subject']" />
    <aura:attribute name="reqFields" type="String[]" default="['Origin','Status']" />
    <aura:attribute name="recordId" type="String"/>
    <lightning:notificationsLibrary aura:id="notifLib"/>

    <lightning:card iconName="standard:case" title="Quick Case Create" >
        <p class="slds-p-horizontal_small">
            <lightning:recordForm objectApiName="Case" 
                          onsuccess="{!c.handleSuccess}"  />

And here is the code for the client-side controller. Note that it includes a commented method that would handle validation, since the component unfortunately does not do this (at this time – refer to issue above). I don’t really consider this a workaround, since the whole purpose of the component was to eliminate the need for the additional code. I personally think Salesforce needs to fix it, and hope you agree.

    handleSuccess : function(cmp, event, helper) {
            "variant": "success",
            "title": "Case Created",
            "message": "Record ID: " + event.getParam("id")
    // },
    // handleValidation : function(cmp, event, helper) {
    //     // NOTE: This method will handle validation if you specify which field to check for specifically, which is 
    //     //  not a good workaround since the component should handle this for you without the need to write
    //     //  all this unecessary code (especially since the whole point of the component is to lessen the
    //     //  amount of code that needs to be written). That is why it was not mentioned in the actual course.
    //     var evtFields = event.getParam("fields");
    //     var reqField = 'Origin';
    //     if (evtFields.hasOwnProperty(reqField)) {
    //         event.preventDefault();  //Stops the record from being created
    //         cmp.find('notifLib').showToast({
    //             "variant": "error",
    //             "header": "Error was encountered",
    //             "message": "The following field is required: " + reqField
    //         });
    //     } 


The code includes the notifications base lightning component. This is used to alert the user with a toast message when the case was added successfully.

Creating Quick Actions

In addition to including this component on the Sales Home page, I exposed it as a quick action and then created a global action using the following steps in Setup.

  1. In Quick Find, type “global” and select Global Actions.
  2. Click New Action.
  3. Select “Lightning Component” as the Action Type.
  4. Select the quickCase component from the drop down list.
  5. Enter a label as “Quick Case Create” and tab to next line.
  6. Click Save to Finish.

After creating the global action, you still need to add the new action to the Publishers layout, which you do using the following steps:

  1. In Quick Find, type “Publisher” and select Publisher Layout.
  2. Click Edit to modify the default layout.
  3. Select “Mobile and Quick Actions”.
  4. Scroll down to the section for Salesforce Mobile and click the override the predefined actions link.
  5. Drag the Quick Case Create action onto the section.
  6. Click Save to finish.

In the next and final post, I will go over the newly redesigned Salesforce Mobile App.

Post 3 – Customizing Salesforce with Lightning Aura Components Series

This will be the third of a series of posts I will be doing over the next few weeks. This particular post will cover working with Salesforce Data. The series will all lead up to the introduction of my new course titled, “Customizing Salesforce with Lightning Aura Components” from Pluralsight. This course is a total re-write of my most popular course, “Customizing Salesforce with Lightning Components: Getting Started“, which was released back in 2017. It will focus on using the new modern toolset that Salesforce offers as part of Salesforce DX.

Working with Controllers

In the last post, I walked you through creating the updateCellNumber Aura component in Visual Studio Code. I also stepped you through how to add a design file so that the placeholder value was easily modifiable in Lightning App Builder.

So far this component will only show a windows alert when the submit button is pressed. I am going to show you how to change that and have it update the Salesforce database instead.

Lightning Components have two ways of dealing with Salesforce data:

  1. Using the Lightning Data Service
  2. Using Apex

In this post, I will only covering the second method of using Apex to write server-side code.

Working with Apex and DML

Apex is strongly-typed object-oriented proprietary language developed by Salesforce. Since Salesforce is a multi-tenanted environment, Apex is subject to limits.

DML or Data Manipulation Language is what Salesforce uses to insert, update or delete a Salesforce record. To change the updateCellNumber component so that it writes to the Salesforce database, I will need to add a Class that uses both Apex and DML. The class will be named updateCellNumberApex (so that it is not named the same as the client-side JavaScript controller). Any server-side methods used by Lightning components must have the @AuraEnabled annotation. They also must be public and static. The code for the class will be as follows:

public with sharing class updateCellNumberApex {
    public static void CellNumberUpdate(String cellNumber) {
        List<User> users = [SELECT MobilePhone FROM User where 
                            Id =: UserInfo.getUserId()];
        if ( users.size() > 0 ) {
            users[0].MobilePhone = cellNumber;
            update users;

This code also uses a SOQL or Structured Object Query Language statement to select the MobilePhone number for the logged in user.

Once the class has been added, I will need to modify the component markup for updateCellNumber so that it is linked to this class. I do that by adding the following attribute to the aura:component tag, like this:

<aura:component controller="UpdateCellNumberApex"....

I will then need to switch to the client-side JavaScript controller and start by removing the code that produced a windows alert and replace it with the following:

var cellNumber = cmp.find("phone").get("v.value");
var action = cmp.get("c.CellNumberUpdate");
action.setParams({ "cellNumber" : cellNumber });
action.setCallback(this, function(response) {
    var state = response.getState();
    if (state === "SUCCESS") {

Creating a New Open Cases Component

This component will display a list of open cases and will be named openCases. The final component will look like the following:

Open Cases Configureable Component
Open Cases Configureable Component

This Aura component will utilize the lightning:datatable base lightning component. Here is the code for the component markup:

<aura:component controller="getOpenCasesApex" implements="force:appHostable,flexipage:availableForAllPageTypes" access="global">
    <!-- attributes -->
    <aura:attribute name="caseList" type="Object"/>
    <aura:attribute name="columns" type="List"/>
    <aura:attribute name="numRecords" type="Integer" default="10" />

    <!-- handlers-->
    <aura:handler name="init" value="{! this }" action="{! c.init }"/>

    <lightning:card title="Open Cases">
                data="{! v.caseList }"
                columns="{! v.columns }"


And here is the JavaScript for the client-side controller:

    init : function(cmp, event, helper) {
        var numRecords = cmp.get("v.numRecords")

        cmp.set('v.columns', [
            {label: 'Subject', fieldName: 'linkName', type: 'url',
                typeAttributes: {label: {fieldName: 'Subject'}, target: '_self'}},
            {label: 'Type', fieldName: 'Type', type: 'text'},
            {label: 'Reason', fieldName: 'Reason', type: 'text'},
            {label: 'Status', fieldName: 'Status', type: 'text'},

        var action = cmp.get("c.getOpenCases");
        action.setParams({"numRecords" : numRecords });
        action.setCallback(this, function(response) {
            var state = response.getState();
            if (state === "SUCCESS") {
                var records = response.getReturnValue();
                    record.linkName = '/' + record.Id;
                cmp.set('v.caseList', records)


The first part of this code is used to define the columns that will be used in the datatable. Notice that the first one is of the type url and that it has an additional definition for the typeAttributes. This is because this column will not only display the case subject, but will include a link to the case detail record.

The callback function will get whatever records are returned and then loop through those records and set the linkName so that it references the Cases record Id.

This component will utilize an Apex controller named getOpenCasesApex. It includes code needed to check for the appropriate FLS and CRUD level security. It also includes cacheable=true for the @AuraEnabled annotation in order to take advantage of caching for performance.

public with sharing class getOpenCasesApex {
    public static List<Case> getOpenCases(Integer numRecords) {
        // Code needed to check for proper access
        String [] caseFields = new String[] {'Id','Type','Reason','Subject','Status'};

        Map<String,Schema.SObjectField> caseMap = Schema.SObjectType.Case.fields.getMap();
        for (String fieldToCheck : caseFields) {
            if( !caseMap.get(fieldToCheck).getDescribe().isAccessible()) {
                throw new System.NoAccessException();

        List<Case> caseList = [SELECT Id,Type,Reason,Subject,Status FROM Case
        WHERE IsClosed = false
        LIMIT : numRecords];

        return caseList;


And finally, it includes a numRecords input parameter, which is passed in form the value set when the component is configured in Lightning App Builder. The associated design file for this component is as follows:

<design:component label="Configurable Open Cases Component">
    <design:Attribute name="numRecords" label="Number of Records Returned" placeholder="10" />

In the next post, I will go over how to design components that do not require an Apex controller.

Post 3 – Building Your First Lightning Web Component for Salesforce Series

This will be the third of a series of posts I will be doing over the next few weeks. They will all lead up to the introduction of my new course titled, “Building Your First Lightning Web Component for Salesforce” from Pluralsight. These posts will contain code snippets of the code used in the course, but will not include all the tips and best practices about using SFDX, along with the way I personally approach teaching in my video courses.

You also have to realize that the solution is built in stages and so the code you see here is not exactly what you will see by the end of the next module. For all that, you will just have to wait and watch the course, which I hope you do.

And Finally, I know there has been a big delay between the first two posts and these remaining posts, but I promise you that the delay will have been worth the wait. I am VERY proud of how this course is turning out and feel like it will be my best yet. 

Component Design

LWC’s are similar to Aura components in the fact that you should consider each component as an application building block. And just like with Aura components, most LWC’s will contain many smaller, nested components. The biggest difference is that the communication patterns between Aura components and LWC’s is VERY different.

LWC Nested Composition


In this course, we will actually be creating multiple LWC components that demonstrate a nested pattern. At the outermost layer we will have a Lightning App Page and inside of that will be an owner or container component. The owner can contain other components, which also contain other components. What is happening here is that we have a parent-child relationship going on and that is very important is determining how data is passed between LWC components.

Creating the Owner Component

At first this component (which we will name myFirstLWC) will just contain placeholder text for where the two components it will contain will ultimately reside. Here is the HTML we will use for now:

    <div class="c-container">
            <lightning-layout multiple-rows="true">
                <lightning-layout-item padding="around-small" size="12">
                        <lightning-layout-item padding="around-small" size="6">
                            <div class="slds-box slds-theme_default">
                                <h2>TO DO: Add List LWC Component here</h2>
                        <lightning-layout-item padding="around-small" size="6">
                            <div class="page-section page-main">
                                <h2>TO DO: Add Map LWC Component here</h2>

You will also need to modify the metadata file so it exposes this component (but ONLY this component since it is the owner) to the Lightning App Builder.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="" fqn="MyFirstLWC">

  1. Type “Lightning App” in Quick Find and select Lightning App Builder.
  2. Click New to start the Wizard.
  3. Leave the default on App Page and click Next.
  4. Enter the label “Lead Locator” and click Next.
  5. Select One Region and click Finish.
  6. In the Builder, scroll down to to the Custom List and drag the myFirstLWC onto the design surface.
  7. Click Save.
  8. Click Activate when prompted.
  9. From the Activation Wizard, accept the defaults, and select the Lightning Experience tab.
  10. Select Sales and click Add Page to app.
  11. Click Save.
  12. Click Back to return to Setup.
  13. Click the App Launcher and select the Sales app.You should see the Lead Locator app and you should select it to see your very basic app so far.

Creating the LeadList Component

The Here is the HTML for our leadList component. Notice that it contains two other nested components. One is a Lightning base component called lightning-input and the other is a custom one yet to be created called lead-list-item.

    <lightning-card title="Lead Search" icon-name="standard:search" class="slds--around_medium">
        <div class="slds-box slds-theme_default">
                label="Search Term"
                placeholder="Search by name, phone, website, or address"
            <h3>Leads for {searchTerm}</h3>
        <div class="slds-m-around_small">
            <template if:true={leads}>
                <template for:each={leads} for:item="lead">
                    <c-lead-list-item key={lead.Id} lead={lead} ></c-lead-list-item> 

Since this module is only about Composition and not about data, the JavaScript for this component will just contain some static JSON code to represent the lead data. It will also use the Track decorators for the leads array and the searchTerm, which allow you to keep track of a properties value when it is re-rendered.

Most importantly, it will follow best practices and use the simplest way to communicate with events by using a standard CustomEvent called newsearch.

import { LightningElement, track} from 'lwc';

export default class LeadList extends (LightningElement) {
    @track leads =[];
    @track searchTerm;

    handleSearchTermChange(event) {
        this.searchTerm =;
        const selectedEvent = new CustomEvent('newsearch', {detail: this.searchTerm});

    leads = [
            "Id": "LeadRef1",
            "Name": "Bertha Boxer",
            "Title": "Director of Vendor Relations",
            "Company": "Farmers Coop. of Florida",
            "Street": "321 Westcott Building",
            "City": "Tallahassee",
            "State": "FL",
            "PostalCode": "32306"
            "Id": "LeadRef2",
            "Name": "Phyllis Cotton",
            "Title": "CFO",
            "Company": "Chamber of Commerce",
            "Street": "300 E Park Ave",
            "City": "Tallahassee",
            "State": "FL",
            "PostalCode": "32301"
            "Id": "LeadRef3",
            "Name": "Jeff Glimpse",
            "Title": "SVP, Procurement",
            "Company": "Tallahassee Taxes",
            "Street": "1327 Colorado St",
            "City": "Tallahassee",
            "State": "FL",
            "PostalCode": "32304"


 Modifying the Owner Component

Since we added a CustomEvent to the leadList component, we will need to add some JavaScript to the owner component, myFirstLWC that will handle this event.

import { LightningElement, track } from 'lwc';

export default class MyFirstLWC extends LightningElement {
    @track searchTerm;

    handleNewSearch(event) {
        this.searchTerm =; 

We will also need to modify the HTML so that we remove the placeholder text for the leadList component. Notice though how it is named. All LWC’s will be rendered with the c namespace, followed by a hyphen and then the component name, which is also separated by a hyphen. LWC knows that the leadList component is two words because we used kebab or camel case when naming it. This is a commonly used HTML standard and it means that the component must start with a lowercase letter and the other letter must be capitalized with no spaces in between, which is how we named the leadList component.

<c-lead-list onnewsearch={handleNewSearch}></c-lead-list>

Creating the leadListItem Component

This is just a very basic component that will display the results of the search. Not much to it for now.

    <lightning-layout vertical-align="center">
        <lightning-layout-item padding="around-small">
        <lightning-layout-item padding="around-small">
        <lightning-layout-item padding="around-small">

And here is the JavaScript for that component. It will use the api decorator since the lead that is passed to it is a public property.

import { LightningElement, api } from 'lwc';

export default class LeadListItem extends LightningElement {
    @api lead;

So that is all we have for now. If you push all the code we have here and go to do a search, you should see the term you type displayed right below it, but not much else is happening yet. But stay tuned for the next post, because that is where all the magic will happen and the solution will come together.

New Way to Cache in Lightning Components

One of the best ways to gain performance in your Lightning pages is through caching. I have spoken and written about how one Lightning best practice is to use Storable Actions. File_Server_Cache_BlueThis means data served up from your server side actions is cacheable and after they are accessed the first time, they are super fast to render a second or third time. This is still a best practice, but what I wanted to make you aware of was that there is a new and even easier way to get the best of caching.

And, the best part is that you can get the benefits of caching using this technique for both your Aura components and any new Lightning web components you might create.

Prior to the Winter 19 release, if you wanted to cache data you had to call setStorable() for every action that called your apex method, such as in this example:

​var action = component.get('c.getRacesDB');
​action.setCallback(this, function(response) {
​            // Code here to handle the response

In the code above, I am making a call to an apex method named getRacesDB, and this will return to me a list of race data. To make that data cacheable, I only have to add the line of code that marks the action as setStorable. Even though this is only a single line of code, if I had multiple places that needed to call the getRacesDB method (which is very likely in a large and complex application), the setStorable line of code would have to be repeated.

With Winter 19 and the API version of 44.0 or greater, you can simply annotate your @AuraEnabled apex method with the cacheable=true attribute. You no longer need to use setStorable. For example, if I wanted to make getRacesDB method cacheable, I would just add the cacheable=true attribute and the data it returns will be cacheable for any actin that calls it.

public with sharing class ListRacesController {

    public static PageResult getRacesDB(Decimal pageSize, Decimal pageNumber) {
        // Code to return the list of races goes here

Just make sure to remember to use API version 44.0 and above when using this new attribute.

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.