How to initialise global state by React props?

[binarykitchen]

Asking for a solution, how to implement this best in Zustand.

In short, I'm building a new component library (not an app!) with a root component called Recorder. I would like to initialise a global state with options given as react props to the root component in Zustand:

export interface VideomailRecorderProps {
  options?: JSONObject
}

const VideomailRecorder = (props: VideomailRecorderProps) => {
  const { options } = props;

  // Here, how can I initialise a global Zustand state (store) with those default options?

  return <h1>Hello</h1>;
};

I'm not sure. I believe mutating state during render is a bad idea. Suggestions welcome.

[dai-shi]

Zustand store is the "external" state from the React perspective. To synchronize with external state, one canonical solution is to use useEffect.

[binarykitchen]

So, this solution is tricky.

Yeah, tricky and I'd rather avoid the hydrate fn.

Didn't you use Context / Provider when you used Redux?

No, none.

How do you pass preloadedState with Redux from React props?

Using the React class method. In the constructor, you'll get the props and can define the initial global state when calling configureStore with the preloadedState.

You also can predefine state with ClojureScript for React using re-frame:
https://github.com/day8/re-frame

(defn ^:export init []
  (re-frame/dispatch-sync [:initialise-db]) ; Dispatch sync to set up before rendering
  ;; ... then mount your React app ...
)

Source: https://github.com/day8/re-frame/blob/master/docs/Loading-Initial-Data.md#cheating---synchronous-dispatch

Lastly, remember, it's a time machine. With a global state, you can go back or forward. So it should also be possible to define the initial state at "birth" based on "genes".

[dai-shi]

I only know the Redux usage with Provider with React.
For Zustand, this is the recommended pattern: https://github.com/pmndrs/zustand/blob/8815101b6d0ae2fae602913fef84e5ddbe0412fb/docs/guides/initialize-state-with-props.md

it's a time machine.

I don't know what will be an equivalent. Hope someone has ideas.

[binarykitchen]

I believe, a context goes against the idea of a single source of truth. No pun intended, this is also a React problem.
Too many overlapping context worsen it. There are plenty of discussions about that.

For Zustand, this is the recommended pattern: 8815101/docs/guides/initialize-state-with-props.md

Ok, let's review that:

function App() {
  const [store] = useState(() => createBearStore()) // <--- on first App render, store is undefined
  return (
    <BearContext.Provider value={store}> // <-- on first render, this context still comes with an undefined value/store
      <BasicConsumer />
    </BearContext.Provider>
  )
}

Ah, yes, on first render, the store is undefined because useState only affects the next event loop, not the current one. Therefore, the BearContext still comes with an undefined store. This can cause race conditions, flickers, etc

I understand, it's only milliseconds, based on the browser's requestAnimationFrame setting. Still, this goes against the concept of the single source of truth.

Because I'm working on something where milliseconds matter, this also matters to me. Hence, all those questions.

A solution to set up the global state the synchronous way would be very welcome.

[180107072]

have you tried this?

function App() {
  const ref = useRef(null);
  if (!ref.current) ref.current = createBearStore();

  return (
    <BearContext.Provider value={ref.current}>
      <BasicConsumer />
    </BearContext.Provider>
  );
}

[binarykitchen]

Sorry, I've decided to go back to RTK Toolkit.

[KeepALifeUS]

Solution: Initialize Zustand Store from Props

You're right - mutating state during render is bad. Here are the recommended patterns:

1. Store Factory Pattern (Recommended for Libraries)

import { createStore, useStore } from "zustand";
import { createContext, useContext, useRef } from "react";

// Create store factory
const createRecorderStore = (initialOptions) =>
  createStore((set) => ({
    options: initialOptions,
    setOptions: (opts) => set({ options: opts }),
  }));

// Context for the store instance
const RecorderContext = createContext(null);

// Provider component
export const VideomailRecorder = ({ options, children }) => {
  const storeRef = useRef();
  
  // Create store once with initial props
  if (!storeRef.current) {
    storeRef.current = createRecorderStore(options);
  }

  return (
    <RecorderContext.Provider value={storeRef.current}>
      {children}
    </RecorderContext.Provider>
  );
};

// Hook to use the store
export const useRecorderStore = (selector) => {
  const store = useContext(RecorderContext);
  return useStore(store, selector);
};

2. Usage in Child Components

