Aura Components Core Concepts

Learn About Bundles and the Request Lifecycle

• Core Concepts
  • This module looks at Visualforce concepts and features and describes the closest translation into Aura components
  • Aura and Visualforce have fundamental differences in architecture
• Concept: Page vs Bundle
  • Visualforce pages are stored in Salesforce as an ApexPage
    • An individual Visualforce page is represented as two files in the metadata/pages directory:
      • yourPageName.page - code for page
      • yourPageName.page-meta.xml - page metadata (API version, mobile settings, etc)
    • Page might have dependencies on other artifacts like an Apex controller/extension, static resources, etc. It references these, but doesn’t include them.
  • Aura components have many more files: 9 total
    • Each individual component is stored in a bundle that includes resources
    • See details in help documentation: Component Bundles and Lightning Component Framework
    • To create an Aura component bundle:
      1. Open Visual Studio Code
      2. Press CTRL+Shift+P to open command palette
      3. Create a project using SFDX:Create Project
      4. Create a component bundle using SFDX: Create Aura Component
    • Each bundle is represented as a folder of files when you save it to local storage. A complex component may look like this:

• Concept: Server-Side vs Client-Side
  • Visualforce runs “on the server side” When a page is requested, a Salesforce server processes the markup, and the resulting HTML is sent to the requesting user’s browser for display
    • Expressions on the page, references to global variables, if the page accesses a controller property - all this is processed on the server
  • Aura components are the opposite - they run “on the client” 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.
    • Expression evaluation, global variables, controller properties, are all resolved on the client.
  • Implications of this are significant:
    • Component can interact with a user without requiring a new server request, but if your component needs to save or load new data, this does require a server request.
    • Classic Visualforce would need a new, visible page request and reload
    • With Aura components, user’s interaction with client-side JavaScript feels more “live,” more responsive, so when time comes to load new data, latency of a server request can feel more slow to the user
      • Aura components perform well, generally, but without careful design of your server requests and how they affect UX, users may think an app is “slow”

Learn Architectural Concepts

• Concept: Page-by-Page vs. Single-Page Application
  • Traditional Visualforce-based apps involve creating a set of pages - users start on a list view, click a view link to navigate to a record view page, click edit to edit a record page, etc
  • Aura components are very different - single “page” for the entire app.
    • Called a “single-page application” (SPA)
    • SPAs load a single page and a lot of JavaScript - once loaded Javascript runs and updates the UI of the “page” from then on
    • Navigation is very different: Users navigate from “state to state” rather than “page to page”
• Concept: Page vs. Component
  • A Visualforce page is a “large” building block, and one cannot be nested within another
    • Visualforce page is intended to stand alone
  • Aura is different - “large” Aura components can be composed of dozens or hundreds of small components, themselves composed of even smaller components
    • Aura is designed to handle thousands of components assembled together into a single app
    • In software design, taking small, fine-grained components and assembling them up into a “next level” component is called “composition”
• Concept: Component vs. Component
  • Custom Visualforce components are less powerful, less functional than custom Aura components, but they are not bad
  • Aura components are better though - more sophisticated and more powerful
    • Aura components can fire and receive events to communicate between components
      • Work with framework or container events, or define your own
      • Write event handlers, and the framework takes care of the details of invoking them when the right event occurs
    • Aura component bundle structure has separate artifact for separate functions and automatically wires them together - good for organization
      • Creating something comparable in Visualforce means you’re writing framework code, not feature code
    • Aura components can be used in more contexts
      • Since its client-side code, you can use “Lightning Out” to pull “Salesforce” ceatures into other, non-Salesforce apps and contexts like SharePoint
• Concept: Application Containers
  • Application containers are an application context, or environment, in which your code runs
  • Different containers offer different services
  • Incomplete list of possible containers:
    • Salesforce Classic
    • Visualforce
    • Salesforce App
    • Lightning Experience
    • Lightning App Builder (LAB)
    • Lightning console apps
    • Communities
    • Lightning Components for Visualforce (LC4VF)
    • Lightning Out
    • Lightning for Outlook and Lightning for Gmail
    • Stand-alone my.app
• Container Services
  • one.app container provides a number of services, including handling events to go to a record, create or edit a record, open a URL, etc
  • Ex: force:createRecord event works great in Lightning Experience, but it will not work in a stand-alone app, or Lightning Out
  • If an event is fired in container where nothing is listening, there is no effect
• Beyond the Basics of Container Services
  • Writing your own container is possible but hard - whole engineering teams work on this
