SLDS — Salesforce Lightning Design System

• Official CSS framework: buttons, cards, forms, icons, tables, spacing, typography, grid.
• Gives consistent look, accessibility, responsiveness, and branding — with no custom CSS required.

<!-- Instead of -->
<button>Save</button>

<!-- Use (SLDS applied automatically) -->
<lightning-button label="Save"></lightning-button>

Shadow DOM

• Each LWC gets its own isolated DOM — CSS from one component cannot leak into another.
• Benefits: CSS isolation, no style conflicts, better performance, encapsulation.

Accessibility

• Keyboard navigation, screen readers, color contrast, labels, ARIA support, focus management.
• Best practice: always provide labels, don't rely on color alone, meaningful alt text, proper headings.
• aria-label, aria-hidden, aria-expanded — know purpose only.

Responsive & performance

• Use lightning-layout instead of HTML tables — responsive, clean, reusable.
• Salesforce encourages mobile-first design.
• Performance: lazy loading, reuse components, minimize SOQL, use Lightning Data Service & Wire Service, prefer Base Components.

HTML file

Root element must be <template> — a div root is a common trap.

<template>
    <lightning-card title="Welcome">
        Hello World
    </lightning-card>
</template>

JavaScript file

Every component extends LightningElement.

import { LightningElement } from 'lwc';

export default class HelloWorld extends LightningElement {
}

Template directives

PD1 uses current syntax lwc:if (not the older if:true).

<template lwc:if={show}>
    Visible
</template>

<template for:each={accounts} for:item="acc">
    <p key={acc.Id}>{acc.Name}</p>
</template>

Every repeated item needs a unique key (usually Id) for render performance.

Getters, setters & querying

get fullName() {
    return this.first + ' ' + this.last;
}
// HTML: {fullName}  — no parentheses

@api
set record(value) { this._record = value; }
get record() { return this._record; }

this.template.querySelector('.foo');  // scoped to component

Static resources & custom labels

import logo from '@salesforce/resourceUrl/logo';
import LABEL from '@salesforce/label/c.MyLabel';

Custom Labels support translation — exam favorite.

Naming rules

• Folder name = camelCase (e.g. accountCard)
• HTML tag = kebab-case with c- prefix: <c-account-card>

Lightning Data Service (LDS)

• Access records without writing Apex. Automatically respects CRUD, FLS, and sharing.
• Benefits: caching, automatic updates, better performance, less code.
• Components built on LDS: lightning-record-form, lightning-record-view-form, lightning-record-edit-form.

<lightning-record-form
    record-id={recordId}
    object-api-name="Account"
    layout-type="Full"
    mode="view">
</lightning-record-form>

Record form comparison

Wire: property vs function style

• Property style — simple, just assigns to a property.
• Function style — use when you need custom processing; gives access to both result.data and result.error in one place.

@wire(getRecord, {...})
wiredAccount(result) {
    if (result.data) { /* ... */ }
    if (result.error) { /* ... */ }
}

'$recordId' (with $) marks a reactive parameter — when it changes, the wire re-runs.

Wire vs Imperative

Use imperative for button clicks, manual refresh, complex logic, or DML.

refreshApex()

• Wire data is cached — after a DML (create/update/delete) call refreshApex() to force fresh data.

import { refreshApex } from '@salesforce/apex';
refreshApex(this.wiredResult);

Security: LDS vs Apex

• LDS automatically respects CRUD, FLS, and sharing.
• Apex is NOT automatic — the developer must enforce security via WITH USER_MODE, stripInaccessible(), or Describe methods.

Parent → Child

Uses @api — the most common communication method. A parent can set a public property or call a public method.

// Child
export default class Child extends LightningElement {
    @api recordId;
    @api refresh() { /* ... */ }
}

// Parent template
<c-child record-id={recordId}></c-child>

// Parent JS — calling a public method
const child = this.template.querySelector('c-child');
child.refresh();

Child → Parent

A child cannot directly modify its parent. It dispatches a Custom Event; the parent listens and decides.

// Child dispatches
const event = new CustomEvent('selected', {
    detail: this.recordId
});
this.dispatchEvent(event);

// Parent listens (lowercase, "on" + event name)
<c-child onselected={handleSelected}></c-child>

handleSelected(event) {
    const id = event.detail;   // data always in .detail
}

LMS vs Pub/Sub

Slots & composition

<!-- Child -->
<slot></slot>

<!-- Parent -->
<c-card>
    <p>Hello</p>
</c-card>

<!-- Named slot -->
<slot name="footer"></slot>
<div slot="footer">Save</div>

Salesforce prefers composition (many small components) over inheritance (extending a class) — rare in LWC.

Common components

• apex:form — required for any input/button to submit
• apex:pageBlock / apex:pageBlockSection — Salesforce-styled sections
• apex:inputField vs apex:outputField — editable vs read-only, both metadata-aware
• apex:commandButton / apex:commandLink — submit actions
• apex:repeat / apex:dataTable — loops and tables
• apex:pageMessages — shows errors, warnings, success, and info

inputField vs inputText

<apex:inputField value="{!Account.Name}"/>
<apex:outputField value="{!Account.Name}"/>
<apex:commandButton value="Save" action="{!save}"/>
<apex:pageMessages/>

Misc features

• Expressions: {!Account.Name}, {!message}
• Static resources: {!$Resource.logo}
• PDF rendering: <apex:page renderAs="pdf"> (LWC has no native PDF equivalent)
• URL params: ApexPages.currentPage().getParameters().get('id')

Security

• Standard Controller automatically respects sharing, CRUD, and FLS.
• Custom Controller — developer is responsible for enforcing all security.

Core files

Component attributes

Attributes hold component state, referenced with the v. value provider — a frequent exam clue.

<aura:component>
    <aura:attribute name="message" type="String" default="Hello"/>
    {!v.message}
</aura:component>

Design resources & base components

• A design resource exposes attributes to builder tools (Lightning App Builder, Experience Builder, Flow Builder) — a classic Aura-vs-LWC clue.
• Salesforce still prefers standard Base Components and SLDS-backed UI over custom raw markup, regardless of framework.

Coexistence & migration

• Aura and LWC can coexist in the same application — Salesforce documents this explicitly.
• Modernization direction: move existing Aura toward LWC over time; new development always targets LWC.
• Developer Console still works with Aura, but modern tooling (Code Builder, VS Code) is the strategic direction.

stripInaccessible()

• Checks records for fields the current user cannot access and returns sanitized records.
• Use it after you already have records, to avoid leaking restricted field values back to the UI.

Apex class access for @AuraEnabled

• Even with correct code, an @AuraEnabled method is only callable when the user's Profile or Permission Set grants access to that Apex class.
• Modern guidance favors WITH USER_MODE/stripInaccessible() over manual Schema.Describe checks.

CSP & third-party libraries

• Lightning apps should use the stricter CSP setting to prevent unsafe/inline script execution and protect org security controls.
• LWS makes third-party libraries easier to isolate safely — it does not make every library automatically safe.

Base components & accessibility

• Base components (lightning-button, lightning-input, lightning-card, etc.) ship with accessible HTML, SLDS styling, keyboard support, and correct ARIA roles — following W3C best practices.
• They are the safest PD1 answer whenever a base component exists for the job, over hand-rolled markup.