You’ve heard me say it before: I was jaded. I was looking back at 20+ years in I.T most of that as a developer in various languages and “frameworks of the day.” I was tired of the same thing, and even my transition to the Salesforce platform brought very little actual excitement for me. The community helped me see past all of that, which is why the community is still my favorite thing about the ecosystem, but as a developer, I was still…well I was cranky!

Then Salesforce introduces #Lightning. Suddenly I was invigorated again, something new, something that was in line with what all the “cool kids” were doing. Something forward-looking, and I got excited again. I dove in and started working, which brings me to my first tip for making the leap from Apex/VF to Lightning.

#1. Jump Right In — One of my favorite bands today “The Zac Brown Band” has a song called “Jump Right In” and you could say I took that to heart. I closed my eyes, picked a random deity, said a prayer and leapt from the lion’s head smack-dab into writing some lightning components. I suppose I’ve always been a learn by necessity/trial by fire kinda person and that seems to work for me. So if it works for me, it might work for you as well. Spin up a developer org, turn on lighting, and start writing something, anything! My first foray was a streaming application that ran via the web and in Salesforce1 that allowed users to vote on what they wanted for lunch. As they voted, the counts went up in real time. Meaning person A voted for sushi from their phone, and persons B,C, and D all saw those updates happen in real time on their screens. I was jazzed, and I was hooked! Was it useful? Not really, but that’s not what matters. What matters was that I learned something. So just “Jump Right In” and do something.

#2. Ask “What If” — since your jumping right in with both feet anyway, start asking yourself “what if?” What if I try to add something like a streaming (see above) result to a lightning component? What if I change this line to that? What if instead of creating a component on the record detail page to modify a field on that same object, (because you could do that), I created a reusable form to create child components directly from the parent’s detail page without having to leave that page? Ya know, like this:

#3. Check out Lightning Design System — When thinking about moving some functionality from Visualforce to Lightning, think about your options. Maybe your first option isn’t a component at all, maybe its simply re-styling your Visualforce page using the Lightning Design System. (This thing is awesome…just awesome). If you’re at all like me at hate front end work, the perhaps the Lightning Design System can ease your pain somewhat. They’ve taken all the things I hate about CSS and put them together in a not so blackbox “blackbox” that just works. All you have to do is apply the appropriate styles to your HTML elements and the system takes care of making it look like the page is inside LEX. Yea, I’m gonna say it…it’s sexy.

#4. Lightning Out — Maybe you’re not quite ready to go full on lightning components. Maybe you could instead replace pieces of functionality with a simple component and Lightning Out and throw that into a Visualforce Page. Lightning Out allows you to run lightning components right inside of a Visualforce page or even off platform if you so desire. (Something I’m really wanting to try but just haven’t been able to find that time yet, but mind you, I will indeed find the time). This would allow you to start small and work your way up.

#5. Get Involved — No surprise here. Me, the guy always raving about the community, is asking you to get involved with the community. Join your local developer group, go to user groups, participate in the Success Community, or the Salesforce Stack Exchange. Start helping other’s solve their problems. I promise, you will learn more than you ever thought you could, and there’s so much to learn. I’m barely scratching the surface and if it weren’t for those in the community already doing the things I’ve mentioned above, I’d be nowhere. Ya hear me? No. Where. The community is the secret and we are all here to help. The blogs, the forums, the user groups, the conferences, all of it. Just do it.

:wq!

One of the things that really surprised me when I started poking at custom Lightning Components/Apps was the fact that I truly had to handle navigation from scratch. As a developer, we’re taught to never re-invent the wheel and to write code that is re-usable up front. Over the next few posts, I hope to discuss what I’ve found, what I’ve tried and what I’ve ultimately come up with when facing these challenges.

