Category Archives: Lightning Components

A Salesforce Lightning Component Design Pattern for Optimum Code Reuse

As the author of Salesforce.com’s official instructor-led course for Lightning Developers – Dev601: Programming Lightning Components as well as the Trailhead Lightning Component Framework Superbadge, I’ve spent a lot of time developing hands-on exercises that illustrate the mechanics of custom app development on the Salesforce.com platform.

What that course doesn’t officially cover, however, are design patterns for creating components for optimum re-use and application maintainability. Therefore I decided to author this blog article to act as additional reading materials for that course. Note that this post does assume that you are already quite familiar with Salesforce Lightning Component development.

Before we can discuss a pattern strategy, let’s define a couple of terms.

Tightly Coupled Components

A Tightly Coupled App is one where all of the components are nested within a container-component.In effect, you can treat the parent component as a de facto controller, handling any Lightning component events thrown by its members (typically by setting public properties and calling public methods of components other than the one that threw the event).

For instance, consider a scenario where a user chooses from a select-box of beers as illustrated by Figure 1. The BeerSelector component throws a component event containing the beer selection back to FriendsWithBeer.cmp. FriendsWithBeer.cmp then takes the beer selection and programmatically sets a beerId attribute in c:FWB_BeerContacts which triggers and APEX request, displaying a list of all contacts who like that particular beer.

app_org1

Figure 1: Tightly Coupled App Wireframe for our sample app, Friends with Beer

Loosely Coupled Components

Loosely Coupled components, illustrated by Figure 2, are assembled into an application with Lightning App Builder and therefore have no direct parent component other than a Lightning App Builder template. The only way these components can therefore communicate with each other is via Lightning Application events. In this scenario, encapsulation of functionality is an absolute-must as business users have the freedom to include or exclude any installed Lightning App Builder-enabled components in your Salesforce org.

app_org2

Figure 2: Loosely Coupled App Wireframe

Why Bother?

It’s a fair question. If you’ve tracked the progress of Lightning App Builder over the last few release cycles, it’s pretty clear that Salesforce is expending a lot of effort in this particular area of the framework. Having components that can be surfaced by both developers (as strongly-coupled apps), yet retain the flexibility to be deployed in App Builder, helps future-proof your code. It would not surprise me if within a couple of years, the vast majority of custom lightning applications are assembled using App Builder by both developers and power-users/admins.

Bringing it all together

I therefore suggest that you organize your Lightning applications around three separate tiers, as illustrated in Figure 3:

  • The Functional Tier are comprised of utility components that do all the actual output within your application. I’m talking about Lightning Base Components, utility components such as custom grids/tables, custom buttons, and whatnot.
  • The Declarative Application Tier are components that invoke Apex methods, encapsulate business logic, and pass data to the functional tier components for output to the user. These components also fire and listen to component events. A strongly-coupled Lightning application would consist of only components from the Declarative Application Tier and the Functional Tier.
  • The Orchestration Tier invokes components from the Declarative Application Tier, re-firing custom Lightning Component events as custom Lightning Application events. They serve as a wrapper for the Declarative Tier components that you want to surface in Lightning App Builder. They also wrap components in lightning:card, as this is the preferred methodology (in Winter 18) to ensure that your component is not transparent against the new Winter 18 Lightning custom background.
app_org3

Figure 3: Code Organization Pattern

Naming Conventions

You’ve probably inferred from the slides above that I’ve settled on a few naming conventions:

  • Functional component names start with a lower-case letter and are camel-cased.
  • Declarative Application Tier components start with applicationName_ComponentName. Since the name of my sample app is Friends With Beer, I’ve abbreviated the app name to FWB. Therefore, FWB_BeerSelector, FWB_BeerContacts, and so forth.
  • Orchestration Tier components are prefixed with applicationName_App_ComponentName
  • Component event names are prefixed with applicationName_evt_ComponentEventName
  • Application event names are prefixed with applicationName_aEvt_ApplicationEventName

