Discover Next Steps
- List five aspects of Aura components that you can explore in more depth.
- Plan three improvements you could make to the Expenses app.
- Earn. This. Badge!
You made it! We are thrilled for you, impressed by you, and proud of you. Seriously, this is a hard module, and earning this badge says a lot. Congratulations!
This unit’s challenge is all that stands between you and that badge, and after all the effort you’ve put in so far, we’re making this one easy. But, please don’t skip ahead! While this unit is “easy” in the challenge sense, if you want to be successful as a Lightning components developer, this unit is every bit as important as all of the others.
The Aura Components Basics module teaches the fundamentals of developing apps with Aura components, but it’s just the start. As long as this module has been to this point, there’s actually more to learn still ahead of you. At least, if you want to become a Lightning components master.
In this unit we’ll cover two topics. First, we’ll provide a survey of the kinds of things we didn’t have space to cover in this module, along with pointers for where you can start to learn about them. And after that we’ll suggest a couple of homework-style projects you could take on. There’s a number of “obvious” additions to our little expenses app that you could try to do yourself. The best way to learn is by doing!
As we were building the expenses app we had to say “we’re not going to cover this here” more times than we can count. We hated every one of them, and you probably did, too. But we believed you would hate us more if we filled up this module to eight hours or more.
Salesforce Lightning Design System
The SLDS is a robust, flexible, and comprehensive system for implementing the Lightning Experience style in your apps. You can use it in Lightning Components, Visualforce, and even in plain markup. A writer on the Salesforce documentation team used it to create prototypes of…wait, we can’t tell you about that yet.
SLDS is fun to learn, and even more fun to use. There’s a Trailhead module dedicated to it (using Visualforce), and number of Trailhead projects that illustrate its use. And there’s a wowza web site dedicated to getting it into people’s hands.
- Lightning Design System module
- Build a Lightning App with the Lightning Design System project
- Salesforce Lightning Design System site
Where You Can Use Lightning Components
We blazed through this topic in a flurry of screenshots, and we never looked back. But Lightning Components can be used in many, many ways within Salesforce, and even outside of it.
In particular, we spent all of our time building a stand-alone “my.app”. You’ll definitely want to learn how to add your apps to the Salesforce app and Lightning Experience. The good news is that it’s so easy, it’s going to make you wonder why we didn’t cover it. (Read on, partner.)
The Lightning Components Developer Guide is the best source of information about where and how you can use your Lightning Components apps.
- Add Lightning Components to the Salesforce App
- Add Lightning Components to Lightning Experience
- Configure Components for Lightning Pages and the Lightning App Builder
- Configure Components for Communities
- Use Lightning Components in Visualforce Page
- Add Lightning Components to Any App with Lightning Out
- Use Lightning Components with Flows
We covered only the most primitive debugging techniques. Learning to debug your Lightning Components apps, using several different sophisticated tools for doing so, is something that will pay dividends, in the form of hours of your life back, and hair not pulled out.
In particular, we recommend learning Chrome’s rich DevTools suite, and the Salesforce Lightning Inspector that works within it. Apex developers will also want to learn about the debugging tools available for Apex, many of them directly in the Developer Console.
- Google Chrome DevTools
- Salesforce Lightning Inspector Chrome Extension
- Lightning Components Debugging
We briefly mentioned that there are some “framework-specific” data types you can use for attributes. Chiefly these are used for facets, in particular the body facet. And we deliberately skipped facets, especially body, because they’re complicated, and they’re not essential for basic Lightning Components development. You’ll want to learn all about these concepts eventually, though, because being able to set a component’s body (or other facets) is a powerful technique that can save you a lot of code and awkwardness.
You wrote a fair bit of helper code in this module, but there are some advanced uses of helpers that are worth knowing. Since helpers are the chief way you share reusable code, it’s an important area to explore.
Server Request Lifecycle and Handling
We covered how to make a server request using $A.enqueueAction() and how to handle a successful response. There are other possibilities, and you really need to know how to handle them. There are also many different kinds of requests, and using the right one can significantly improve your app’s performance in some cases.
- Creating Server-Side Logic with Controllers
- Calling a Server-Side Action
- Queuing of Server-Side Actions
Security, Security, Security, Security
We lectured earlier, so we won’t here. But there’s a lot to know.
We mentioned these, and they’re important for larger apps. And while we covered event basics, there’s a lot to learn about them. You can’t build sophisticated apps with Lightning Components without learning all about events.
There’s also a number of topics we simply didn’t mention. Some of these are complex, some are advanced, and some are both. We’re listing a few here for your consideration.
Other Bundle Resource Types
We covered the four core Lightning Components bundle resource types. There are four others. While the Design and SVG resources have somewhat specialized purposes, the Documentation and Renderer resources are potentially useful in any Lightning component.
You would be forgiven for thinking this is fundamental. In any complex, real-world app it is. And in many cases, if you’re running inside of Lightning Experience or the Salesforce app, developing navigation is actually pretty easy. But, see the next item.
Dynamically Creating Components
One of the principal ways of “navigating” within your Lightning Components apps is to create new components dynamically, in response to user actions. This whole area is rich and powerful, and complex enough that you’d be slogging away at this module for a week. We’ll give you a search term and you can start to explore: $A.createComponent().
There’s handling server errors, and there’s handling errors that are purely client-side. For the purposes of this module, we assumed you’d always be successful. Sadly, in the real world, bugs and weird both happen with alarming reliability. The Great Engineer said it best: Anything that can go wrong, will go wrong. So you might as well plan to handle and recover from errors as best you can.
force: Namespace Components and Events
When your Lightning Components app runs inside Lightning Experience and the Salesforce app, there are a number of really cool components and events you can use. Some of these components work in other contexts, but many of them are only easy-to-use in Lightning Experience and the Salesforce app, and so we didn’t look at them.
Technically we touched on this, in the form of init handlers, but we didn’t explain that the init event is one of a suite of system events that you can catch during the component or app lifecycle. (For that matter, we didn’t talk about that lifecycle, either.) There’s a bunch of them, and you can use them to have your components “do something” at specific points in their existence, or to handle specific situations.
We hope we’ve whet your appetite for more Lightning Components learning. Here’s a couple of ideas we have for things you could do with the Expenses app that would make for interesting exploration, and that fit naturally with what you just learned.
Clear the Form After Submission
Right now when you click the Create Expense button, the form stays filled in. It’s not hard to set the fields to empty strings…but when should you do it? Think about the behavior you want, about usability, and about the various possibilities in terms of server responses. (That is, besides SUCCESS.)
Once you decide on behavior, where do you put the code? It sounds easy, at first, and then you realize the server response handling is in expenses, and the form fields are in expenseForm. What does this sound like a job for?
Display an “Expense Saved” Message
When your expense is successfully saved to the server, it would be nice to show the user a little success message. And maybe the message is different for updating the Reimbursed? checkbox vs. creating a new expense. Or, maybe sometimes you don’t show a message at all.
What happens if a data validation rule on a field prevents you from saving a record on the server? Or some other error happens? Right now, nothing; the app silently fails. For the Reimbursed? checkbox, the app can show an incorrect state for the expense. Both of these are bad!
Dealing with simple failures isn’t actually that many lines of code. But you’ll need to do some reading before you start.
Allow Expense Record Editing
This one is kind of advanced, but you can tackle it in stages. First, when you click on an expense in the expense list, have the form fill in with the appropriate expense values. Then have it change the text of the Create Expense button to Save Expense. (Don’t cheat and have it say Save Expense all the time!) Then change the event that the form fires to update the existing expense instead of creating a new one.
And, with that, we’ll leave you for today. Congratulations again, and we hope you’ll find fame, fortune, and excitement in your Lightning Components app development adventure!