Recommended way to "listen" another change in a reducer

[mordonez-me]

There are some situations where you need to "know" about something happened and avoid repeating useEffects in multiple components to react, for example a logout. Every time a user logs out from the system you want to reset the state of multiple stores, what would be the recommended way to do it? I have one in mind but I would like to get some opinions and recommendations.

Access the state directly with getState inside the logout (or a global reset function to call all of them, even logout)

//Inside logout call to each state and reset
useSomeState1.getState().reset()
useSomeState2.getState().reset()
useSomeState3.getState().reset()

// Using the recommended way to reset
reset: () => {
set(store.getInitialState())
},

There is a way to reset multiple states in the website but it just consideres all stores in the same place and I don't want to create the Set that stores the references as a global variable because it will feel a bit weird in a feature/domain based structure. Maybe using a wrapper for all stores could be an option, following the same pattern (wrapping store creation into another function)

I found this question #1654 but looks like it is a different perspective, like "extending" based on an action, I want to "react" based on an action, pretty similar but not exactly the same thing.

[poetryofcode]

Your instinct is right, calling getState().reset() directly is the recommended pattern in Zustand for this. It's synchronous, doesn't require hooks, and works from anywhere (including outside React).

Here's how to structure it cleanly in a feature-based architecture:

Option 1: Explicit reset call in the logout action

Keep a reset action on each slice using getInitialState():

const initialState = { user: null, token: null }

export const useAuthStore = create<AuthStore>()((set) => ({
  ...initialState,
  reset: () => set(initialState),
  logout: () => {
    // reset this store
    set(initialState)
    // reset other stores without creating a global registry
    useCartStore.getState().reset()
    usePreferencesStore.getState().reset()
  },
}))

This keeps the reset responsibility in the logout action itself — no global Set, no wrapper needed.

Option 2: A resetAllStores utility (without a global registry)

If you want to decouple stores from each other, export a single resetAllStores function from a stores/index.ts that each feature store registers into:

// stores/reset.ts

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

export const registerReset = (fn: () => void) => resetFns.add(fn)
export const resetAllStores = () => resetFns.forEach((fn) => fn())

// stores/authStore.ts
const initialState = { user: null }
export const useAuthStore = create<AuthStore>()((set) => {
  const store = {
    ...initialState,
    reset: () => set(initialState),
  }
  registerReset(store.reset)
  return store
})

Then on logout:

import { resetAllStores } from './stores/reset'
resetAllStores()

This avoids a truly global variable while keeping each store self-registering at module init time. It fits well into feature-based structures because each store opts in by calling registerReset.

Option 3: subscribe for reactive cross-store coordination

If you need Store B to react to something that happens in Store A (without Store A knowing about Store B), use subscribe:

// In your app's initialization

useAuthStore.subscribe(
  (state) => state.isLoggedIn,
  (isLoggedIn) => {
    if (!isLoggedIn) {
      useCartStore.getState().reset()
      usePreferencesStore.getState().reset()
    }
  },
  { equalityFn: shallow }
)

This keeps stores fully decoupled Store A has no import of Store B and is good for large apps where logout is just one of many state transitions you want to react to.

[poetryofcode]

Happy to clarify or expand on any part of this!