LWC State Managers: Share Reactive State Across Components

State managers are now generally available in Lightning Web Components (LWC)! The Summer ’26 release ships the @lwc/state module, providing developers with a first-class, reactive pattern for organizing and sharing application data across component trees without prop drilling, custom events, or pub/sub workarounds, plus a library of ready-made state managers from the lightning namespace built on the same Lightning Data Service and UI API foundations you already use today.

Defining state in LWC with defineState

A state manager is a dedicated JavaScript module that encapsulates a related set of data (the “state”) and the actions that operate on it. You create one with the defineState function from @lwc/state, passing a setup function. The setup function’s first argument is an object of building blocks: atom, computed, and setAtom. defineState returns a factory; any arguments you pass when you call it flow through to your setup function after that object, so you can parameterize each instance:

• An atom is a reactive “atomic” value, which is essentially a wrapper around a piece of data that LWC can use to make components and other state managers reactive to changes in that data.
• A computed is a lazily-evaluated derivation that recalculates only when its atom dependencies change.
• setAtom is used whenever you need to modify state.

1import { defineState } from '@lwc/state';
2
3export const createCounter = defineState(({ atom, computed, setAtom }, initialCount = 0) => {
4    const count = atom(initialCount);
5    const doubled = computed([count], (countValue) => countValue * 2);
6
7
8    const increment = () => setAtom(count, count.value + 1);
9
10
11    return { count, doubled, increment };
12});

Any component that references count or doubled in a reactive context is automatically re-rendered after increment runs. Computed values recompute lazily and only when their inputs change, and multiple setAtom calls in the same tick are batched into a single notification cycle, so you get reactivity without the re-render churn.

Sharing state across a component tree with fromContext

State managers go beyond a single component. You can create an instance at the top of a component tree and consume it in a descendant component below using fromContext, with no prop drilling, no event handling, and no pub/sub plumbing:

Example code for the top-level component that instantiates the state manager:

1import createShopStateManager from 'x/shopState';
2
3export default class App extends LightningElement {
4    shopState = createShopStateManager();
5}

Example of a descendant component that reads the same instance via LWC context:

1import { LightningElement } from 'lwc';
2import { fromContext } from '@lwc/state';
3import createShopStateManager from 'x/shopState';
4
5export default class Cart extends LightningElement {
6    shopState = fromContext(createShopStateManager);
7
8    get cartTotal() {
9        return `$${this.shopState.value.cartTotal.toFixed(2)}`;
10    }
11}

Built-in state managers for Salesforce data

Salesforce ships a collection of state managers in the lightning namespace that expose Salesforce data and metadata through the Lightning Data Service. Each one presents a uniform shape:

• status (”unconfigured” | ”loading” | ”loaded” | ”error”)
• data
• error
• setter functions for configso using and composing them is straightforward.

Available state managers expose record, objectInfo, layout, and related list data. Because state managers can be nested and wired together with computed, you can build sophisticated, fully reactive data waterfalls, for example: fetch a record to discover its record type, then fetch the matching layout, then fetch the full record using the layout’s fields.

Example of a component that consumes a lightning/stateManagerRecord:

1import { LightningElement, api } from 'lwc';
2import { getFieldValue } from 'lightning/uiRecordApi';
3import createRecordStateManager from 'lightning/stateManagerRecord';
4import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';
5import ACCOUNT_INDUSTRY_FIELD from '@salesforce/schema/Account.Industry';
6
7export default class AccountCard extends LightningElement {
8    _recordId;
9
10    // The built-in state manager instance. Config takes the schema field refs;
11    // recordId is supplied later via the @api setter.
12    state = createRecordStateManager({
13        fields: [ACCOUNT_NAME_FIELD, ACCOUNT_INDUSTRY_FIELD]
14    });
15
16    @api
17    set recordId(id) {
18        this._recordId = id;
19        // Updaters live on the frozen outer shape, so go through .value.
20        this.state.value.setRecordId(id);
21    }
22    get recordId() {
23        return this._recordId;
24    }
25
26    get displayLabel() {
27        const { status, data } = this.state.value;
28        if (status !== 'loaded') return 'Loading…';
29        const name = getFieldValue(data, ACCOUNT_NAME_FIELD) ?? 'Unknown';
30        const industry = getFieldValue(data, ACCOUNT_INDUSTRY_FIELD) ?? '';
31        return industry ? `${name} — ${industry}` : name;
32    }
33}

See state managers in action

State managers bring a modern, reactive data-flow pattern to LWC that scales from a single component to a full application. Because state managers are plain JavaScript modules with no DOM dependency, you can unit-test them with Jest without mounting a component. You can reuse the same state module across multiple component trees. And because consumers read values from the state manager’s public shape rather than reaching into its internals, you can refactor how state is stored without updating every consumer. Additionally, with the built-in UI API state managers, you get that same shape for Salesforce data out of the box. Note: state managers are available in Lightning Experience, but not yet supported in Experience Cloud.

To help you get started, we’ve published two complete examples in the forcedotcom/state-management GitHub repository:

• simple-store: A standalone shopping-cart application (demoed at TDX in March 2026) that shows how multiple components can read and mutate the same state manager entirely through context, with no properties or events. You can run it live on StackBlitz.
• platform-state-managers: A Salesforce DX project that builds a layout-driven record detail panel using the record and layout state managers. The source is heavily commented, and is the best place to learn the basics.

More resources

Ready to start managing your state? Here are additional resources you need to dive in:

• Developer Documentation: Manage State Across LWC Components
• GitHub repository (forcedotcom/state-management): Find the platform-state-managers and simple-store examples.
• Live playground (Simple Store on StackBlitz): Explore a full state-manager app in your browser.

About the Authors

Mike Burr is a Principal Member of Technical Staff at Salesforce from the Lightning Data Service team. When he’s not building client data libraries, he’s busy tweaking his home automation and listening to audiobooks.

Ben Sklar is a Director of Product Management at Salesforce responsible for UI API, GraphQL API, Lightning Data Service, and AI Developer Kit. Ben is a major fan of GraphQL, but when not using GraphQL, you can find him playing ultimate frisbee or skiing during the winter. Follow him on LinkedIn.