Calling other actions inside an action (handling side-effects)?

[ivancuric]

I've got a data structure which is a directed graph, with nodes and connections.
If I want to delete a node, I also need to delete the associated connections. Same goes for deleting multiple nodes at the same time.

So I've got zustand actions (I guess that's the term for store functions that use set?) for:

deleteConnection(id)
deleteNode(id)
deleteMultipleNodes([id])

etc.

So both deleteNode and deleteMultipleNodes are using deleteConnection, and deleteMultipleNodes is basically using deleteNode in a loop.

How would you handle actions calling other actions in Zustand? Not sure what the correct terminology for this is, but I haven't found any documentation about it.

[dai-shi]

I would leave someone for showing a good pattern, but here's what would work:

const useStore = create((set, get) => ({
  countA: 0,
  countB: 0,
  incA: () => set(prev => ({ countA: prev.countA + 1 })),
  incB: () => set(prev => ({ countB: prev.countB + 1 })),
  incBoth: () => {
    get().incA()
    get().incB()
  },
}))

[danieldaeschle]

I left it empty only for demonstration.
It sets content too. So it wouldn't work.

One thing I would really appreciate are effects like ngrx has it. This would solve the problem.

[sskanishk]

I would leave someone for showing a good pattern, but here's what would work:

const useStore = create((set, get) => ({
  countA: 0,
  countB: 0,
  incA: () => set(prev => ({ countA: prev.countA + 1 })),
  incB: () => set(prev => ({ countB: prev.countB + 1 })),
  incBoth: () => {
    get().incA()
    get().incB()
  },
}))

it giving me ⬇️

Uncaught TypeError: get(...).getMyShiftData is not a function

[dai-shi]

Aren't you calling get during store creation?

[sskanishk]

@dai-shi got fixed, actually my mistake function is inside object. and i'm missing .object_key after get().
thanks.

[zecka]

@danieldaeschle

With combine, you do as follow:

export const useDemoStore = create(
  combine(
    {
      documents: []
    },
    (set, get) => {
      const fetchDocument = async () => {}

      return {
        fetchDocument,
        async loadDocument() {
          await fetchDocument()
        }
      }
    }
  )
)

[ivancuric]

I ended up having the same (or similar?) issue where I get two state updates instead of one and it gets messed up:

{
    streams: [a, b, c],
    activeStreams: [a],
    removeActiveStream: (stream) => {
      set((draft) => {
        draft.activeStreams = draft.activeStreams.filter((x) => x !== stream);
      });
    },

    stopAllStreams: () => {
      set((draft) => {
        draft.streams.forEach((stream) => {
          if (stream.isActive()) {
            stream.stop();
            stream.clearFrameCallbacks();
            draft.removeActiveStream(stream);
          }
        });
      });
    }
}

I was hoping that calling draft.removeActiveStream(stream) from another action would get batched. What happens is that I get two state updates. The first one being activeStreams: [] and the second one reverting back to activeStreams: [a].

I guess this is because the inner set gets executed first, but the draft of the outer set still has a reference to the old unchanged draft which eventually gets returned.

I need to replace draft.removeActiveStream(stream); with a copy of draft.activeStreams = draft.activeStreams.filter((x) => x !== stream); to the stopAllStreams to make it work. Is there some way to make it work without extracting, specifically by waiting for the state to be changed by nested action calls?

I'd like to avoid more bloat by extracting it into something like:

function removeActiveStream(draft: State, stream: Stream) {
  draft.activeStreams = draft.activeStreams.filter((x) => x !== stream);
}
{
    removeActiveStream: (stream) => {
      set((draft) => removeActiveStream(draft, stream));
    },

    stopAllStreams: () => {
      set((draft) => {
        draft.streams.forEach((stream) => {
          if (stream.isActive()) {
            stream.stop();
            stream.clearFrameCallbacks();
            removeActiveStream(draft, stream);
          }
        });
      });
    },
}

[dai-shi]