Feel free to critique these choices and concepts in the comments section below. In (hopefully) about 30 days, you’ll be able to view my detailed explanations of these concepts (including a code walkthrough) as a Pluralsight video play-by-play with my fellow Lighting Component instructor Don Robins!

Need immediate help? For Lightning Component consulting, development, and best-practices code-reviews please send an email to info@figleaf.com. My company, Fig Leaf Software is a certified Service-Disabled Veteran-Owned Small Business located in Washington, D.C.

Salesforce Lightning Components: Creating a Select Box/Tree Component

Need a user to select an item from a 2-tier hierarchy? Typically, you’d either use a lightning:select with embedded optgroup tags, or use the new lightning:tree component. But, for optimal code reuse, consider building a single component that enables a developer to toggle the input mechanism that they think is the most appropriate for their use-case. For instance, while lightning:tree is great for desktop and tablet apps, it’s not appropriate for mobile phones, or for input forms.

fwb1

lightning:tree (left)

IMG_2170

lightning:select (in Salesforce Mobile)

The following component enables a user to either select from a list or a tree, depending on the value of the “mode” attribute.

<aura:component controller="BeerContacts" access="global" extends="c:Base">

<aura:attribute 
 name="mode" 
 type="string" 
 access="global" 
 default="select" />

<aura:attribute 
  name="beers"       
  access="private"       
  type="Object[]"      
  description="hierarchical data to display" />

 <aura:attribute       
  name="selectedBeerId"       
  access="public"       
  type="Id"       
  default=""       
  description="User selection"/>

 <aura:attribute       
  name="labelPrefix"       
  access="public"       
  type="String"       
  default="Friends with "      
  description="Text prefix for select options"/>

 <aura:handler    
  name="change"         
  value="{!v.selectedBeerId}"         
  action="{!c.onBeerChange}" />

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

 <!-- fire event when a selection is made -->
 <aura:registerEvent       
  name="onBeerSelected"       
  type="c:FWB_BeerSelected"/>

 <aura:if isTrue="{!v.mode == 'select'}">
   <div>
    <lightning:select     
     name="beerId"           
     label="Select Beer"      
     variant="label-hidden"      
     value="{!v.selectedBeerId}">

    <option value="">Select Beer</option>
    <aura:iteration items="{!v.beers}" var="thisBeerGroup">
        <optgroup label="{!thisBeerGroup.label}">
        <aura:iteration items="{!thisBeerGroup.items}"               
                        var="thisBeer">

            <option value="{!thisBeer.name}">
             {!v.labelPrefix}{!thisBeer.label}
            </option>
        </aura:iteration>
        </optgroup>
     </aura:iteration>
   </lightning:select>
  </div>
  <aura:set attribute="else">
    <lightning:tree items="{!v.beers}"                               
       header=""                               
       onselect="{!c.onTreeSelect}"/>
  </aura:set>
 </aura:if>
</aura:component>

While you can’t prevent a user from selecting a category in lightning:tree, you can provide them with guidance that they need to select a leaf node as illustrated by the component’s controller onTreeSelect function:

({
    doInit : function(component, event, helper) {
        helper.onInit(component,event,helper);
    },
    onBeerChange: function(component,event,helper) {
        var compEvent = component.getEvent("onBeerSelected");
        compEvent.setParam("beerId",component.get('v.selectedBeerId'));
        compEvent.fire();
    },
    onTreeSelect: function(component,event,helper) {
        var compEvent = component.getEvent("onBeerSelected");
        var selectedName = event.getParam('name');
        if (selectedName.indexOf('type:') == -1) {
            compEvent.setParam("beerId",selectedName);
            compEvent.fire();
        } else {
            var toastEvent = $A.get("e.force:showToast");
            if (toastEvent) {
                toastEvent.setParams({
                    "type" : "warning",
                    "message": "Please select a beer, not a category."
                });
                toastEvent.fire();
            }
        }
    }
})

