Please don't remove createContext

[arvinxx]

I notice that https://github.com/pmndrs/zustand/blob/main/docs/previous-versions/zustand-v3-create-context.md says:

Note: This function will likely be deprecated in v4 and removed in v5.

I think this createContext is more usable that react's createContext. Please don't deprecated or remove it in the further version.

Reason why this createContext is more usable

ths most useful situation is refactor a app to a component.

Here's progress:

At first I create a App without context :

// store.ts
import create from "zustand";

export const useStore =  create((set) => ({
    bears: 0,
    increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
    removeAllBears: () => set({ bears: 0 })
  }));

compoents use useStore to consume store

// Component.ts

import {useStore} from './store'

const ButtonChild = () => {
  const state = useStore();
  return (
    <div>
      {state.bears}
      <button
        onClick={() => {
          state.increasePopulation();
        }}
      >
        +
      </button>
    </div>
  );
};
export default ButtonChild

But oneday, I need to convert this app to a component(like react-flow) to reuse in another app.

with zustand createContext, what I need to do is just wrapper the App with a zustand's createContext, and don't need to refactor any code in children components. It become a component, can be used in any other app.

// store.ts
import create from "zustand";

+ const createStore = ()=> create((set) => ({
- export const useStore =  create((set) => ({
    bears: 0,
    increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
    removeAllBears: () => set({ bears: 0 })
  }));

+ const { Provider, useStore } = createContext();

+ export { Provider, useStore ,  createStore }

// Wrapper.tsx

import {Provider,  createStore } from './store'

const  Wrapper =()=>{
  return (
    <Provider createStore={createStore}>
      <ButtonChild />
    </Provider>
  );
}

But what if use it with react's context?

1. change create usage to createStore usage
2. Add wrapper with react context.
3. change all children components usage to new useStore. If I have 20 components, I need to rewrite 20 times.

Compare to zustand 's context usage, It's real bad.

So please keep the zustand's createContext usage in the furture. And it's a more recommended method in my mind.

[dai-shi]

The point is you can create v3 compatible createContext with v4 new APIs.
We want to make the library minimalistic, and thus considering deprecation.

Your feedback is important and I agree that there are some use cases. I wonder if anyone would be interested in creating a 3rd-party package, if it's valuable.

[dai-shi]

Have you seen the migration guide? #1180 (comment)

[divmgl]

Let me take a look and see if that answers both of my questions, thanks for pointing me in the right direction.

[dai-shi]

You can also reach out a third-party library. https://github.com/charkour/zustand-di

[josegoval]

I think in general context usage is extremely useful to create Zustand store instances per component level, and as such, It should be considered a core aspect of Zustand.

In Zustand we should be able to create global stores (the most common usage) and store instances.

Store instances combine really well with react preventing prop drilling and achieving clear organization within project, among other benefit commented by arvinxx.

[dai-shi]

The new docs by @dbritto-dev should address the context usage.

[arvinxx]

I just released a library with v3.5 context : https://github.com/arvinxx/zustand-utils. Maybe I can handle with some migration documents context releated. @dai-shi

[dai-shi]

Good to see you use useStore hook. You may not need useMemo in your useStoreApi.

[arvinxx]

Good to see you use useStore hook. You may not need useMemo in your useStoreApi.

improved

[ollwenjones]

I fail to understand how moving to react context as in the migration guide allows us to have multiple instances of the same store, with some state passed from a parent component, as before, because these examples are creating the store at the module level. If we create a store instance at the module level (singleton) we can't have more than one instance of the same store for different components / component instances.

TypeScript also says createContext requires at least 1 argument, fwiw

[norama]

But in another use case even that fails, there are 2 stores again and the same problem arises.
Maybe the single reliable solution is using global store without context as you have in the intro:
https://docs.pmnd.rs/zustand/getting-started/introduction

[dai-shi]

  const storeRef = useRef(createStore((set) => ...))

is equivalent to

  const initialStore = createStore((set) => ...)
  const storeRef = useRef(initialStore)

there were 2 stored created

Can you create a minimal reproduction with https://codesandbox.io/s/react-new and open a new discussion?

just put the store into React state

That is fine from the library usage perspective.

[norama]

You can ignore this, it was caused by accidental forced remount in our code.
Anyway, I have also learned why

const storeRef = useRef()
  if (!storeRef.current) {
    storeRef.current = createStore((set) => ...)
  }

is better than setting

const storeRef = useRef(createStore((set) => ...))

right away: this latter variant calls createStore((set) => ...) upon each render with no purpose, the new store will not be used.
So it will work but will generate extra stores that are not used.

[xinaesthete]

I have a different issue... I have some code (third party code I'm trying to refactor/adapt) that uses useMyStore.setState() from event listeners etc.

So if I have something like (excuse my condensed example code):

const useMyStore = selector => {
  return useStore(useContext(StoreContext), selector)
}

Then useMyStore.setState is undefined... but if I try

function useMyStore(selector) {
  return useStore(useContext(StoreContext), selector)
}
useMyStore.setState = s => {
  const store = useContext(StoreContext) //uh-oh
  store.setState(s)
}

Then it won't be able to work because of rules of hooks... Perhaps it would be preferable to replace any such instances with more specific store actions - which is doable, but then this refactor will need to have a higher surface area and diverge from the original more than I would ideally prefer.

Excuse me if I missed something.

[dbritto-dev]

@xinaesthete that's expected since the context is undefined until the component is mounted if you want re-use an store outside of react you should use createStore

[xinaesthete]

@xinaesthete that's expected since the context is undefined until the component is mounted if you want re-use an store outside of react you should use createStore

Perhaps I should've kept a bit more code for context - I was using createStore in what I believe to be a similar pattern this documentation which by my reading I thought was the most canonical...

Indeed, now that I review a bit more of the docs, I see https://docs.pmnd.rs/zustand/guides/practice-with-no-store-actions

this pattern doesn't offer any downsides

... but it seems to offer something of a downside when it comes to adapting it to the context API.

I could maybe benefit from re-reading some of this discussion, as well as reviewing the utility libraries mentioned... heading out now, but FWIW here is a code sandbox with a simple store (and lots of boilerplate for types etc).

I keep a Map of stores, and have another hook useStoreGetter that returns a function that when called (later, outside react component render) will retrieve the given store. It's then possible to use setState and getState... it should remove the reference when the provider is unmounted... I don't think there's anything terribly wrong with it, but I'm not sure how much I like it, sure it can be improved. JS version is a bit more brief:

import { createContext, useContext, useEffect, useRef } from "react";
import { createStore } from "zustand";
import { useStoreWithEqualityFn } from "zustand/traditional";

const StoreContext = createContext(null);
const stores = new Map();
export const StoreProvider = ({ children, id }) => {
  const storeRef = useRef();
  if (!storeRef.current) {
    console.log("init store", id);
    storeRef.current = createStore(() => ({
      count: 0,
    }));
  }
  useEffect(() => {
    if (storeRef.current) stores.set(id, storeRef.current);
    return () => {
      stores.delete(id);
    };
  }, [storeRef.current, id]);
  return (
    <StoreKeyContext.Provider value={id}>
      <StoreContext.Provider value={storeRef.current}>
        {children}
      </StoreContext.Provider>
    </StoreKeyContext.Provider>
  );
};

export function useStoreInContext(selector) {
  const store = useContext(StoreContext);
  if (!store) {
    throw new Error("Missing StoreProvider");
  }
  //@deprecated...
  //return useStore(store, selector);
  return useStoreWithEqualityFn(store, selector);
}
/**
 * const storeGetter = useStoreGetter()
 * useEffect(() => {
 *   storeGetter().setState(...)
 * })
 */
export function useStoreGetter() {
  const k = useContext(StoreKeyContext);
  return () => stores.get(k);
}

Any thoughts welcomed (including on the type stuff, which it may be possible to make a bit less involved on the provider side with some thought...)

[xinaesthete]

I just realised I'd mis-pasted the sandbox link above, should have been https://codesandbox.io/p/sandbox/zustand-context-ts-y5cpyh?file=%2Fsrc%2Fzustand.tsx%3A17%2C1 (now edited in the previous comment as well)

[RinNguyens]

I have added Immer middleware insight createStore. It's works. But I don't know, It good for context when call any components.

[xinaesthete]

I have added Immer middleware insight createStore. It's works. But I don't know, It good for context when call any components.

It might be better if you include the code as text rather than an image. I'm not actively using Immer at the moment and don't have any immediate thoughts on whether there are problems with your approach, but may review at some point.