Learn About Bundles and the Request Lifecycle
- Describe the difference between a Visualforce page and an Aura component bundle, and how each is represented in resources locally and on Salesforce.
- Describe basic differences in the Visualforce and Aura component request lifecycle, and where component code runs.
Before You Go Further
You should have a basic understanding of Salesforce DX projects and Salesforce CLI. You’ll also need to use a properly configured org in your Trailhead account and VS Code with the Salesforce Extension Pack. You can learn about all of this by completing the first two units in Quick Start: Lightning Web Components. There, you'll set up your Salesforce DX environment and Visual Studio Code.
In this module, we look at Visualforce concepts and features, and then describe the closest translation into Aura components. Not everything maps cleanly across. Visualforce and Aura have fundamental differences in architecture, and different requirements for how you use them to build apps. We’ll explain as many of those differences as we can, using the individual features as our signposts.
Note that we’re not explaining how to use Aura components features in detail here. (That’s the Aura Components Basics module.) Instead, we’re focused on making essential differences clear, so that you can avoid turning things that sound the same into chutes you spend time sliding down.
Concept: Page vs. Bundle
Before we tackle some of the abstract concepts, let’s look at something that’s fairly concrete: how an individual page or component is stored on Salesforce.
Visualforce pages (and Visualforce components, but let’s set those aside for now) are stored on Salesforce as a single entity, an ApexPage. When you use Salesforce Extensions for Visual Studio Code or another tool to copy your Visualforce pages to your local storage to work on them, an individual Visualforce page is represented as two files in the metadata/pages directory:
The first is the code for the page, and the second is the page metadata (API version, mobile settings, and so on).
Although your page might have dependencies on other artifacts, like an Apex controller or extension, static resources, and so on, they are separate from the page. Your page references them, but doesn’t include them.
An Aura component has more to it than a single code artifact plus metadata, with up to eight code artifacts plus metadata today (nine total). For this reason, an individual component is stored in a bundle that includes resources. This bundle is represented as a folder of files when you save it to your local storage. A complex component might look like this:
We’ll talk about the most important resources in the component bundle throughout the rest of this module. For the remainder, see the details in Component Bundles and elsewhere in the Lightning Aura Components Developer Guide .
- Press Command + Shift + P on a Mac or Ctrl + Shift + P on Windows or Linux to open the Command Palette.
- Create a project in the Command Palette using SFDX:Create Project.
- Create a component bundle in the Command Palette using SFDX:Create Aura Component.
In the challenge for this unit, you authorize Visual Studio Code to deploy files to your org. You need to know the username and password for your org. To get your Trailhead Playground username and password, see the
Trailhead Playground Management module.
For more information, see the Aura Components Skills & Tools module.
Concept: Server-Side vs. Client-Side
This is one of the two “obvious” biggies. Except, actually, what’s obvious about it? Let’s be clear about what this means, and then make sure some of the implications are clear, too.
|Visualforce Request Cycle||Aura Components Request Cycle|
This major architectural difference has major consequences. For example, your component can interact with a user without requiring a new server request, but if your component needs to save or load new data, that does require a server request.
You’ll find that Aura components perform well overall. However, without careful design of your server requests and how they affect the user experience, your users might very well think an app is “slow.”
We cover additional aspects of this divide in upcoming topics, but you need to keep the client-vs-server-side thing clear in your head when thinking about how the frameworks behave.