12.2 Aura Component Structure & Resources

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

12.2 Aura Component Structure & Resources

Key Takeaways Explain This Topic AI

An Aura component is a bundle of resources: component markup, controller, helper, style, design, documentation, renderer, and optional SVG

aura:attribute defines typed public/private data on the component; expressions bind attributes into markup

Client-side controller methods handle UI events; helpers hold shared JavaScript logic; server-side Apex controllers use @AuraEnabled methods

Component events target ancestors in the containment hierarchy; application events broadcast more widely—prefer component events when a parent-child path exists

Platform Developer I may still test Aura structure conceptually even though LWC is preferred for new UI
Last updated: August 2026

12.2 Aura Component Structure & Resources

Quick Answer: An Aura component is a bundle of files: component markup, controller (client JS), helper , style (CSS), design , documentation , optional renderer , and optional SVG . Data is declared with aura:attribute . UI actions call the client controller (often delegating to a helper ); server work uses an Apex controller with @AuraEnabled . Component events bubble to parents; application events are broader. Know this structure even if you build new UI in LWC.

Section 12.1 established LWC as the modern default. This section covers Aura literacy the exam still expects: what lives in a bundle, how attributes work, how client and server controllers split responsibilities, and how Aura events differ.

The Aura Component Bundle

In the Developer Console or metadata, an Aura component is a folder-like bundle , not a single file. Typical resources:

Resource Role

Component ( .cmp ) Markup: HTML-like tags, aura:attribute , aura:handler , nested components, expressions {!v.attr} / {!c.action}

Controller ( .js ) Client-side JavaScript action handlers bound to UI events
Helper ( .js ) Shared client-side functions; controllers stay thin and call helpers
Style ( .css ) Component-scoped CSS (Aura scoping conventions apply)
Design ( .design ) App Builder exposure: which attributes admins can set on the page
Documentation ( .auradoc ) Description and samples for component library docs
Renderer ( .js ) Optional custom rendering lifecycle overrides (advanced; rarely the first choice)
SVG Optional custom icon for App Builder / component palette

Exam tip: Match the resource to the job. “Make an attribute editable in App Builder” → design . “Share logic between two controller actions” → helper . “Call Apex” → Apex class with @AuraEnabled , invoked from the client controller/helper—not from the .cmp file directly as raw Apex code.

Minimal markup shape

<aura:component controller="AccountPanelController" implements="flexipage:availableForRecordHome,force:hasRecordId">

<aura:attribute name="recordId" type="String" />
<aura:attribute name="accountName" type="String" />

<aura:handler name="init" value="{!this}" action="{!c.doInit}" />

<lightning:card title="{!v.accountName}">
<lightning:button label="Refresh" onclick="{!c.handleRefresh}" />
</lightning:card>
</aura:component>

Key ideas in that snippet:

controller="AccountPanelController" points at the Apex server controller class name

implements interfaces control where the component can be placed (for example record pages) and which platform attributes (like recordId ) are available

aura:handler name="init" runs client logic when the component initializes
{!v.accountName} reads a view attribute; {!c.handleRefresh} references a client controller action
Attributes
aura:attribute declares typed data on the component: <aura:attribute name="contacts" type="Contact[]" />
<aura:attribute name="maxRows" type="Integer" default="10" />
<aura:attribute name="showPanel" type="Boolean" default="true" access="private" />

Concern Detail
Name Referenced as v.name in expressions
Type Primitives, sObjects, lists, custom Apex types (with caveats), component references
default Initial value
access public (default for many cases), private , global —affects who can set/see the attribute
required Whether the attribute must be provided

Attributes are the Aura analogue of LWC public/ @api properties and internal fields. Parent components set child attributes in markup: <c:childPanel maxRows="{!v.pageSize}" />

Design attributes in the .design file surface selected attributes to Lightning App Builder so admins can configure the component without code.

Client Controller vs Helper vs Server Controller
Client-side controller
The client controller maps UI events to functions: // accountPanelController.js
({
doInit: function (component, event, helper) {
helper.loadAccount(component);
},
handleRefresh: function (component, event, helper) {
helper.loadAccount(component);
}
})

Signature pattern to recognize: function (component, event, helper) .

component : read/write attributes ( component.get("v.accountName") , component.set(...) )
event : source event data
helper : shared helper methods
Helper