When I started out, I knew that navigation was something that I didn’t want to have to solve every time I set out to write an application. I knew I’d need a core group of components and events that would work in concert with one another and I knew that I’d have to keep these components generic enough that they could be included in any apps that I wrote. What I’ve come up with thus far appears to be working and I’ve done a demo for a couple different people and haven’t had any major “gotchas” pointed out to me yet. I’m still trying to get the ear of some other folks that I know are much more into Lightning than I am just to level set my expectations and find out if I’m really off in the weeds or not.

Before I get into the nitty-gritty, the back story here is that I had a customer approach me about creating a Visualforce page for a very complex custom object in their org. They wanted to be able to use the page in both the browser and on Salesforce1. If this were a simple object, this could have been simpler I imagine, however there are numerous dependent picklists that forced the original VF page to be spread out amongst several other clicks/refreshes, etc. This was not going to translate well to Salesforce1. Also, we wanted to avoid two different processes, one for mobile and one for the web. I made a couple of suggestions and one of them was to create a custom app that could be “created” via App Builder for use with Salesforce1 and an app that could be accessed via the web interface. (I’ve since done some playing with lightning out and prefer going that route for the web interface as it feels more native to the Salesforce experience).

However, budgeting for such an endeavor was a challenge because I’d never done anything like this before. I’ve been through the trailhead modules, taken a HOT at Dreamforce and toyed with it a bit on my own but only using rather simple examples. This was a chance to step back and tackle a “real world” scenario. I dove in far enough to realize, as some of my past blog posts have eluded to, that Lightning really is a “framework” in the most true sense of the word. There are just enough features there for you to work with, but you are left to your own devices to get things off the ground. Therefore, I started an example project in a dev org and this is what I’ll be going over in the coming posts.

Since #TahoeDreamin had just ended, and Apex & The Limits had been asked to travel to #SEDreamin — conferences were stuck on my mind. So my sample application was a very basic conference management application, its not fully baked and I plan to write more, but currently its just venue’s and conferences because…well consulting and billable hours take precedence. (Hey kids gotta eat man!)

The actual components are simple enough that I could use pre-built items for display, etc but I wanted to see how the system would behave with completely custom pages/forms, etc. since my clients’ application was not going to be able to take advantage of things like default page layout, record pages and what have you.

Rather than discuss the ins and outs of creating my custom objects, I’ll just tell you what I have and leave you to your devices to create them (or something similar) if you’d like to follow along. We have a Conference object and a Venue object. Each object has its own information, like addresses, start dates, end dates etc. Again since that’s not at all what this post is about, I don’t want to spend too much time here. Let’s get to thinking about the structure of the application since we are trying to be generic anyway.

Navigation:
I wanted to be able to navigate to a list of conferences or a list of venues so I knew I would need a basic component to display these links to me. I knew I would need custom components to display these lists and informational pages. What I didn’t know was how to navigate between the two. My intuition told me that selecting a record would need to fire some sort of event that I could handle and initialize/load the appropriate component. I had been googling and not found a standard, built-in navigation method. I did find e.force:navigateToSObject and other similar events, but those only work in Salesforce1 (according to the docs) & I needed this to work in the web interface as well. On top of that, I needed a component to fire that event anyway. I knew I needed to fire a custom event and it was looking like I would also need a component to fire it.

However, that’s only part of the problem. Even if I managed to fire this custom event, how were people swapping components in and out. And then I came across this. Basically, I needed to create a container component that would house my custom components and swap them in and out of there.

The last piece I needed was some generic code to be able to handle my custom event, get the name of the component I intend to load and have my container component’s controller load that component. I created a “Base Component” that will be my container and a matching controller that will initialize my entire app (based on a parameter, but more on that later) and also handle my “navigation” by swapping out custom components as signified by my custom event. That looks something like this (I’m using the Lightning Design System to style things):

<aura:component implements="force:appHostable,flexipage:availableForAllPageTypes" controller="BaseComponentController">
	
	<aura:attribute name="appName" type="String" />
	<aura:attribute name="activeComponent" type="String" />

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

	<div class="slds" style="padding: 10px;">
		{!v.body}
	</div>

</aura:component>

And my Base Component’s controller (NOTE: much of this code should be moved to the helper class, I just haven’t gotten there yet):

