Live Preview and the New LWC Dev Loop in Summer '26

Summer '26 makes Single Component Live Preview and the Live Preview VS Code extension generally available for LWC. The important change is not the rename from Local Dev. It is removing a deployment from the middle of small UI decisions.

Salesforce Live Preview showing a single Lightning web component in the browser

Four useful preview loops

1. Isolate one component

Run a browser preview directly from the CLI:

sf lightning dev component --target-org my-sandbox --name alarmList

This is the fastest loop for markup, CSS, empty states and event handlers. The preview toolbar can resize the component, so a row can be tested at utility-panel, record-column and mobile-like widths without building several temporary pages.

2. Keep the preview in VS Code

The extension can open an LWC in the Lightning Preview panel from the component folder or command palette.

Salesforce Live Preview extension showing an LWC preview inside VS Code

The value is simple: edit the component and judge it without leaving the editor. That matters when the work is a dozen small corrections rather than one large change.

3. Test the app context

An isolated component cannot reveal every problem. Preview the containing app when layout, navigation or the page shell matters:

sf lightning dev app --target-org my-sandbox --name "Service Console"

For supported mobile tooling, add a device type:

sf lightning dev app \
  --target-org my-sandbox \
  --name "Field Service" \
  --device-type ios

That is useful for compact task cards, action panels and record summaries that look fine in desktop Chrome but fail where users actually touch them.

4. Know when to return to the org

Live Preview handles common HTML, CSS and straightforward JavaScript edits well. Public API changes, wire configuration, GraphQL queries, new @salesforce imports and .js-meta.xml changes may require a refresh, deployment or preview restart.

Use the smallest loop that can answer the question:


Does the spacing or wrapping work?	Component preview
Does it fit the page shell?	App preview
Does a metadata target work?	Deploy to the org
Do permissions and automation behave correctly?	Real user testing
Is the logic stable?	Automated tests

Faster feedback, not a substitute runtime

Live Preview is most valuable for the small checks that make up frontend work: whether a spinner clears, a label wraps, an empty state fits or an action remains reachable at a narrow width.

It does not replace sandbox testing or automated tests. It makes the earlier design loop cheap enough to repeat. That means fewer deployments for two-line changes and better components before they reach the final gate.