Lightning Component: User Activation Example
Disclaimer: If you already know the difference between Visualforce/Classic vs Lightning, then you can skip to “Hey I have read about this already! I came here for the example.”
On 2015 Salesforce revealed the Lightning Experience, which is a UI to the platform’s famous CRM, and with it comes a Bootstrap-like framework, called “Lightning Design System”, to be used on custom pages within the platform (not mandatory though, but it is arguably prettier than most CSS developers can build).
Lightning Components introduce a whole new way of doing things within a page. On Salesforce Classic all you had was a Visualforce and an Apex controller class. On Lightning, however, you need:
- a component (.cmp)
- a controller (.js)
- a helper (.js)
- a server-side controller (.apxc) (which is more like a model, I suppose?)
Down below is what I understood about how different Lightning is from Visualforce:
Hey I have read about this already! I came here for the example.
Right. So while trying to learn what exactly I needed to do to learn Lightning, I decided to convert a basic functionality from a page I made couple of months ago. On that page, I list every user on my organisation that has a license with “Salesforce” on it, and display a checkbox to activate or deactivate the user. It was nice because accessing each user record from the Setup was consuming time. We wanted a single place to do this to every user.
So the page started with a simple Visualforce with an
apex:dataTable and a controller that would query users names, licenses and the
IsActive column. There were buttons to activate or deactivate the user, depending on their state.
How would I do that on Lightning?
First of all: create a Lightning Application. It will look like this, after we create our component:
Note that it will already “extend” the Salesforce Lightning Design System when we ask to extend it. Line 2 contains our actual component, which will look like this:
We declare on lines 2 and 3 a variable and an event handler. One will hold our data (user list) while the other will fire the initial event when the page is initialised. Thinking about this handler, it actually acts like a VF Controller constructor, getting all the data necessary for the page to work properly. We would probably put our query inside the constructor, if this were a Visualforce…
… but since it is not, we will call our JS controller below to get our data instead.
This little guy does one thing: it will call the specific helper method depending on what we need right now. If we are initialising the page, we will call the
doInit method, like you can see on line 3 of the component. If we are saying a certain user should be activated or deactivated, then it will pass the user’s id and current status to the helper function responsible to call our Apex code. Simple.
I’ve noticed that the
event can be used to get the parameters in your
input tag, like
checked, which are the user’s id and current state.
Finally, we have our helper, that does a little more weight lifting than the other code:
This guy’s methods are going to call our controller’s (below) methods, and in case we are changing the state of a user it will also receive parameters (see
setParams on line 14).
So to sum it up:
User opens the page, then the
init handler on the component calls the controller, which calls the helper method to get the list of users, which calls the database using the Apex class method.
After this, the page will be presented to the user like this:
And if you click on the toggle icon…
It isn’t that hard when you know what to use. And probably there is a better way of doing this using a component like
<ui:checkBox>, but I couldn’t find another way.
The hardest part was to figure out how to pass parameters from the component to the controller, I admit. I think you can pass the whole object to the controller (instead of just the id, for example), but I haven’t tested this way.
I’m thinking of converting another functionality on this page that will probably use a modal to set some values to the users’ records. I can (and probably will) write another text if (when?) I succeed.