({
    doInit : function(component, event, helper) {
            //ignore this bit for now, more on that later
            var action = component.get("c.getDefaultComponent");
            action.setParams({
            	"appName" : component.get("v.appName")
            });

            action.setCallback(this, function(response) {
            	var state = response.getState();
            	if(state === "SUCCESS") {
            		//load new component
            		var defaultCmp = response.getReturnValue();
            		$A.createComponent(
            			defaultCmp,
            			{},
            			function(newComponent) {
            				component.set("v.body", newComponent);
            			}
            		)
            	}
            });

            $A.enqueueAction(action);
    },

    //this is the custom swapping of components piece...
    loadComponent : function(component, event, helper) {
        var newCmp = event.getParam("targetCmp");
        var attrs = event.getParam("attributeList");

        $A.createComponent(
			newCmp,
			attrs,
			function(newComponent) {
				component.set("v.body", newComponent);
			}
		)
    }
})

The “magic” here lies in my controller’s loadComponent function. You will notice that my Base Component is handling a custom event called “navigateToComponent” — this event gets fired by another custom component (we’ll discuss that in my follow up post), my base component will handle that event and inspect it for the name of the component I’d like to load as well as any custom attributes my new component will need, such as the ID of an object I’m trying to load into that component. This function calls $A.createComponent which loads an instance of my component, and swap it into place where my Base Component has {!v.body} specified.

So now “theoretically” (this is all just my observations, but it is indeed working) I can fire my custom event, pass in the name of any component and its attributes and load it without my Base Component having to know anything about the component it is loading nor its data. If I use this base component in all my future apps (along with my custom event), navigation is solved for me.

That’s plenty of writing for me, and reading for you at the moment I think. Hopefully next week, I’ll have the custom event queued up for you :)

:wq!

Last week we updated our app to show all of the Poll Question Options as buttons within our parent Poll Question Component. However, it still “does nothing.” What we really need to do is get it to interact somehow, and we will do this by supplying our buttons with a function to call in order to cast our vote.

The first thing we need to do is setup a javascript controller (client side controller) for our Poll Question Item component to talk to. On it we will create a function called “voteItUp” that will in turn call a method on our apex controller that will actually increment the vote count and save our answer.

Open up your PollQuestionItem component in the developer console and in the right-hand side menu, click “Controller” and paste this into the code:

({   
    voteItUp : function(component, event, helper) {
        var optionId = component.get("v.pollOptionId");
        var voteAction = component.get("c.incrementVote");
        voteAction.setParams({ optionId : optionId });
        
        voteAction.setCallback(this, function(response) {
           var state = response.getState();
            if(state === "SUCCESS") {
                document.getElementById(optionId).innerHTML = response.getReturnValue();
            }
        });
        
        $A.enqueueAction(voteAction);
	}
})

What this does is gives us a function that we will use when our button is clicked. In order to determine which button is clicked we will store the option ID of the component that it came from (v.pollOPtionId) in a variable called “optionId.” If you recall we are looping over this component in our parent component and passing it a Poll Option object each time. We then setup the action (the call to the apex method) by looking at our component and finding its declared controller, and telling it to call the “incrementVote” method on that controller. Our apex controller needs to know what option we are voting on so we will have pass in the option ID. This is done with the setParams function and takes a key value pair collection of arguments (voteAction.setParams({ optionId : optionId }) ). We then tell this action what to do when it completes by setting up the callback function. This will run after our callout to apex completes. We’ll then inspect the results and if successful, update the UI.

