Finding a workaround to common properties shared between slices.

[KamaniBhavin]

I have two distinct slices, each with identical property names. This naming convention enhances code readability. However, upon creating a store, they merge into a unified global object, potentially overwriting properties from different slices. Is there a workaround for this issue? While I recognize it may not be directly related to Zustand, any assistance in addressing this matter would be greatly appreciated.

export interface A {
 initialize: () => void;
}

export const a: StateCreator<A, [["zustand/immer", never]]> = (set) => ({
  initialize: () => {
    // something specific to slice A
  },
});

export interface B {
  initialize: () => void;
}

export const b: StateCreator<B, [["zustand/immer", never]]> = (set) => ({
  initialize: () => {
    // something specific to slice B
  }
});

const store = create()(
  immer((...args) => ({ //<-------- we overwrite the initialise in A with B here.
    ...a(...args),
    ...b(...args),
    })
  ));

But having a property with the same name in both slices will cause a conflict.
I would like to avoid this and have a way to define the slices in a way that they don't conflict with each other.
Is there a way to achieve this?

[dbritto-dev]

@KamaniBhavin you could try with zustand-lens

[Sebastian-Nielsen]

@dbritto-dev as a maintainer, would it be possible to have zustand automatically do all this namespacing here behind the scenes whenever you create a slice?

This namespacing issue seems like something zustand should be able to handle does it not?

[dbritto-dev]

@KamaniBhavin the issue you are facing is not related to zustand and should be handled by the user

[dbritto-dev]

@KamaniBhavin for instance on redux you have reducers but if for some reason you use the same name on a different reducer one would overwrite the other one

[dbritto-dev]

@Sebastian-Nielsen would be better to spend some time trying zustand-lens

[Sebastian-Nielsen]

@KamaniBhavin The immer solution is good but not great because of the need to repeatedly reference myNamespace, which reduces readability. I am curious, how do you write your actions (setter functions)? Are you repeatedly referencing the namespace in question like this:

export const myNamespace: StateCreator<A, [["zustand/immer", never]]> = (set) => ({
  myNamespace: {
         setSomething: (b: boolean) => set(state => ({ myNamespace: {...state.myNamespace, something: b} })),
    },
  }
});

or

export const myNamespace: StateCreator<A, [["zustand/immer", never]]> = (set) => ({
  myNamespace: {
         setSomething: (b: boolean) => set(state => { 
             state.myNamespace.something = b;
         }),
    },
  }
});

[dai-shi]

This namespacing issue seems like something zustand should be able to handle does it not?

The short answer is no.

I wouldn't try to convince anyone, but here's some notes for anyone interested.

• Zustand philosophy is "unpoinionated"
• Namespacing is an important feature, but I decided it's out of the scope of Zustand core (this repo).
  • Quite a few use cases can be done without namespacing.
  • Namespacing requirements vary from person to person.
  • It feels like there are some API options.
• We currently have zustand-lens and zustand-slices. They shouldn't cover all use cases. There should be more libraries.
• Docs should clarify about this.

[Sebastian-Nielsen]

At the very least consider warning people in the docs and also maybe suggest what to do to avoid the risk:

When following the recommended "one store, multiple slices" pattern, you are constantly suceptible to the risk of introducing a bug if you ever happen to accidentally use the same attribute-name in two different slices at once. Unless you fix the namespacing issue yourself by ... (and then some suggestions maybe)

[dai-shi]

TBH, I’ve never liked the current slice pattern. I warned about name collisions and didn’t personally recommend the pattern. But the community liked it (even with name collisions), so we added it to the docs.

Now, my dislike of the current slice pattern has driven me to create zustand-slices. And @dbritto-dev is working on new docs, so you are right on time.

[dbritto-dev]

@Sebastian-Nielsen suggestions are welcome -> https://gist.github.com/dbritto-dev/7fc6abc8afb33e5f98df35e6e0aa7657