• Container Containment (“Russian Dolls”)
  • Application containers (like real-life containers) have boundaries and barriers to keep inside things in, and outside things out
    • Ex: In web applications and frameworks, the boundaries are based on an HTML iframe, which is enforced by the browser
  • You can nest containers: Ex:
    1. Lightning Experience container
    2. Lightning Page container
    3. Visualforce page (added to the Lightning Page using LAB)
    4. Aura component (added to the Visualforce page using LC4VF)
  • In example above, note that an Aura component can only access the services of the container it’s running inside, even if that container is inside another container
    • So Aura component can’t fire Lightning Experience events, because the Visualforce container doesn’t understand them
  • So, your component can only count on the services of the container it runs in - if you create a component for multiple contexts, you need multiple code paths to account for different sets of services
    
    
• Aura components are different from Visualforce pages in that:
  • Aura components are designed to be part of a single-page application, while Visualforce is built for multi-page applications
  • Aura components must be part of a larger whole, while Visualforce pages can stand alone
• An unintended consequence of not being mindful of the container your code is running in is that your code may fire an event that has no effect

Learn Coding Concepts

• Concept: Controllers
  • Standard Controller is a staple feature of Visualforce - it allows a lot of automatic behavior, such as reading/writing record data, without writing code. This does not exist for Aura components.
  • Remember Visualforce controllers run on the server side, whereas Aura components run on the client side
    • Visualforce controllers are written in Apex, Aura controllers are written in JavaScript generally and sometimes in Apex

• Concept: Actions
  • In Visualforce, an action is a controller method that returns a PageReference at the end of it. Usually attached to a button or a link, the action represents the work the user wants the app to do.
  • Aura component actions are similar - written in JavaScript and attached to user interface elements
  • Differences between Aura/Visualforce actions:
    • Visualforce: actions are methods defined on an Apex class, which provides some language infrastructure (instance variables, class and instance methods)
    • Aura: component actions aren’t defined in a class - they are function definitions declared on the value side of elements in a JavaScript object. Example below.
  • These Structural differences prevent controller code from accessing other functions/values inside the controller resource - you can’t declare helper methods in the controller, can’t create instance of static properties, etc.

({
    myAction : function(component, event, helper) {
        // add code for the action
    },  // <- Note the comma
})

• Concept: Properties vs. Attributes vs. “Expandos”
  • Apex properties are effectively instance variables with custom logic behind them
    • If defined in Visualforce controller, expressions on a page can use them
  • This is not possible in Aura component JavaScript controller files
    • Adding them to the helper makes them shared across all instances of your component - its more like a class static variable
• Component Attributes

If you need to access the value in an expression in your component markup, use a component attribute. These require minimally a name and datatype.

<aura:attribute name="myAttribute" type="Integer"/>

Reference the attribute in markup using standard expression syntax.

{!v.myAttribute}

Get and set the attribute value in controller JavaScript code using get and set methods.

({
    myAction : function(component, event, helper) {
        var counter = component.get("v.myAttribute");
        counter++;
        component.set("v.myAttribute", counter);
    }
})

• JavaScript Expandos and Private Attributes
  • JavaScript-savvy developers might be tempted to use a quirk of JavaScript and set a value on the component instance from within an action, called an expando
  • Expandos create an opportunity for subtle bugs and memory leaks, so they are not recommended by Salesforce

component._myExpando = "A new string variable";

• Concept: Method Calls vs. Events
  • Visualforce: Visualforce pages run on methods: expressions, properties, actions all boil down to function calls. This means there is a tight coupling between parts of your app
    • Page is tightly coupled with its controller and extensions, which might be tightly coupled with other Apex classes
    • This makes the relationships between pieces easy to follow, but potentially fragile
    • Analogy is a hard line connecting the caller to the callee, like a physical wire
  • Aura components are intended to be loosely coupled - the method for accomplishing this is events
    • Analogy is a wireless connection - firing an event is like a radio signal:
      • If there is someone out there listening on that frequency (IE has a handler for that event), it can take action when it receives the signal, but the radio operator won’t know if anyone is listening.
  • Salesforce advice is to:
    • Give principles of composition and loose coupling some time: its a new framework and needs time to sink in
    • Don’t treat methods the same as in Visualforce: Aura component methods have appropriate uses, but should not be used all the time
      
      
• Do Aura components have controllers that are analogous to standard and custom controllers in Visualforce?
  • No - writing controllers for Aura components involves writing more code than Visualforce controllers
• Which punctuation symbol is the #1 source of syntax errors in Aura component controller code? ,
• Events are the mechanism for loose coupling in the Lightning framework