function RecordButton() {
  const options = useRecorderStore((s) => s.options);
  return <button>{options.buttonText}</button>;
}

// In your app
<VideomailRecorder options={{ buttonText: "Record" }}>
  <RecordButton />
</VideomailRecorder>

Why this works:

• Store is created once in useRef (not during render)
• Each <VideomailRecorder> instance gets its own store
• Perfect for component libraries with multiple instances

This is the official recommended pattern from Zustand docs for React context integration.

[binarykitchen]

Ah right, with useRef that works. Good suggestion, thanks.

[dbritto-dev]

https://zustand.docs.pmnd.rs/hooks/use-store#using-scoped-(non-global)-vanilla-store-in-react

[wesleysmyth]

You're right that mutating state during render is a bad idea. For a component library where the root component receives config props, the cleanest Zustand pattern is a store factory with React context.

Recommended: Store factory + context provider

// store.ts
import { createStore } from "zustand";

export interface RecorderState {
  options: JSONObject;
  isRecording: boolean;
  // ... other state
  setOptions: (options: JSONObject) => void;
  startRecording: () => void;
  stopRecording: () => void;
}

export const createRecorderStore = (initialOptions: JSONObject = {}) =>
  createStore<RecorderState>((set) => ({
    options: initialOptions,
    isRecording: false,
    setOptions: (options) => set({ options }),
    startRecording: () => set({ isRecording: true }),
    stopRecording: () => set({ isRecording: false }),
  }));

export type RecorderStore = ReturnType<typeof createRecorderStore>;

// context.tsx
import { createContext, useContext, useRef } from "react";
import { useStore } from "zustand";
import { createRecorderStore, RecorderState, RecorderStore } from "./store";

const RecorderContext = createContext<RecorderStore | null>(null);

export function RecorderProvider({
  options,
  children,
}: {
  options?: JSONObject;
  children: React.ReactNode;
}) {
  const storeRef = useRef<RecorderStore | null>(null);
  if (storeRef.current === null) {
    // Create store once with initial props — not a mutation during render,
    // this is lazy initialization (same pattern as useRef)
    storeRef.current = createRecorderStore(options);
  }
  return (
    <RecorderContext.Provider value={storeRef.current}>
      {children}
    </RecorderContext.Provider>
  );
}

export function useRecorderStore<T>(selector: (state: RecorderState) => T): T {
  const store = useContext(RecorderContext);
  if (!store) {
    throw new Error("useRecorderStore must be used within <RecorderProvider>");
  }
  return useStore(store, selector);
}

// VideomailRecorder.tsx
export interface VideomailRecorderProps {
  options?: JSONObject;
  children?: React.ReactNode;
}

export const VideomailRecorder = ({ options, children }: VideomailRecorderProps) => {
  return (
    <RecorderProvider options={options}>
      <RecorderInner />
      {children}
    </RecorderProvider>
  );
};

function RecorderInner() {
  const isRecording = useRecorderStore((s) => s.isRecording);
  const start = useRecorderStore((s) => s.startRecording);
  return (
    <div>
      <h1>{isRecording ? "Recording..." : "Ready"}</h1>
      <button onClick={start}>Start</button>
    </div>
  );
}

Why this pattern works for component libraries

1. No global singleton — each <VideomailRecorder> instance gets its own store, so multiple instances on the same page don't conflict
2. Props initialize the store once — useRef ensures the store is created only on first render with the given options
3. No state mutation during render — useRef initialization is the React-approved pattern for this (it's how useState lazy initializers work too)
4. Child components access state via hooks — useRecorderStore(selector) gives you fine-grained subscriptions with Zustand's selector pattern

If options can change after mount

If the parent can pass new options that should update the store:

import { useEffect } from "react";

export function RecorderProvider({
  options,
  children,
}: {
  options?: JSONObject;
  children: React.ReactNode;
}) {
  const storeRef = useRef<RecorderStore | null>(null);
  if (storeRef.current === null) {
    storeRef.current = createRecorderStore(options);
  }

  // Sync prop changes to store (outside of render)
  useEffect(() => {
    if (options) {
      storeRef.current?.getState().setOptions(options);
    }
  }, [options]);

  return (
    <RecorderContext.Provider value={storeRef.current}>
      {children}
    </RecorderContext.Provider>
  );
}

This is the pattern Zustand's docs recommend for library authors — see the Extracting the store to a custom hook with vanilla store section.