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.