trailhead

Learn About Bundles and the Request Lifecycle

Lightning bolt icon used to indicate that the content is for Lightning Experience

Attention, Trailblazer!

Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Lightning Experience.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

Learning Objectives

After completing this unit, you’ll be able to:
  • 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.

Core Concepts

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.

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 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:

  • yourPageName.page
  • yourPageName.page-meta.xml

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: An example component bundle

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. Example component bundle open in the Force.com IDE

Ladder! To create a new Lightning component, choose File | New | Lightning Bundle from 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.

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.

Classic Visualforce runs “on the server side.” That is, when a page is requested, a Salesforce server processes the markup, and then the resulting HTML is sent to the requesting user’s browser for display. If the page has an expression (those things inside “{! }” delimiters), it’s evaluated by the server. References to global variables are resolved on the server. If the page accesses a controller property, that’s processed on the server. And so on. For the purposes of this conversation, all of the “framework processing” happens on the server. (Note that we’re setting aside using Visualforce + JavaScript remoting as a mere container for your JavaScript app. But then you’re not really using Visualforce, except as a web server.)

The process for Lightning components is the opposite. When a component is requested, the component’s resources are packaged up and sent to the requesting user’s browser. Most of this is JavaScript, with some markup providing structure. The browser runs that JavaScript, which renders the resulting HTML and inserts it into the existing “page.” (We’ll explain those quotation marks shortly.) Expression evaluation, global variables, controller properties—those are all resolved on the client.

Visualforce Request Cycle Lightning Components Request Cycle
Visualforce request lifecycle Lightning component request lifecycle
  1. User requests a page
  2. The server executes the page’s underlying code and sends the resulting HTML to the browser
  3. The browser displays the HTML
  4. When the user interacts with the page, return to step one
  1. The user requests an application or a component
  2. The application or component bundle is returned to the client
  3. The browser loads the bundle
  4. The JavaScript application generates the UI
  5. When the user interacts with the page, the JavaScript application modifies the user interface as needed (return to previous step)

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.

That sounds straightforward, or even obvious. But keep in mind, with classic Visualforce that interaction would come with a new, visible page request and reload. With a Lightning component, the user’s interaction with client-side JavaScript feels more “live,” more responsive, so when the time comes to load new data, the latency of a server request can suddenly feel slow to the user—even if the overall experience takes less time than a Visualforce 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.

Resources

Lightning bolt icon used to indicate that the content is for Lightning Experience

Remember, this module is meant for Lightning Experience. When you launch your hands-on org, switch to Lightning Experience to complete this challenge.

retargeting