Learn About Bundles and the Request Lifecycle
- Describe the difference between a Visualforce page and a Lightning component bundle, and how each is represented in resources locally and on Salesforce.
- Describe basic differences in the Visualforce and Lightning component request lifecycle, and where component code runs.
In this module, we look at Visualforce concepts and features, and then describe the closest translation into Lightning components. Not everything maps cleanly across. The two frameworks 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 Lightning components features in detail here. (That’s the Lightning 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.
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 the Force.com IDE 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.
A Lightning component has more to it than a single code artifact plus metadata, with up to eight code artifacts today. For this reason, an individual component is stored in a bundle that includes resources. This is represented as a folder of files when you save it to your local storage. A complex component might look like this on disk, in the metadata/aura directory:
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 Components Developer Guide.
It’s easy to create and switch between resources using the Force.com IDE, which has a row of tabs at the bottom of each component’s window dedicated to exactly that.
To create a new Lightning component, choosefrom the Lightning Platform options, and then choose Lightning Component for the type. Once the main component is created, the Force.com IDE adds additional resources to the bundle as you click the tabs below the component.
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||Lightning 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 Lightning 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.