Joint State Pattern (JSP)

[designervoid]

Joint State Pattern (JSP) – A Pattern to Reduce Boilerplate

I want to standardise the approach to state management across frameworks and libraries, writing in a similar style with core conditions (see next 4 conditions in the end of the article).

This article discusses this pattern.

In the case of VanJS, you can use van.state.

In Raw, you can use raw.signal.

In React it's a little bit complicated.

You should use some state and some hook useState (/TanStack/store/blob/main/packages/react-store/src/index.ts).

Joint State Pattern (JSP) cover TanStack Store, which helps reduce boilerplate (see example with theme).

Also it can be scaled to nanostores, for instance.

TanStack Store is based on React’s useSyncExternalStore — a hook introduced to simplify and improve the management of external data stores.

Before TanStack Store was something like MobX:
Example on GitHub

While JSP can be implemented with MobX, I am personally not focusing on that approach.

However, there are edge cases to consider, such as working with private fields or nested arrays/objects.

So, Core Conditions for Joint State Pattern (JSP):

1. Reduce Boilerplate in Store Creation
   Minimize the amount of repetitive setup code required to define stores. This makes it easier to manage shared state without the overhead of redundant code.
   • Store Structure
   When creating stores, keep them consistent with a clear, standard structure. Specifically:
   • Start by initializing the store, and end by exporting the hook.
   This ensures that each store is straightforward to use and import across the app.
   • Define state, getters, actions, and exports.
   These elements should be clearly outlined within each store, providing an organized and predictable setup for accessing and updating shared state.
2. Enable Native Shared State Across Components
   Shared state should be accessible directly between components, without additional setup. In React, this means simply importing useStore to access the shared state — no need to wrap components in an observe function or similar constructs. This setup makes the state more easily available and reduces dependencies on extra state management wrappers.
3. Easy-to-read/write pattern based on point 1 (an example can be seen in /registry/patterns-react/src/stores/theme/index.ts).
4. You should be able to read and write state anywhere you want (currently, outside components, this is possible with getters. A getter is something like () => state.prop, which returns the latest state, although it is not yet memoized).

[designervoid]

More:

Implementation of Joint State in VanJS

[designervoid]

Very simple joint state in react using @tanstack/store & @tanstack/react-store:

import { useStore } from '@tanstack/react-store';
import { Store } from '@tanstack/store';

interface IEntitiesStore {
  // properties here
  entity0: string;
}

// state
const state = {
  entities: new Store<IEntitiesStore>({
    entity0: '',
  }),
};

// getters
export const getters = {
  getLastEntities: () => {
    return state.entities.state;
  },
};

// actions
const actions = {
  updateEntities: (payload: Partial<IEntitiesStore>) => {
    state.entities.setState((prev) => ({
      ...prev,
      ...payload,
    }));
  },
};

// hook
type UseEntitiesStore = [
  { entities: IEntitiesStore },
  {
    getters: typeof getters;
  },
  {
    actions: typeof actions;
  },
];

export const useFiltersStore = (): UseEntitiesStore => [
  {
    entities: useStore(state.entities, (state) => state),
  },
  {
    getters,
  },
  {
    actions,
  },
];

[designervoid]

⚠️ Joint states are more expensive than local states (e.g., useState in React).

They are a convenient way to share global state between components but should be used wisely in large components to avoid unnecessary complexity.

In small components, there's no significant difference between using joint state or local state.