Resetting Zustand stores

[biggyspender]

In the documentation, we are given the following code for resetting stores:

import { create as _create } from 'zustand'
import type { StateCreator } from 'zustand'

const storeResetFns = new Set<() => void>()

const resetAllStores = () => {
  storeResetFns.forEach((resetFn) => {
    resetFn()
  })
}

export const create = (<T extends unknown>() => {
  return (stateCreator: StateCreator<T>) => {
    const store = _create(stateCreator)
    const initialState = store.getState()
    storeResetFns.add(() => {
      store.setState(initialState, true)
    })
    return store
  }
}) as typeof _create

A similar technique is recommended when writing tests involving zustand.

However, if the stateCreator has side-effects (or does any kind of initialization beyond simply returning the initial store state), these side-effects are not re-run.

Perhaps a better way to do this reset might be: rather than storing an initial state to recall on reset, to re-run the state creator instead?

export const create = (<T extends unknown>() => {
  return (stateCreator: StateCreator<T>) => {
    const store = _create(stateCreator)
    storeResetFns.add(() => {
      store.setState(stateCreator(store.setState, store.getState, store), true);
    });
    return store
  }
}) as typeof _create

Is this sensible?

[dbritto-dev]

@biggyspender did you tried with getInitialState() instead of getState()?

[biggyspender]

@dbritto-dev Your comment highlights the discrepancy in the docs between the technique used here (getState) and here (getInitialState) that I had not previously noticed.

However, neither of these approaches will rerun any initialization/side-effects that happen in the stateCreator.

I guess part of my question here is: is it actually sensible to do anything other than setting up a store's initial state in the stateCreator? Say we want to run some kind of initialization... think of, perhaps, an authStore where we want to immediately establish the user's auth status via some kind of async code.

Where does that kind of code go, and how do we ensure that it re-runs if the store is reset?

[dbritto-dev]

@biggyspender do you have an example? I don't see why initialization should be an issue here, about side effects I wouldn't recommend do that in stateCreators

[dbritto-dev]

so something like this:

store = createStore(() => {
  // don't add side effect to your store here
  return { ... }
})

should be like this

store = createStore(() => {
  return { ... }
})

// add side effects to your store here

[dbritto-dev]

btw, some parts of the docs still outdated I added new docs for apis in general (apis, hooks, and middlewares)

[biggyspender]

Fair enough. I was self-aware enough to realise that there might be a smell to running initialization/side-effects as part of the store setup.

This line of questioning really arose from my attempts to test stores and the somewhat contrived mocks of zustand that are required to do this.

I think I'll probably opt for placing the stores in a context provider instead of module singletons and side-step the whole reset issue this way instead.

[dbritto-dev]

@biggyspender cool, ping me if you have any question