Should initialState be immutable?

[kevinokerlund]

The initialState can be mutated after the store is created, sometimes in subtle ways. Consider the following example:

type Bear = {
	id: number;
	name: string;
};

type BearStore = {
	bears: Bear[];
	changeBearName: (id: number, name: string) => void;
};

export const useBearStore = create<BearStore>((set) => ({
	bears: [
		{ id: 1, name: 'Pooh' },
		{ id: 2, name: 'Yogi' },
	],
	changeBearName: (id, name) =>
		set((state) => {
			const bearIndex = state.bears.findIndex((bear) => bear.id === id);

			if (bearIndex >= 0 && name !== state.bears[bearIndex].name) {
				const bears = [...state.bears];
				bears[bearIndex].name = name; // mutation; I know, I know... bad!
				return { bears };
			}

			return state;
		}),
}));

To demonstrate the mutation we can use the following tests:

Note

I am using the instructions on setting up vitest found here to mock zustand so the store is reset afterEach test.

import { act, renderHook } from '@testing-library/react';
import { useBearStore } from './bear-store';

describe('BearStore', () => {
	// ✅ This test passes
	it('should change a bear name', () => {
		const { result } = renderHook(() => useBearStore());

		act(() => {
			result.current.changeBearName(1, 'Winnie');
		});

		expect(result.current.bears[0].name).toBe('Winnie');
	});

	// ❌ This test fails because of the mutation that occurred in the previous test
	it('should not change a bear name if the passed index does not exist', () => {
		const { result } = renderHook(() => useBearStore());

		act(() => {
			result.current.changeBearName(3, 'Baloo');
		});

		expect(result.current.bears[0].name).toBe('Pooh'); // Fail because name is "Winnie"
		expect(result.current.bears[1].name).toBe('Yogi');
	});
});

The way the zustand.ts mock file handles resetting the store is using the getInitialState api method:

const initialState = store.getInitialState();
storeResetFns.add(() => {
  store.setState(initialState, true);
});

---

I totally get it—I shouldn't mutate the object for a bear. However, many developers might assume that immutability only applies or is necessary at the top level (the array) rather than to the objects inside it. That said, if I call getInitialState, it seems reasonable to expect a deep copy of whatever was originally passed into create, especially in a testing environment.

Does it make sense for getInitialState to return a deep copy in this case, or is there a better way to handle this kind of issue?

[dai-shi]

Should initialState be immutable?

Yes, it should as well as non-initial state. Everything is built on the immutability contract.

However, many developers might assume that immutability only applies or is necessary at the top level (the array) rather than to the objects inside it.

I wasn't aware that many devs assume that. In such a case, one might consider deep freezing the state object during the development.

Does it make sense for getInitialState to return a deep copy in this case, or is there a better way to handle this kind of issue?

No it doesn't. If this is only about testing env, deep freezing might be a good option.

[kevinokerlund]

I wasn't aware that many devs assume that. In such a case, one might consider deep freezing the state object during the development.

That's a good point. Although what I was highlighting more was that because of the new array being returned, that's enough in the case of React (which I didn't clarify I was using, apologies) to trigger the necessary re-renders. I personally have observed that many developers find simply returning the new array as the state sufficient (still not good!), rather than doing that and creating a new object for the particular bear.

No it doesn't. If this is only about testing env, deep freezing might be a good option.

Also true, that would be a good option. Would you suggest modifying the zustand.ts mock file provided in the instructions to deep-freeze? (Ultimately, the answer is to never mutate.) What I was more getting at — and no, this isn't only about testing — is why wouldn't it make sense to return a deep-cloned initialState from getInitialState? Is the answer essentially, "If you mutate it, that's on you. You should know what you're doing in your code?"

[dai-shi]

(still not good!)

True. It breaks in a certain case. What works doesn't mean what is right.

why wouldn't it make sense to return a deep-cloned

In general, it's not only about initialState, but any state.

We have three options:

1. never deep freeze
2. deep freeze only in DEV (incl. testing)
3. always deep freeze

We don't prefer 3 because it may be unnecessary computation.

So, the answer should be an opt-in middleware or something.

If it's only about initialState, I guess it's as simple as this:

const useFooStore = create((set) => deepFeeze({
  ...
}));

[kevinokerlund]

Thanks for the discussion! I'll look at some ways to better handle this, and you've given me some good things to think about.