Wire Service Patterns

Use this skill when the LWC data path needs to be intentional rather than incidental. The wire service is excellent for declarative, cache-aware reads, but only if the component understands immutability, reactive parameters, and when wire adapters will or will not re-evaluate. Use it when the LWC is not updating when data changes—often because the wire adapter isn't re-evaluating or a refresh wasn't triggered.

Before Starting

• Is the component only reading Salesforce data, or does it also perform writes that should happen imperatively?
• Is the best data source a base component, a UI API wire adapter, an Apex wire adapter, or the GraphQL wire adapter?
• What event should actually refresh the data: parameter change, record change notification, or an explicit refresh call?

Core Concepts

Wire Is A Provisioning Model, Not A Lifecycle Hook

Wire adapters provision data when their configuration is complete and when Salesforce determines fresh data should be emitted. The component should not assume wire execution timing matches connectedCallback() or renderedCallback(). The framework owns when data arrives.

Knowing the concrete init sequence is what lets you debug the classic "flash of undefined data" bug. For a Lightning Data Service wire the order is:

1. constructor() runs.
2. LDS provisions an empty placeholder — an object where both data and error are undefined. This happens before your first render, so the wired property is defined-but-empty, not missing.
3. connectedCallback(), render(), and renderedCallback() fire in that order. On this first pass the real data has not arrived yet — data is still undefined.
4. Data becomes available from the adapter asynchronously and is set on the data property (with error remaining undefined).
5. If the template consumes that data, render() and renderedCallback() fire again.

So renderedCallback() legitimately runs at least twice with no user interaction: once against the empty placeholder and once (or more) as real data lands. Guarding the template on data being truthy — or handling undefined in renderedCallback() — is what prevents the empty first pass from rendering as broken UI. The official guidance is blunt: don't depend on receiving data from a wire adapter at any specific point in the component lifecycle.

Wire Emissions Are Multiple, Asynchronous, And Unordered

A wire is a stream, not a single resolved value. An LDS wire can emit data multiple times without the component changing its configuration; LDS controls those emits and they aren't tied to the LWC lifecycle. That is why renderedCallback() can fire repeatedly for reasons the component never initiated — a cache update elsewhere in the app can push a fresh value.

Wire adapter calls are also asynchronous unless the data is already cached, so the order of response and promise resolution is not sequential. Do not write logic that assumes wire A resolves before wire B, or that a wired value is present just because an imperative promise resolved. Each emission is a newer, immutable version of the previous value — treat the property as a read-only stream you react to, never a variable you populate at a known moment.

Reactive Parameters Must Become Real Values

Dynamic wire parameters prefixed with $ only work when the underlying values are defined. If a required reactive parameter is undefined, the wire adapter is not evaluated. This is one of the most common reasons a wire "doesn't fire."

The flip side is that when a reactive parameter's value changes, the wire service provisions new data — which then flows through the second render/renderedCallback() pass described above. A reactive parameter is therefore both a trigger for the first evaluation and a trigger for every subsequent re-provision, so expect the render cycle to run again each time the referenced property updates.

Wired Data Should Be Treated As Immutable Input

The wire service gives the component data to render, not mutable state to edit in place. Clone data before transforming it for UI use. Direct mutation of wired data leads to confusing bugs and stale state assumptions.

Wire And Imperative Calls Solve Different Problems

Use wire for cache-aware reads and declarative reactivity. Use imperative Apex or LDS mutation APIs for creates, updates, deletes, and explicit user-triggered actions. If the component writes data, it also needs a clear refresh strategy for any wired reads that should update afterward.

Common Patterns

UI API Wire For Record Reads

When to use: The component reads record data and should inherit Lightning Data Service caching, sharing, CRUD, and FLS behavior.

How it works: Use adapters such as getRecord or object-info wires with schema imports and reactive record identifiers.

Why not the alternative: Custom Apex for standard record reads adds avoidable maintenance and can bypass built-in data protections.

Imperative Mutation Plus Controlled Refresh

When to use: A user action updates data and the component must then refresh its wired state.

How it works: Perform the write imperatively, then use refreshApex() or the appropriate LDS notification pattern to refresh affected wired reads.

Why not the alternative: Expecting the wire adapter to notice every asynchronous server-side change leads to stale UI.

GraphQL Wire For Multi-Entity Read Models

When to use: The component needs a richer read model than individual UI API wires can express cleanly.

How it works: Use the GraphQL wire adapter, remember that the response exposes errors instead of error, and keep the component read-focused.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Gather context — confirm the org edition, relevant objects, and current configuration state
2. Review official sources — check the references in this skill's well-architected.md before making changes
3. Implement or advise — apply the patterns from Core Concepts and Common Patterns sections above
4. Validate — run the skill's checker script and verify against the Review Checklist below
5. Document — record any deviations from standard patterns and update the template if needed

Review Checklist

• The component uses wire only for read/provisioning use cases.
• Reactive parameters are defined intentionally and not left undefined accidentally.
• Wired results are cloned before UI-specific mutation or sorting.
• Refresh behavior after writes is explicit, not assumed.
• Schema imports are used where referential integrity matters.
• GraphQL wire consumers handle errors rather than assuming error.

Salesforce-Specific Gotchas

1. A wire adapter does not guarantee when data arrives — it can emit multiple times and is not tied to component lifecycle timing.
2. Undefined reactive parameters stop evaluation — many "wire isn't running" bugs are really incomplete configuration.
3. GraphQL wire returns errors, not error — assuming the standard wire error shape causes broken error handling.
4. Async changes outside the adapter do not always auto-refresh — Apex-triggered or Flow-triggered server updates often still need explicit refresh strategy.
5. renderedCallback() runs against undefined data on the first pass — LDS provisions an empty {data: undefined, error: undefined} placeholder before the real value arrives, so the first render happens with no data. Guard the template or the callback instead of assuming data exists by the time the DOM renders.

Output Artifacts

Related Skills

• lwc/lifecycle-hooks — use when render timing or cleanup is the real problem rather than provisioning strategy.
• apex/soql-security — use when the component relies on custom Apex reads that need secure data access review.
• lwc/lwc-offline-and-mobile — use when the wire strategy must also account for mobile or offline behavior.