Please Note: This code is still under some development as I was having some issues locating the output for my vote count. However, this was happening while simultaneously trying to troubleshoot some streaming API issues (coming in part 5). In order to get things to work, I had to resort to using document.getElementById to locate the element in my component to update it. However, that’s also the beauty of this — while its probably not the “blessed” way to do something, while coding you can always “fall back” to tricks like this because your UI, at the end of the day, is still simply HTML and javascript. I would like to come back at some point and fix this, but haven’t found the time :( #StoryOfMyLife

Next we will create the apex controller that our component’s client side controller will call. Simply create a controller using your favorite editor (dev console, sublime, eclipse etc). I called mine PollOptionController. Use the following code:

public class PollOptionController {
	    
    @AuraEnabled
    public static Integer incrementVote(String optionId) {
        Poll_Option__c option = [SELECT Id
                                , Vote_Count__c 
                                FROM Poll_Option__c 
                                WHERE ID = :optionId];
        option.Vote_Count__c += 1;
        update option;
        return option.Vote_Count__c.intValue();
    }
}

Here we take the optionId that we passed in from our client side controller and lookup our custom object by its Id. We then increment its vote count by 1, update it and return the vote count back to our calling function. This will get processed in the “callback” of our action and update our component’s UI with the latest vote count.

Lastly we need to tell our button what function to call when pressed and tell our component which apex controller it needs to be associated with like so:

<aura:component controller="PollOptionController">

    <aura:attribute name="pollOption" type="Poll_Option__c"/>
    <aura:attribute name="pollOptionId" type="String" default="{!v.pollOption.Id}"/>
    
    
    <div style="border:1px solid black;margin:5px;padding:10px;text-align:center;border-radius:5px">
        <ui:button aura:id="voteButton" label="{!v.pollOption.Option_Name__c}" press="{!c.voteItUp}"/>
        <div style="float:right" class="findme" id="{!v.pollOption.Id}">
            {!v.pollOption.Vote_Count__c}
        </div>
        <br/>
    </div>

</aura:component>

We tell our component which apex controller it will be working with by adding the controller attribute to our component declaration: controller=”PollOptionController” and finally we add the “press” attribute to our button to tell it which function to call when its tapped/clicked, etc. One point that may be confusing for some is the use of multiple controllers. Our UI components do not call our apex directly, instead they call our client side controllers (the javascript ones). That is the {!c.voteItUp} notation. However we do tell our component which apex controller it is associated with using the controller attribute in our declaration. So when I say our component is calling a controller function using c.something, I’m making reference to our client side controller, not our apex controller. (For me, it really feels as if the only reason our component mentions the apex controller is so that our client side controller has a place to look up which controller to call a given function on, I could be wrong and it may provide other functionality, but at the moment that bit is unclear to me).

If we load up our application in Salesforce 1, we should now be able to tap the buttons and vote. As you vote you will see the vote count increase. These results are also being persisted to your org as well. We now have a functional lightning app!

I was imagining a use for such an app, and perhaps rather than a “voting” type of application, similar apps could be used on shop floors, in retail etc to reflect an up to date view of inventory. But even better, what if we could stream those results so that users of the app could see an ongoing real-time view of data. For that, we will need some extra javascript libraries, some calls the the streaming API….and another blog entry. Until then…

:wq!

As you may or may not know, I was out in San Francisco last week attending my first MVP Summit. For this reason, I did not post part three of my current lightning tutorial. <sarcasm>Since you’re no doubt waiting directly on the edge of your seat<sarcasm>, lets get right back to it.

Last week we left off with a component that was just a tiny bit more flexible than a simple “Hello World” type of component. We were able to add our component to the lightning app builder and configure said component to display the current active poll question. Today we will move on to having this component nest a secondary component that will be responsible for displaying our poll’s options as buttons on the screen. For this, we need to create a brand new custom component, so we’ll begin there.

In the developer console click File->New->Lightning Component. We will call this component “PollItemOption.” Once again we will get the familiar skeleton code, but we’re going to replace it with the following:

<aura:component >

    <aura:attribute name="pollOption" type="Poll_Option__c"/>
    <aura:attribute name="pollOptionId" type="String" default="{!v.pollOption.Id}"/>
    
    <div style="border:1px solid black;margin:5px;padding:10px;text-align:center;border-radius:5px">
        <ui:button aura:id="voteButton" label="{!v.pollOption.Name}" />
        <div style="float:right" class="findme" id="{!v.pollOption.Id}">
            {!v.pollOption.Vote_Count__c}
        </div>
        <br/>
    </div>

</aura:component>

For this component, we are creating a place holder for the Poll Option object itself (pollOption attribute). Remember that we will be using this component “inside” of our Poll Question component that we’ve been working with. That parent component will be passing a Poll Option object to this one. In our case, the Poll Question component will loop over the Options that belong to it and pass them to this component for rendering. We will also likely need the ID of the Option we are working with for updates, etc so we’ll create a place to store that ID as well (pollOptionId attribute).

Next we add some HTML and styling to our component. We will be displaying the poll options as clickable buttons that our users will tap in order to vote for them. I’m wrapping these ui:button pieces in an HTML div for more control over styling. (Once again, I must point out that I am doing this “wrong” during development as style should go in the CSS file that belongs to the component — we’ll get there, but when I’m coding, I like my styles right where I’m working, its just a preference for me). Inside that div we have an instance of ui:button, the label of that button will be the Poll Option’s name field, referred to with our shorthand for accessing attributes in our view: {!v.pollOption.Name}. We can also tell that button what function to call when it is pressed (but we will do that in part 4 next week).

I follow this button up with some HTML markup to assist in styling and then I close it up.

This component, though it will have zero/broken functionality can now be rendered within our parent component, so lets just wire it up briefly so we can track our progress. Open up the Poll Question component that we created in part one. (If you don’t already have it open you will need to go to File->Open Lightning Resources and expand the appropriate folder, highlight the individual pieces and click on the Open Selected button at the bottom of that dialog window).

Now let’s add an iteration over our Poll Options from within our PollQuestion component and have it pass each option to our newest component. Replace the PollQuestion component code with this code (really you only need to add the aura:iteration tag and its contents):

<aura:component implements="flexipage:availableForAllPageTypes"  controller="PollController" >

    <aura:attribute name="pollQuestion" type="Poll_Question__c"/>
    <aura:attribute name="options" type="Poll_Option__c[]"/>
    <aura:attribute name="title" type="String" />
    <aura:handler name="init" value="{!this}" action="{!c.doInit}" />

    <h1 style="text-align:center">{!v.title}</h1>
    <p style="padding:10px;">{!v.pollQuestion.Name}</p>
    <aura:iteration var="option" items="{!v.pollQuestion.Poll_Options__r}">
        <c:PollItemOption pollOption="{!option}" />
    </aura:iteration>

</aura:component>

What we’ve added here is the bit called an aura:iteration. It’s how we loop over collections inside lightning components. You specify the variable that you will be using for each iteration and the items over which to be iterated. In this case our variable is called “option” and our items are our poll options that we retrieve from the pollQuestion (!v.pollQuestion.Poll_Options__r} — we retrieved them in our PollController). Secondly, inside of this iteration we are telling this component to use our PollItemOption component that we just created to render each poll option (<c:PollItemOption pollOption=”{!option}” />). Here the “c:PollItemOption” means we are loading a component called “PollItemOption.” That component also has an attribute called “pollOption” that is expecting a Poll_Option object. So we pass our “option” variable in using pollOption=”{!option}”

If you load up your lightning app in Salesforce1 now, you should see our Current Poll application displaying the question and each option rendered as a button. If you’re following along, from last week we should see something similar to the screenshot below. (NOTE: Your titles will be different since I am re-writing my original app for the blog to help me keep track, and you likely won’t have any vote numbers showing up since we’ve not voted for anything yet):

Things are starting to look a tad more useful. Next week we will add the necessary logic to allow voting on each item, followed by adding in some functionality to wire in the streaming api so that you can watch the votes increase as users vote.

If you happen to be in the Milwaukee area on Thursday, May 21st (I know its short notice) I will be demoing this application complete with streaming at the Wisconsin User Group meeting at: 250 E Juneau Ave Milwaukee, WI. The meeting starts at 11:30am. Stop on by if you find the time.

:wq!