Helpers avoid duplicating logic across multiple controller actions and keep controllers readable: // accountPanelHelper.js

({
loadAccount: function (component) {
var action = component.get("c.getAccount");
action.setParams({ accountId: component.get("v.recordId") });
action.setCallback(this, function (response) {
var state = response.getState();
if (state === "SUCCESS") {
component.set("v.accountName", response.getReturnValue().Name);
} else if (state === "ERROR") {
// surface errors to the user
}
});
$A.enqueueAction(action);
}
})

Pattern to memorize:

component.get("c.apexMethodName") — c. here means server Apex method , not the client controller
setParams → setCallback → $A.enqueueAction(action)
Check response.getState() for SUCCESS , ERROR , INCOMPLETE
Server-side (Apex) controller public with sharing class AccountPanelController {
@AuraEnabled
public static Account getAccount(Id accountId) {
return [
SELECT Id, Name
FROM Account
WHERE Id = :accountId
LIMIT 1
];
}
}

Rules that show up on exams and code reviews:

Methods called from Aura/LWC must be @AuraEnabled (and often static for these controllers)
Prefer with sharing unless there is a deliberate system-context reason otherwise
Enforce CRUD/FLS as appropriate for the data exposure
Return serializable types; avoid patterns that cannot travel over the wire cleanly

Client vs server split: UI state, show/hide, and simple calculations stay client-side. Database access, security-sensitive decisions, and complex business rules belong on the server.

Events: Component vs Application (High Level)

Aura’s event model is a frequent conceptual question.

Component events
Defined with a component event type and fired by a child
Travel through the containment hierarchy (bubble/capture toward parents)
Best when a parent (or ancestor) should handle the child’s notification
Lower coupling blast radius than application events
Application events
Broadcast more like a pub-sub channel across the app (handlers register interest)
Useful when components are not in a direct parent-child relationship
Easier to create surprising cross-talk if overused

Exam heuristic: If the communication path is parent ↔ child, choose a component event (or, in modern LWC, CustomEvent ). If components are siblings or distant and must coordinate, application events (Aura) or Lightning Message Service (modern) are the conceptual match.

<aura:handler name="saveComplete" event="c:saveCompleteEvent" action="{!c.onSaveComplete}" />
Renderer and Other Advanced Bundle Pieces

The renderer lets you override default DOM rendering lifecycle methods. On PDI, treat custom renderers as advanced / rare . Prefer standard markup binding and base components. SVG resources customize the icon shown in builders. Documentation resources matter for team libraries, not typically for deep exam calculation.

When the Exam Still Asks Aura Structure

Expect Aura-oriented items when the question:

Shows a bundle file list and asks which file holds App Builder-exposed attributes → design
Asks where shared client JavaScript should live → helper
Shows {!c.doSomething} vs {!v.field} and asks what each means → client action vs attribute
Contrasts component events and application events
Mentions $A.enqueueAction or response.getState()
Describes an existing Aura component that must be extended or diagnosed

You may also see “which interface makes the component available on a record page?”-style questions ( flexipage:availableForRecordHome , force:hasRecordId , and similar implements values).

Aura vs LWC Mapping (Study Aid)

Aura concept Rough LWC analogue
.cmp markup .html template
Client controller + helper .js class methods
aura:attribute fields / @api properties
Apex @AuraEnabled + enqueueAction @wire or imperative Apex
Component event CustomEvent
Application event LMS / pub-sub pattern
.design js-meta.xml targets + properties
Style resource .css (Shadow DOM scoped in LWC)

Use this table to transfer knowledge—not to assume APIs are interchangeable. Markup and lifecycles differ.

Practical Pitfalls
Forgetting $A.enqueueAction so the server call never runs
Mutating attributes incorrectly or expecting two-way binding everywhere without handlers
Putting heavy logic only in the controller and duplicating it across actions instead of using a helper
Using application events for simple parent-child communication
Assuming client-side checks replace sharing and FLS on Apex

Bottom line: An Aura component is a multi-file bundle . Know component / controller / helper / style / design / documentation / renderer / SVG , aura:attribute , the client controller + helper + @AuraEnabled Apex path, and component vs application events . Even as LWC dominates new work, these Aura structures still appear on Platform Developer I at a conceptual level.