Scoped state in a singleton world

The original store setup

Consumers imported the module-level singleton directly. A search bar, for example, subscribed during its component lifecycle and dispatched query updates to that store:

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

With multiple pages mounted, every import still resolved to the same store instance. A dispatch from one tab notified subscribers on all other tabs.

Creating one store per page solved ownership. The remaining problem was discovery: each consumer needed to find the store for the page it belonged to.

Scoping the store to a page

React’s context API already solves this kind of problem, so I used it as a model. A Context provider owns a value for a subtree, and useContext resolves the closest provider above. One provider per tab would give each page its own store.

LWC doesn’t offer an equivalent context API for components, so I couldn’t turn to the framework for the answer. Prop-drilling was also a non-starter because it tightly couples discovery to a specific parent chain.

I adapted React’s context pattern for store propagation. The implementation has two parts:

• StoreProvider takes the role of React’s Context provider. It owns one page’s store and makes it available to its descendants.
• getStore takes the role of useContext. It lets child components resolve the nearest provider’s store in their tree.

Each search page mounts a StoreProvider at its root:

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

Consumers replace the singleton import with a getStore(this) call. The subscription and dispatch logic stays the same:

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

Two tabs now mount two providers, which create two stores. A dispatch from one tab only reaches subscribers connected to that store. The reducers, actions, selectors, and components stay shared.

Finding the nearest provider

When a consumer calls getStore(this), the utility dispatches a StoreRequestEvent from that consumer’s instance. The event is configured to bubble up through shadow DOM boundaries and carries a callback for a provider to call with its store.

Because event dispatch is synchronous, the callback passes the store back before getStore continues. The utility returns that store to the consumer; if no provider is found, it throws an error instead.

1type StoreCallback = (store: Store<State>) => void;2 3class StoreRequestEvent extends CustomEvent<{ callback: StoreCallback }> {4  static readonly NAME = 'storerequest';5 6  constructor(callback: StoreCallback) {7    super(StoreRequestEvent.NAME, {8      detail: { callback },9      bubbles: true,10      composed: true11    });12  }13}14 15function getStore(element: Element): Store<State> {16  let resolved: Store<State> | undefined;17 18  element.dispatchEvent(19    new StoreRequestEvent((store) => {20      resolved = store;21    })22  );23 24  if (!resolved) {25    throw new Error('No StoreProvider found above this component.');26  }27 28  return resolved;29}

On the other side, StoreProvider listens for the event, stops propagation so an outer provider cannot also respond, and invokes the callback with its store:

1import { LightningElement } from 'lwc';2import { StoreRequestEvent } from 'results/state';3 4class StoreProvider extends LightningElement {5  private store = createStore(reducer);6  private storeRequestHandler = this.handleStoreRequest.bind(this);7 8  connectedCallback() {9    this.addEventListener(10      StoreRequestEvent.NAME,11      this.storeRequestHandler12    );13  }14 15  disconnectedCallback() {16    this.removeEventListener(17      StoreRequestEvent.NAME,18      this.storeRequestHandler19    );20  }21 22  private handleStoreRequest(event: StoreRequestEvent) {23    event.stopPropagation();24    event.detail.callback(this.store);25  }26}

The StoreRequestEvent is the internal protocol between getStore and StoreProvider. State consumers only depend on getStore; the event and provider stay behind that API. This keeps store discovery centralized and decoupled from a consumer’s exact parent chain.

What came next

This architecture was transitional, but it directly unblocked a major product milestone: multi-tab search. Each tab could keep its own state without rewriting the existing Redux layer.

The cost was in the consumer setup. Components still had to look up the store, subscribe, and unsubscribe by hand. Store discovery also depended on a custom event-and-callback convention rather than an LWC primitive.

The provider model gave me a useful starting point for the next iteration of this work. LWC doesn’t natively support context sharing between components, but its wire service can propagate context into wire adapters, which are conceptually similar to React hooks.

That insight became the basis for declarative state access, where I revisited store discovery and the manual subscription work left in each consumer.