Best practices on the updater functions

[ivsantos]

Hi, I am currently implementing a single Zustand store with some properties and a single updater function, something like a 'dispatcher' that updates whatever field you want:

interface StoreState {
	fieldA: string | null
	fieldB: string | null
	update: (newState: Partial<StoreState>) => void
}

export const useStore = create<StoreState>((set) => ({
	fieldA: '',
	fieldB: '',
	update: (newState) => set(newState),
}))

And then, when I need to update a field or more, I call it like this:

update({ fieldA: 'something' })
or
update({ fieldA: 'whatever', fieldB: 'another' })

This seems to not cause any major problems or re-renders, except for one thing: you could potentially call the 'update' function with another value for the same 'update' function. However, I see it as a developer responsibility and not likely to happen.

I know that Zustand describes the use of 'actions', each one of them 'linked' to its primitive value, but...
Is something wrong with my solution? The only goal I have is to try to simplify the code by using a single update function.

Thank you so much in advance.

[dbritto-dev]

@ivsantos nothing wrong but in that case I'd use useStore.setState(...) function instead

[ivsantos]

Thank you for your reply!
I'll look at useStore.setState(...) then. Can you briefly explain why that is preferred rather than having an updater function inside the store?

[dbritto-dev]

@ivsantos they're pretty the same and you are not supporting updater functions only plain objects but .setState(...) does that so you don't need to replicate it

[ivsantos]

Thanks @dbritto-dev! I will use the .setState(...) utility then.
Instead of using it at the module level, I added a utility near the store like this:

export const useUpdateStore = () => ({
  update: (state: Partial<StoreState>) =>
    useStore.setState(state, undefined, Object.keys(state).join('/')),
})

The only purpose of adding Object.keys(state).join('/') is to see in the devtools what is currently being updated, but maybe, even though devtools are only enabled on local development it may slow down update transactions, am I right?

[dbritto-dev-seatpick]

Thanks @dbritto-dev! I will use the .setState(...) utility then.

Instead of using it at the module level, I added a utility near the store like this:

export const useUpdateStore = () => ({

  update: (state: Partial<StoreState>) =>

    useStore.setState(state, undefined, Object.keys(state).join('/')),

})

The only purpose of adding Object.keys(state).join('/') is to see in the devtools what is currently being updated, but maybe, even though devtools are only enabled on local development it may slow down update transactions, am I right?

This should be named updateStore without use due to is not a custom hook you.

If you want to add something for devtools and remove devtools on prod I'd use process.env.NODE_ENV = 'development' or import.meta.env.DEV so will be removed with dead code elimination