I guess it's the behavior how immer works, so extrarcting seems a good solution.
(wonder, how valtio works for this use case..)

[ivancuric]

Oh so it's immer that's doing it! Another option I guess would be explicitly using immer in every action instead of composing set with produce at the root.

[amir-gorji]

I tried to clean things up by declaring a value called action at first, then use it like in below example.

const useStore = create((set, get) => {
  const actions = get().actions

  return {
  countA: 0,
  countB: 0,
  actions: {
     incA: () => set(prev => ({ countA: prev.countA + 1 })),
     incB: () => set(prev => ({ countB: prev.countB + 1 })),
        incBoth: () => {
           actions.incA()
           actions.incB()
        },
     }
  }
})

But I got this error: caught TypeError: Cannot read properties of undefined (reading 'actions').
However, I tried const actions = () => get().actions and used actions().incA(), then it worked, but why does this error happen and can it be fixed without making the value actions a function?

[dbritto-dev]

The right way to do it is by callingget() inside of your function not outside because before creating the state the state itself is undefined.

[lveillard]

I think I'm facing the same issue but it only happens when I nest multiple actions using set((status) => ...)

I query a tree structure, and I'm using zustand as a cache. When i'm updating the cache, I need to do some operations. Also this cache can be updated from different sides (for instance the cache of "companies" can get an update when querying directly companies, or when querying "currentEmployee.company"

Imagine something like this

 immer(
    (set, get,) => ({
      ...initValues,
      updateCompanyValues: ({
        companyId,
        fieldId,
        value,
      }: {
        companyId: string;
        fieldId: string;
        value: any;
      }) => {
        set((state) => {
          if(fieldId === 'employees') {
            value.forEach(employee=> get.().updateEmployeeValues({employeeId: employee.id ...}))
          } else {
            setPath(state, 'companies', companyId,.companyId.value, 'values', 'local', unitId, fieldId);
          }
        });
      },
      updateEmployeeValues:  (...) => { set((state=> ... }    

So basically whenever I get employees I update the cache of the employees, and then the cache of the companies I got from those units. And the equivalent when getting companies.

The problem with this it that this generates a nesting of set((state)=>... that results on nothing being changed in the store after the first set. (And no error is thrown)

Not sure how to fix this, so far I'm trying a version where I have only a parent fn with set((state) => and make all the others accept state as a property, but it would be nice to be able to nest those actions and let immer mutate the draft and send everything at the end

[alkkas]

same issue, have u found a way to fix it?

[littlehaker]

Running into the same issue.

The solution is to avoid nesting set((state)=>..., call set when necessary rather than wrap everything inside.

Try this:

 immer(
    (set, get,) => ({
      ...initValues,
      updateCompanyValues: ({
        companyId,
        fieldId,
        value,
      }: {
        companyId: string;
        fieldId: string;
        value: any;
      }) => {
        if(fieldId === 'employees') {
          // unwrap from `set`
          value.forEach(employee=> get.().updateEmployeeValues({employeeId: employee.id ...}))
        } else {
          set((state) => {
            setPath(state, 'companies', companyId,.companyId.value, 'values', 'local', unitId, fieldId);
          });
        }
      },
      updateEmployeeValues:  (...) => { set((state=> ... }    

[tfazekas]

It seems that the discussion didn't provide an explanation about the root cause of the issue, so I investigated a bit more. From what I gathered, the immer Zustand middleware uses immer's produce function.

About nesting immer produces:
https://immerjs.github.io/immer/pitfalls/#always-use-the-result-of-nested-producers

Nesting multiple produce functions can result in incorrect states as the output of the inner produce is not used in the outer produce. As zustand actions return type is void, unfortunately we cannot use the inner action's result in the outer action to set the new state, so nesting actions (or immer produces) is not a way to go.

Nesting can be avoided by @ivancuric's suggestion here:
#307 (comment)

OR if you can, compose the code so that you don't really need to nest actions.