I think we need the dependencies array back... about zustand HOT 8 CLOSED

Indeed, this has to work.

@JeremyRH It stores the selector as a ref and runs it each render pass over the store-state. Since the function is exchanged, shouldn't it be able to take the updated scope?

from zustand.

Playing around some more, the store is never updated since nothing in it changes, so it doesn't fire subscribers. setId(id => id + 1) just returns arg0, but doesn't call set. Hence the selector is called only once, initially. Isn't this expected, though?

from zustand.

On second thought, you're right, when the selector changes it can yield another result, so it should definitively be possible to run a diff even though the store hasn't been changed.

from zustand.

Exactly. We should either add back dependencies or be more restrictive how the selecting can happen. Because if I can write code like this to select state I’m expecting it to work.

from zustand.

Like this maybe? https://codesandbox.io/s/o7nky5wwj5

This would also work if you remove the [id], in that case it would call the selector on every render, more or less like redux works. If you supply the selector, it runs only on memoize changes. I haven't tested if this causes extra render calls now.

from zustand.

Yeah, you bring up extra renders... I worry that the component will render, triggering the React.useEffect(() => void ping(), deps) which in turn will trigger another render.

from zustand.

I think this seems like a pretty good solution, barring it doesn't cause a bunch of extra renders...

from zustand.

I think we can solve this issue without adding the dependencies back. We can run the selector on every call to useStore and return that slice instead of returning the state from React's useState. I'm not sure if this will cause unwanted side effects though. I'll test this out today.

from zustand.