March 2026

Declarative primitives for global state access

In earlier work on scoped stores, I gave each agentic search page instance its own Redux store and built a utility for components to resolve the right store for their tree.

After that lookup, every component still had to work against the low-level store API directly: subscribe to listen for changes, getState to read, dispatch to write, and remember to unsubscribe by hand.

The same lifecycle wiring kept getting copied into new components until it showed up across more than twenty of them. Looking at a component didn’t make its state dependencies obvious. They were scattered across lifecycle code and subscription callbacks.

At its core, this problem is the cost of LWC lacking a higher-level API for Redux. React already solves that with React Redux hooks, so I set out to bring the same API to LWC in an idiomatic way. The result was a small abstraction layer modeled on those hooks: a component declares what state it needs, and the framework handles the subscription work.

Doing it by hand

Here’s an example of how components looked before. Consider a simple search bar that reads the query from the store and writes updates back:

TypeScript</>

1import { LightningElement } from 'lwc';2import { getStore, queryChanged } from 'results/state';3 4class SearchBar extends LightningElement {5  private store: Store<State>;6  private query: string;7  private unsubscribe: () => void;8 9  connectedCallback() {10    this.store = getStore(this);11    this.unsubscribe = this.store.subscribe(() => {12      const { query } = this.store.getState();13      this.query = query;14    });15  }16 17  disconnectedCallback() {18    this.unsubscribe();19  }20 21  updateQuery(event: Event) {22    this.store.dispatch(queryChanged(event.target.value));23  }24}

Even in a component this small, a few issues show up:

Reading one value costs three fields. The value itself, a store reference, and an unsubscribe handle all end up on the class.
A manual store lookup is required. That means calling getStore, a utility from earlier work on scoped stores, to resolve the right store instance.
One callback holds everything. subscribe fires on every dispatch, no matter what changed. Assignments and side effects need manual comparisons. Each new value joins the same callback until it becomes a wall of if checks.
Unsubscribe is easy to miss. Forget the unsubscribe() call and the subscription leaks.

Borrowing from React Redux

React Redux solves this problem with three hooks: useSelector, useDispatch, and useStore. Together, they give components a declarative way to work with the store while abstracting away the manual subscription and cleanup.

LWC doesn’t support those hooks, but its wire service allows us to achieve a similar effect. An LWC component uses the @wire decorator to bind a property or function to a wire adapter, which is just a reusable data provider. That binding stays up to date as new data arrives.

The key realization here was that React Redux hooks and wire adapters solve the same problem in different shapes. A hook keeps a value in sync inside a function body; an adapter keeps a class member in sync from the outside.

Adapters can also receive context from a provider higher in the DOM, so the store can come from a parent instead of a lookup in every consumer.

With that, I modeled each React Redux hook as a wire adapter:

Hook	Wire Adapter	What it provides

useSelector	StoreValue	A single value from the store. Updates when the selected value changes.

useDispatch	StoreDispatch	A dispatch function already bound to the right store instance.

useStore	StoreReference	The store itself, for the cases that don’t fit a selector.

Reading a value

StoreValue takes a selector function and returns the selected value from the store. It handles the subscription, cleanup, and value diffing behind the scenes.

TypeScript</>

1@wire(StoreValue, { selector: (state) => state.query })2query: string;

The property only updates when the selected value changes. A strict equality check is used by default, but a custom comparison function can be specified if needed.

TypeScript</>

1@wire(StoreValue, {2  selector: (state) => state.query,3  equalityFn: (a, b) => a.toLowerCase() === b.toLowerCase()4})5query: string;

The adapter can also be wired to a method, which is useful for running side effects when the selected value changes.

TypeScript</>

1@wire(StoreValue, { selector: (state) => state.query })2onQueryChange(query: string) {3  this.runSearch(query);4}

Dispatching an action

StoreDispatch gives the component a dispatch function already bound to the right store instance, so there’s no need to look up the store manually:

TypeScript</>

1@wire(StoreDispatch)2dispatch: (action: unknown) => void;3 4updateQuery(event: Event) {5  this.dispatch(queryChanged(event.target.value));6}

The escape hatch

Not every case needs a reactive selector. Sometimes a component needs to read several values at once, or manage its own subscription for something more complicated.

Enriching a log payload is a good example. The component needs a few pieces of state at the moment it logs, not a live binding for each one.

StoreReference provides the store instance directly, so the low-level getState and subscribe APIs are still available for that kind of work:

TypeScript</>

1@wire(StoreReference)2store: Store<State>;3 4logSearchPerformed(event: CustomEvent<{ query: string }>) {5  const { query } = event.detail;6  const { viewMode, currentPage } = this.store.getState();7 8  const context = {9    viewMode,10    currentPage,11    timestamp: Date.now()12  };13 14  this.logger.log({ ...context, query });15}

That freedom has a cost. A component that leans on it excessively can end up back in the lifecycle pitfalls this work was meant to remove. I kept it as a deliberate escape hatch, not as the default path.

The same shape as React

Compare SearchBar before and after. With StoreValue and StoreDispatch, the refactored version declares the value it reads and the action it dispatches up front. The lifecycle code from before is gone.

TypeScript

