Lightning Components
Lightning Components are the building blocks of the Salesforce Lightning user interface.
Definition
Lightning Components are the building blocks of the Salesforce Lightning user interface. Each component bundles a template (markup), JavaScript controller, optional Apex backend, CSS styles, and metadata into a reusable unit that admins compose onto pages via the Lightning App Builder. Two generations exist: Aura components (the original Lightning framework from 2014) and Lightning Web Components (LWC, introduced in 2018 and built on modern web standards). New development should use LWC; Aura is supported but deprecated for net-new work.
Lightning Components run inside the Lightning Experience UI, the Salesforce mobile app, Experience Cloud sites, and Lightning Out embeds in external pages. They communicate with the Salesforce backend via Lightning Data Service, Apex method calls, or the User Interface API. Page layouts, record pages, app pages, home pages, and Experience Cloud pages are all assembled from Lightning Components, mixing standard components (provided by Salesforce) with custom components (built by admins and developers). The component model is the foundation of modern Salesforce front-end development.
How Lightning Components shape modern Salesforce UI
Aura versus Lightning Web Components
Aura was the original Lightning framework, with its own component model, expression language, and event system. Lightning Web Components arrived in 2018 built on modern web standards (ES6+ JavaScript, Web Components, custom elements, shadow DOM). LWC performs better, follows industry-standard patterns, and is the direction for all new development. Aura components still work and integrate with LWC in the same page, but Salesforce has been clear that net-new component development should use LWC. Migration from Aura to LWC is a multi-year effort for any org with substantial Aura inventory.
Component file structure (LWC)
An LWC component is a folder with files sharing the component name: myComponent/myComponent.html (template), myComponent.js (controller), myComponent.css (styles, optional), myComponent.js-meta.xml (metadata declaring where the component can be used). The HTML template uses standard markup with directives like for:each, if:true, lwc:if. The JS controller exports a class extending LightningElement with reactive properties (@track, @api), wired Apex methods (@wire), and event handlers. The metadata file controls visibility in App Builder, target pages, and exposed properties.
Lightning Data Service and the @wire decorator
Lightning Data Service (LDS) is the data layer that lets LWC components read and modify Salesforce records without writing Apex. The @wire decorator binds a component property to an LDS function (getRecord, getRecords, createRecord, updateRecord). LDS handles caching, shared state across components, and automatic re-render when the underlying record changes. For most simple CRUD interactions, LDS is the right choice; Apex is necessary for complex queries, multi-record DML, or business logic that LDS cannot express.
Apex integration and @AuraEnabled methods
When LDS is not enough, LWC components call Apex methods marked @AuraEnabled. The @wire decorator binds method results to component properties reactively. Imperative calls return promises for one-off invocations. Apex methods called from LWC must be in classes marked with sharing context, must respect FLS and CRUD permissions (or use the WITH USER_MODE keyword), and should return JSON-serializable data structures. Cacheable methods (with the cacheable=true attribute) are eligible for client-side caching, dramatically improving performance.
Lightning App Builder and component composition
Admins compose Lightning Components onto pages via the Lightning App Builder. Drag standard or custom components onto record pages, app pages, home pages, or Experience Cloud pages. Set component properties (filter strings, default values, picklist API names) in the property panel. Configure component visibility rules so different user populations see different layouts. The composition model lets admins build sophisticated UIs without touching code, as long as the available components cover the requirements.
Component events and inter-component communication
LWC supports several inter-component communication patterns. Parent-to-child via @api properties. Child-to-parent via CustomEvent dispatch caught by parent listeners. Cross-component via Lightning Message Service (LMS) or pubsub modules. Choose based on the component relationship. Direct parent-child is the simplest; LMS handles loosely-coupled cross-tab or cross-page coordination. Avoid global state via window or document because shadow DOM isolation makes those patterns fragile.
Performance, testing, and deployment
LWC performance is generally better than Aura because the framework leverages browser-native Web Components. Component testing uses Jest with the Salesforce LWC Jest runner. Deployment via SFDX, change sets, or metadata API treats components as bundles (folder of files). Production code coverage requirements apply to Apex methods backing LWC components; pure-LWC code is not subject to the same coverage rules but should still have meaningful Jest tests. Salesforce ships a Lightning Web Security framework that enforces stricter isolation than the older Lightning Locker Service.
How to build a Lightning Web Component
Building an LWC is straightforward once the toolchain is set up. SFDX project, VS Code with the Salesforce Extensions Pack, scratch org or sandbox for development, Jest for tests. The hard part is designing components small enough to compose cleanly and writing the metadata file so admins can drop them into pages without surprises.
- Set up the SFDX project and toolchain
Install Salesforce CLI and VS Code with the Salesforce Extensions Pack. Create an SFDX project: sf project generate. Authenticate to a sandbox or create a scratch org. The project structure puts LWC components in force-app/main/default/lwc/.
- Generate the component skeleton
sf lightning generate component --type lwc --name myComponent. This creates the four-file bundle (HTML, JS, CSS, meta XML). The CLI handles the boilerplate so you can start with the actual logic immediately.
- Write the HTML template
The template uses standard HTML with directives. lwc:if for conditional rendering. for:each for iteration. {variableName} for data binding. Lightning Design System components (lightning-card, lightning-input, lightning-button) provide built-in styling.
- Write the JavaScript controller
Import LightningElement and decorators (@api, @track, @wire). Define reactive properties. Wire Apex methods or LDS functions for data. Handle DOM events with named methods. Use @api for public properties parents can set; @track is no longer required for deep reactivity in modern LWC.
- Configure the metadata XML
Set isExposed to true. Add targets (lightning__RecordPage, lightning__AppPage, lightning__HomePage, lightning__FlowScreen) where the component can be placed. Declare design properties admins can configure in App Builder.
- Write Jest tests
Create __tests__/myComponent.test.js. Use Jest with the LWC test helpers (createElement) to assert rendered output, simulate events, and verify wire data handling. sf force lightning lwc test run executes the suite.
- Deploy and place on a Lightning page
Deploy via sf project deploy start. Open the App Builder for the target page, drag the component from the custom-components section, set the design properties, save and activate. Verify in the browser as different user profiles.
- Monitor performance and errors
Use Chrome DevTools to profile render time and JavaScript execution. Setup > Debug Logs captures Apex errors triggered from LWC. Lightning Usage tracker shows component performance metrics. Iterate on slow components based on real-world traffic.
LWC for all net-new development. Aura supported but deprecated for new work. LWC and Aura can coexist on the same page.
Which Lightning page types the component can be placed on: record pages, app pages, home pages, flow screens, Experience Cloud sites.
@AuraEnabled methods for custom queries and DML. LDS handles simple CRUD without Apex; Apex needed for complex business logic.
- Aura is supported but deprecated for net-new development. Building new Aura components creates technical debt that will need migration to LWC eventually.
- Apex methods called from LWC must respect FLS and CRUD permissions explicitly. Use WITH USER_MODE in SOQL or check Schema permissions before DML to avoid security review failures.
- Cacheable Apex methods (cacheable=true) cannot do DML and cannot make callouts. The platform enforces this because the result is cached client-side.
- Inter-component communication has multiple patterns (parent-child via api, child-parent via events, cross-component via LMS). Picking the wrong pattern produces brittle component coupling.
- LWC components run inside Lightning Web Security (or older Lightning Locker), which restricts access to globals like window and document. Code that works in plain HTML may fail in LWC due to isolation rules.
Trust & references
Cross-checked against the following references.
- Lightning Aura Components Developer GuideSalesforce Developer
- Lightning App BuilderSalesforce Help
Hands-on resources to go deeper on Lightning Components.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What skill set is typically needed to work with Lightning Components?
Q2. What is required before deploying Lightning Components-related code to production?
Q3. Where would a developer typically work with Lightning Components?
Discussion
Loading discussion…