And finally, you can use the same data structure to populate both the select box and tree control, as outlined by the following helper method, which is invoked by the controller’s doInit() method:

({
    onInit : function(component,event,helper) {
        helper.runApex(
            component,
            "c.getBeers",
            function(response) {
                var result = [];
                var groupName = "";
                var thisGroup = {items : []};
                for (var i=0; i<response.length; i++) {
                  if (groupName != response[i].Type__c) {                          
                        if (thisGroup.items.length > 0) {
                            result.push(thisGroup);
                        }
                        groupName = response[i].Type__c;
                        thisGroup = {
                            label: response[i].Type__c,
                            name: 'type:' + response[i].Type__c,
                            expanded : true,
                            items : []
                        };
                    }
                    thisGroup.items.push({
                        name: response[i].Id,
                        label: response[i].Name
                    });

                }
                component.set('v.beers',result);
            }
        );
    }
})

For reference, the getBeers() Apex method simply retrieves a category and beer name from a custom object. Note that the data is sorted by the fields that we are going to use for grouping in both the tree and select box:

public with sharing class BeerContacts {

    @AuraEnabled
    public static List<Beer__c> getBeers() {
      return [
         select Id,Name,Type__c,Country__c
         from Beer__c
         order by Type__c,Name
      ];
    }
}

Happy coding!

Using optgroup in lightning:select

IMG_2170.PNG

Grouped Options in Salesforce Mobile

Every coding framework/toolset has strengths and weaknesses. There are some incredibly powerful things that you can do very simply, but often times there are incredibly simple things that require more brainpower (and a lot more coding) than should really be necessary.

Unfortunately, grouping options read from force.com in a Salesforce lightning:select control falls into the latter category.

In order to achieve the grouping effect, as seen in the screenshot at right, I needed to pull data using Apex, group it client-side into an array of objects, and then loop through that array of objects in the lightning component.

In this use-case, we’re working with a custom object named Beer__c with a field named Type__c that holds our types of beer, e.g. Ale, Lager, Stout, etc.

Why beer? Because beer is both the cause and solution to all of our problems. Clearly.

Step 1: Ordering Apex Results

public with sharing class BeerContacts {

   @AuraEnabled    
   public static List<Beer__c> getBeers() {
     return [ 
       select Id,Name,Type__c,Country__c
       from Beer__c
       order by Type__c,Name
     ];
   }
}

Step 2: Group the Results into an Array of Objects

    doInit : function(component, event, helper) {
        helper.runApex(
            component,
            "c.getBeers",
            function(response) {
             
                // transform into object array
                var result = [];
                var groupName = "";
                var thisGroup = {items : []};
                for (var i=0; i<response.length; i++) {
                    if (groupName != response[i].Type__c) {
                        if (thisGroup.items.length > 0) {
                            result.push(thisGroup);
                        }
                        groupName = response[i].Type__c;
                        thisGroup = {
                            Name: response[i].Type__c,
                            items : []
                        };
                    } 
                    thisGroup.items.push({
                        Id: response[i].Id,
                        Name: response[i].Name
                    });
                    
                }
                component.set('v.beers',result);
            }
        );
    }

Step 3: Output the Array of Objects into a lightning:select

<lightning:select name="beerId"
             label="Select Beer"
             variant="label-hidden">              
  <option value="">Select Beer</option>    
  <aura:iteration items="{!v.beers}" var="thisBeerGroup">
     <optgroup label="{!thisBeerGroup.Name}">
     <aura:iteration items="{!thisBeerGroup.items}" var="thisBeer">
         <option value="{!thisBeer.Id}">{!thisBeer.Name}</option>
     </aura:iteration>
     </optgroup>
   </aura:iteration>
</lightning:select>

Screenshots from Dev601: Programming Lightning Components

