Lightning Component Zero to Hero
Welcome to the first post in my new series that will help you go from zero to hero with the Lightning Component framework. In this first post we ae going to take our first tentative steps by learning what exactly a Lightning Component is as well as the architecture of the Lightning Component framework at a very high level. We will round up with a look inside a component (the component bundle) and then be ready to get going in the next post.
So what is a Lightning Component then?
The short answer is whatever you want it to be!
That was simple eh? So the more serious long answer is:
A Lightning Component is a bundle of functionality that you may want to reuse in multiple scenarios throughout an application. You won’t believe this but I spent a long time writing that definition - all 20 words of it. The reason it took so long (aside from me being slow) is that a Lightning Component does not have to have a user interface, does not have to be something that you will definitely reuse many times and is more of a logical grouping of functionality by a developer.
Clear as Mud
Okay, I know the definition and paragraph above have a fair amount of hand-waving at first glance but please hear me out on this. The Lightning Component framework moves the Salesforce platform towards a more modern way of developing applications and away from the “traditional” server-side rendering of Apex and Visualforce. Whilst there is a very active debate as to whether such a shift makes applications faster, in general for Salesforce it should theoretically improve page performance for users. Why? Because instead of waiting for the Salesforce pod to render your page and send it down to you, you simply send down the component and your local machine does all the work, only sending and retrieving the data it needs from Salesforce. Obviously this has been made possible over the past few years as faster computers and more efficient JavaScript engines mean your local machine can handle such processing with relative ease.
Aside from just making the application more performant in some instances, the move to a component framework helps drive developers to be more productive as they componentize their application into chunks of reusable functionality. Lets take creating a task as an example. A task in Salesforce can be attached to almost any other object in Salesforce. Lets say I have devised a brilliant task entry system that makes entering this information really easy, wouldn’t it be good to be able to use this same entry system anywjere within Salesforce? By making this into a component, we can abstract away the common elements into a component and then just pass in some parameters to handle the dynamic elements of the component, in this instance the Id of the record we are associating the Task to.
Now this would make you believe that all components need to have a UI and this is why I was very careful with my definition. A component is just any bundle of functionality - it could simply be a set of logic and code to help you make a call to another site or service (for example an API to recieve a stock price). Credit here for the concept of “Lightning Service Components” goes to Dave Carroll, a concept which I intend to blog further about. However, for now (before we start getting into how componeonts communicate), just understand that a component can include other components and as such does not need to have any UI.
Enough of the Theory…
Okay, now we have laboured over the philosphical nature of what a Lightning Component is, lets actually break down what makes up a Lightning Component.
Your bundle
A Lightning Component is actually a bundle of things which together are called the “Component” or “Component Bundle”. Lets have a look at what actually makes up a component bundle and what all these pieces are for.
Component
This is the UI for your component (if we have one). In here will be some HTML style markup tags which will be used to display data on the page. This is where we put anything we want to see on screen.
Controller
Here sits the JavaScript to react to any events that occur from our component markup, for example pressing a button or entering some text in a field.
Helper
This is the JavaScript that we want to call to interact with the Salesforce servers or fire off some event in the background.
One of the hardest things for many people to figure out when first getting to grips with the Lightning Component Framework is “when should something be in the controller and when should something be in the helper? This is something you will get to grips with more over time but the correct answer is that any JavaScript which is not interacting with the UI should be in the Helper class (or in the Renderer which we will get to in a minute). In reality this doesn’t always happen and sometimes for small components people will just keep their JavaScript all in the controller - pragamatism can often override strict techncial correctness.
Style
This is the custom styles for your component’s user interface - no UI = no styles. This is just a standard CSS file.
Documentation
This file holds all the documentation details for your component including sample code showing how it an be incorporated if necessary.
Renderer
This JavaScript file is used to enable a developer to override the rendering lifecycle of the component so that they can perform additional custom rendering tasks. Typically you will not need to touch this class.
Design
This file contains information around how to apply your component and is required if you wish your component to be available in Lightning Pages, Communities or Lightning App Builder.
SVG
If you want a custom icon for your component in the Lightning App Builder then add it here.
Next Time
In the next post we will start building our own Lightning Component by discussing what we are going to build and then working on a basic UI for us to display our data.