Review Fundamental Skills
- Evaluate if you’re really ready for Aura components.
- Describe what Aura components are.
- Identify where and why to use Aura components.
This module, and the others in this trail, are for folks who are experienced with Visualforce and want to use their Lightning Platform expertise to accelerate learning about Aura components. Maybe you looked at the (nine unit!) Aura Components Basics module and said “I’ve got a job to do, and it’s not Trailhead. Isn’t there something faster?”
This module, and this trail, is designed for you.
Before we start, a heads-up. The Aura Component programming model is larger, more sophisticated, and more complex than Visualforce. That means there’s more to learn, and your Visualforce background doesn’t always give you an advantage.
Let’s make this visual. Did you ever play the game Chutes and Ladders (originally known as Snakes and Ladders) as a kid? The goal is to make it to the top of a zig-zag board. As you move along, you can land on ladders, which advance you forward, toward the top; or chutes, which send you backward, toward the bottom. To get to the top quickly, you want to land on ladders and avoid the chutes.
So, let’s pretend that learning Aura components is played on a similar board. The ladders up are your Lightning Platform and Visualforce expertise, and the chutes down are things you don’t know yet, or are areas where your Visualforce skills aren’t transferable. Because you already know Lightning Platform, you’d probably expect that the board is filled with ladders to help you up.
Alas, many of the things you know about Visualforce aren’t ladders. Aura components are quite different. If you make assumptions based on Visualforce, the things you already know can turn into chutes. It makes the board a little more challenging in terms of finding your way to the top.
The goal of this and the other modules in this trail is to help you avoid some of those chutes. To be specific, 22 of them, marked by this icon: .
Keep in mind, though, that the Aura Components Basics module will help you avoid many more. If you find yourself getting stuck on seemingly small things—sliding down chutes—maybe your time would be better spent doing the longer module? Just a thought. (We’ve got an icon for 26 more tips like that one: .)
When people ask us what Aura components are, we usually say something like the following:
Let’s take a moment and marvel at the buzz-wordy awesomeness of that description…
We’ll dive into the deep end of the pool about this in the Aura Components Core Concepts module, the next on this trail. And if you’re interested in some of the underlying motivations for why we designed Aura components the way we did, see “User Interface Development Considerations” in the Lightning Experience Development module (links in the Resources section).
- Variable declaration and scope rules
- Rules of comparison for equality, and evaluating truthiness and falsiness
- The difference between undefined and null, and how and when you need to check for them
- How to treat functions like variables, including passing them as parameters to other functions (callbacks)
- And, to truly master the framework, you’ll need to understand closures, at least enough to recognize and use the immediately invoked function expression (IIFE) pattern
The framework includes a number of built-in components, which we call the Base Lightning components. These components are modern, lightweight, and design-matched for Lightning Experience.But, while the collection is growing rapidly, it’s not yet as complete as Visualforce, and you’ll write many components from scratch. Make sure your HTML and CSS skills are current. You should be confident with HTML5, CSS3, and building pages that are responsive, mobile-optimized, accessible, and cross-browser compatible. If you know what flexbox, media queries, ARIA, and REM units are, and how to use them, you’re in the game.
One CSS tip. Try to write as little of it as possible for your components. Instead, use the Salesforce Lightning Design System (SLDS).
Using SLDS correctly is, at a high level, straightforward.
- Wherever possible in your Lightning components markup, use built-in components from the lightning: namespace—the Base Lightning components mentioned previously. These components are built with SLDS, and use it automatically.
- When you write HTML markup, style it by adding SLDS utility classes to the appropriate elements.
- Only as a last resort, or in limited special cases, should you write your own CSS styles for a component.
One thing to look out for. If you visit the SLDS site—an outstanding resource for learning to use the design system in detail—you’ll find that it uses the term “component” a lot. There’s a whole “component” library!
These are not Lightning components!
The SLDS site describes how to use SLDS in any web app context, whether with Salesforce, Ruby on Rails, PHP, or whatever. The “components” the site describes are idealized forms of web app user interface elements. They’re defined in static HTML and CSS only—there’s no executable aspect to any SLDS component.
And, most importantly—there are many more SLDS “components” than there are built-in Lightning components. SLDS describes the world of the future, a target we’re aiming for. For now, just because the SLDS site describes an Activity Timeline “component” doesn’t mean there’s a Lightning component that performs that function. And just because there’s an SLDS “component” for a badge, or a button, or a modal doesn’t mean that a Lightning component that provides a badge, button, or modal is the same. (It probably is. But it might not be. And it might change in the future.)
TL;DR: SLDS components are not Lightning components. If you don’t find what you need in a built-in Lightning component, use the SLDS site as your starting point for building it yourself.