Last week, at Snowforce in Salt Lake City, I saw a demonstration of the Lightning App Builder and decided that I wanted to make a Lightning component of my own. I thought the best thing to do was to follow the quick-start PDF, and was quite proud of that. I made the text say "Hello David!" which seemed like a good start. Mike Gerholdt then challenged me to render the word "David" dynamically, pulling from the running user. I checked the documentation, and there is no $User global variable as there is in Visualforce, so I was faced with a conundrum: How to pull fields from the current User record? The documentation and quick-start expenses app show how to pull a list of records and then to choose one from those, but I wanted something different. After perusing Reid Carlberg's post about Lightning components, I had my answer. I won't explain too much what is going on here, but I will share the necessary parts of the app. I have endeavored to make all the method and variable names different enough so you can see where each comes from. If there is any confusion, please leave a comment and I will update the post accordingly. ExampleApp - Lightning Application This is only necessary for previewing your work in a browser window. As we will see, it is unnecessary for creating components for either the Salesforce1 mobile interface or the Lightning App Builder interface.

TopLevelUserComponent - Lightning Component This is perhaps the most important part, as it is a container for all the other components that will contain whatever we want to put in our application. This contains the required code for exposing the component to Salesforce1 (force:appHostable) and to the Lightning App Builder (flexipage:availableForAllPageTypes). If we put any code or styling here, it would be available, should we wish, to all child components. This is how components communicate with each other if they are not above or below in the component hierarchy. This is also important because apps will likely have multiple components all at the same hierarchy level, so the "top level" container allows us to unify everything in one place.

    

Hello TopLevelUserComponent!


    

UserFromUser - Lightning Component Here is where things get interesting. The component is fairly simple, with an Apex controller to allow us to pull data from the Salesforce database, an attribute for the running User, a line to run the code to query the data, and an output of that data.

    

User from User Component


    
    

User lastname:  {!v.runningUser.LastName} 

User firstname:  {!v.runningUser.FirstName} 

Please note that I have written the first and last names thrice: Once with a ui:outputText tag, once as naked markup, and once with an aura:text tag. I have no idea which is the best practice, but as I try never to put naked text on a Visualforce tag, I will assume that either ui:outputText or aura:text are best. UserFromUser - Component JavaScript Controller This JavaScript class (I'm not sure if class is the right word, but it will have to do for now) contains the run-once code for this component. If we had code that would be run repeatedly, it would be better to put that into the Helper class. Because we have none, I did not put anything in the helper.

({
    doInit: function(component, event, helper) {
        var action = component.get("c.getCurrentUser"); // method in the apex class
        action.setCallback(this, function(a) {
            component.set("v.runningUser", a.getReturnValue()); // variable in the component
        });
        $A.enqueueAction(action);
    }
})

This shows the standard base-code that I plan to use for my components: Much as there is an action tag in the apex:page Visualforce component, which calls an Apex method, here I use the c.doInit action, which is prefaced by c to show that it is called in a controller (and as we will see below, that refers here to the JavaScript controller, whereas in JavaScript it refers to the Apex controller). CurrentUserController - Apex Controller This Apex class allows us to query the database. Note that the method is static and has the @auraenabled annotation, allowing it to be seen by the JavaScript controller. I have kept the code simple; were I to do this for an ISV, I might describe the User sObject and then included all available fields in my query. Here, though, I just wanted first and last names.

public class CurrentUserController {

    @AuraEnabled
    public static User getCurrentUser() {
    	User toReturn = [SELECT Id, FirstName, LastName FROM User WHERE Id = :UserInfo.getUserId() LIMIT 1];
        return toReturn;
    }
}

The method getCurrentUser is called as c.getCurrentUser in the JavaScript. The c refers to controller, and to a different controller, depending on where it is used. Style documents I could have styled the h1 tag in any of the components I used, as well as the Application. While I don't think that styling in the Application is a good idea for any uses that I can imagine right now, I do think that care should be taken in choosing whether to style in the top-level component or a lower-level one. The Java developer in me thinks that much as we control access by declaring variables as finely as possible, we should handle styling in the same way. This is the CSS that I used. I put it in the UserFromUser Style document.

.THIS h1 {
    font-size: 24px;
    padding-left: 40px;
}

For more information

• Lightning Dev Guide
• Trailhead Lightning Module
• Configure Components for Lightning Pages and the Lightning App Builder
• Salesforce Lightning Component Newbie Notes
• Jeff Douglas: Building Your First Lightning Component