I recently completed revamping the Dev601: Programming Lightning Components course for Salesforce.com. Dev601 is a 450-page, 5-day instructor-led course that comprehensively walks developers through building custom extensions for Lightning Experience, Salesforce Mobile, and other platforms.

You learn how to build custom query-by-example interfaces using Apex, Lightning Data Service, and standard components…
ss1

You coordinate the display of multiple views using Application and Component events…
ss2

Build sophisticated forms with data validation and execute CRUD operations with Lightning Data Service…
ss3

And implement loosely-coupled components that are flexible enough to be assembled by non-programmers in Lightning App Builder…

ss5

Cool!!!

Need some Lightning Component consulting/professional services? Contact my company, Fig Leaf Software, at info@figleaf.com

Implementing a “Deck of Cards” Layout in Salesforce Lightning Components

A “Deck of Cards” layout is where multiple “cards” of information are stacked on top of each other. Only one card is visible at any given time. Essentially, this is similar to a tab panel, but it gives you the flexibility to design your own ux for swapping the cards in and out.

I’ve implemented this as a single component that can be easily invoked from an app, or other cmp file:

<aura:application >
    <c:cardLayout aura:Id="myCardLayout">
        <div class="card">
            This is card 1
        </div>
        <div class="card">
            This is card 2
        </div>
        <div class="card">
            This is card 3
        </div>
    </c:cardLayout>
    
    <div style="position:fixed; bottom:10px; border: 1px solid black">
    <ui:button 
        label="Show Card 1"
        press="{!c.showCard1}" />
    <ui:button 
        label="Show Card 2"
        press="{!c.showCard2}" />
    <ui:button 
        label="Show Card 3"
        press="{!c.showCard3}" />
   </div>
</aura:application>

The corresponding controller simply calls a public method on the cardLayout component:

({
  showCard1 : function(component, event, helper) {
    component.find('myCardLayout').setActiveCard(0);
  },
  showCard2 : function(component, event, helper) {
    component.find('myCardLayout').setActiveCard(1);
  },
  showCard3 : function(component, event, helper) {
    component.find('myCardLayout').setActiveCard(2);
  }
})

Pretty simple, right?

Now, let’s take a look at the cardLayout component. It’s relatively straightforward:

<aura:component>
   
   <aura:method 
                name="setActiveCard" 
                action="{!c.doSetActiveCard}" 
                access="global" />
   
   <aura:handler name="init" value="{!this}" action="{!c.doInit}"/>
 
 
   <aura:attribute 
                   name="activeCard" 
                   type="String" 
                   default="0" access="global" />
	
   <div class="cardContainer">
     {!v.body}
   </div>
</aura:component>

The controller logic simply applies or removes a custom css class:

({
    doSetActiveCard : function(component, event, helper) {
        var currentActiveCard = component.get('v.activeCard');
        
        var params = event.getParam('arguments');
        var newCardId = params[0];
        
        var oldCard = component.get('v.body')[currentActiveCard];
        $A.util.removeClass(oldCard,"card--on");
        
        var newCard = component.get('v.body')[newCardId];
        
        $A.util.addClass(newCard,"card--on");
        component.set('v.activeCard',newCardId);
        
    },
    
    doInit: function(component, event, helper) {
        component.setActiveCard(component.get('v.activeCard'));
    }
})

And the CSS…well, it just defines a couple of classes for defining card visibility along with a “fade” animation

.THIS {
    height: 100%;
}

.THIS.cardContainer {
  position: relative;
  display: flex;
  flex: 1 0 auto;
  height: 100%;
}

.THIS .card {
  transition: 0.2s opacity linear; 
  visibility: visible;
  overflow: auto;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  position: absolute !important;
  opacity: 0;          
  visibility: hidden;
}

.THIS .card--on {
  opacity: 1;
  visibility: visible;
}

I’ll be discussing this technique, as well as other solutions at my presentation on “Lightning Component Best Practices” at the Dreamforce conference in Thursday, Oct 6. See you there!