1import { LightningElement, wire } from 'lwc';2import { StoreValue, StoreDispatch, queryChanged } from 'results/state';3 4class SearchBar extends LightningElement {5  @wire(StoreValue, { selector: (state) => state.query })6  private query: string;7 8  @wire(StoreDispatch)9  private dispatch: (action: unknown) => void;10 11  updateQuery(event: Event) {12    this.dispatch(queryChanged(event.target.value));13  }14}

Here’s the same component in React. A selector pulls one value out of the store, and dispatch sends actions back in.

TypeScript (TSX)</>

1import { useSelector, useDispatch } from 'react-redux';2import { queryChanged } from 'results/state';3 4function SearchBar() {5  const query = useSelector((state) => state.query);6  const dispatch = useDispatch();7 8  return (9    <input10      value={query}11      onChange={(event) => dispatch(queryChanged(event.target.value))}12    />13  );14}

The LWC version is supposed to resemble the React one and feel familiar beside it. That was by design.

Under the hood

None of that lifecycle work went away. It moved into two places: the adapter a component wires to, and the provider that hands out the store.

The adapter

At a technical level, a wire adapter is any class that implements the WireAdapter interface. That’s the whole contract, and it’s only three methods, which map closely to the lifecycle methods a component already has:

connect: invoked when the consumer connects to the DOM
disconnect: invoked when the consumer disconnects
update: invoked with the config from the @wire decorator and the context from a provider

To push data into a component, an adapter invokes a dataCallback with the value to provision. This callback is provided by the wire service when the adapter is instantiated.

TypeScript

1type Selector = (state: State) => unknown;2type EqualityFn = (a: unknown, b: unknown) => boolean;3 4interface StoreValueConfig { 5  selector: Selector;6  equalityFn?: EqualityFn;7}8 9interface StoreContext {10  store: Store<State>;11}12 13const defaultEqualityFn: EqualityFn = (a, b) => a === b;14 15class StoreValue implements WireAdapter {16  private store: Store<State>;17  private selector: Selector;18  private isEqual = defaultEqualityFn;19  private value?: unknown;20  private unsubscribe?: () => void;21 22  constructor(private dataCallback: (value: unknown) => void) {}23 24  connect() {25    this.subscribe();26  }27 28  disconnect() {29    this.unsubscribe?.();30  }31 32  update(config: StoreValueConfig, context: StoreContext) {33    this.selector = config.selector;34    this.isEqual = config.equalityFn ?? defaultEqualityFn;35    this.store = context.store;36    this.subscribe();37  }38 39  private subscribe() {40    this.unsubscribe?.();41    this.provide();42    this.unsubscribe = this.store.subscribe(() => this.provide());43  }44 45  private provide() {46    const next = this.selector(this.store.getState());47 48    if (this.isEqual(this.value, next)) return;49 50    this.value = next;51    this.dataCallback(next);52  }53}

The subscription logic that used to live in a component’s lifecycle callbacks has a natural home in connect and disconnect. The wire service handles context propagation, so the adapter can reach the store without looking it up.

From there, each adapter pushes its result back through dataCallback: a selected value, a bound dispatch function, or the store itself.

The provider

In earlier work on scoped stores, I built a StoreProvider that creates a store for each search page and makes it available to components in its subtree. For this work, I repurposed that same provider as the context source for the new adapters.

LWC exposes a lesser-known API for this: createContextProvider. It takes an adapter and returns a contextualizer: a function that a component calls to register itself as the source of context for that adapter.

Each adapter needs its own contextualizer, so StoreProvider loops over all three and provides its store to each of them:

TypeScript</>

1import { LightningElement, createContextProvider } from 'lwc';2import { StoreValue, StoreDispatch, StoreReference } from 'results/state';3 4const contextualizers = [StoreValue, StoreDispatch, StoreReference].map(5  createContextProvider6);7 8class StoreProvider extends LightningElement {9  private store = createStore(reducer);10 11  connectedCallback() {12    for (const contextualize of contextualizers) {13      contextualize(this, {14        consumerConnectedCallback: (consumer) =>15          consumer.provide({ store: this.store })16      });17    }18  }19}

The adapters declare what a component needs, StoreProvider owns the store, and createContextProvider threads that store into the adapters at runtime. No prop drilling, and no manual store lookup in each consumer.

HTML</>

1<template>2  <store-provider>3    <search-bar></search-bar>4  </store-provider>5</template>

Tradeoffs

None of this is part of LWC or Redux. There’s no upstream maintainer to fix bugs and ship new features for free. It’s a custom layer my team owns, so we’re responsible for its upkeep.

The other cost is StoreReference. A selector isn’t always the right tool, so the escape hatch has to exist. Used carefully, it stays rare. If components use it as the default, they end up back in the lifecycle pitfalls this work was meant to remove.

In practice, those costs have been manageable. Components no longer subscribe and unsubscribe by hand. They don’t hold monolithic subscribe callbacks or look up the store themselves. State dependencies show up on the class declaration instead of lifecycle code.

That logic now sits in three wire adapters. We can reuse them across components and test each one in isolation. The adapters themselves are just idiomatic LWC primitives applied to Redux.