Middleware priority

[OrRosenblatt]

I would like to better understand the middleware priority and what's the correct order between the middlewares themselves.

1️⃣ devtools priority

The recommendation is to use devtools middleware last:

However, the two examples shared in the same documentation page show devtools wrapping persist middleware:

// 1st example
const useBearStore = create<BearState>()(
  devtools(
    persist(
      ...
  ),
)

// 2nd example
import { create } from 'zustand'
import { devtools, persist } from 'zustand/middleware'

const myMiddlewares = (f) => devtools(persist(f, { name: 'bearStore' }))

I assume that persist middleware doesn't mutate setState and therefore both options devtools(persist(...)) and persist(devtools(...)) are OK, but wanted to confirm as the examples are confusing and contradict the recommendation below them.

Also, the middlewareTypes test is showing devtools that is the ost outer middleware:

const useBoundStore = create<CounterState>()(
  devtools(
    subscribeWithSelector(
      persist(
        immer(…)
      )
    ),
    …,
  ),
)

I'm trying to understand it - is it a test to less optimum state and actually trying to mimic the opposite of the recommendation? or maybe leftovers from an older PR?

2️⃣ other middleware priority: subscribeWithSelector, immer etc.

Let's say I had 4 middleware (devtools, subscribeWithSelector, persist, immer) and wanted to use them in a way that won't introduce bugs due to mutations. What would be the most recommended order?

3️⃣ middleware priority with createWithEqualityFn

Is there any impact on the priority order when using createWithEqualityFn with shallow as it prevents rendering incase deep mutated objects in the store changed?

Thank you, appreciate your help on this.

[dai-shi]

both options devtools(persist(...)) and persist(devtools(...)) are OK,

Did you try if both work?

Middleware is interesting in Zustand. Implementation-wise, there's nothing for middleware. It's only about types and docs.

I think what we have in the middleware tests are the right order. If some patterns were missing we could add them.

As for createWithEqualityFn, equalityFn has only impact on hooks and not on stores.

[OrRosenblatt]

Thank you for responding! Good to know about createWithEqualityFn & equalityFn.

I'm still confused about the other ones - devtools, subscribeWithSelector, persist & immer.

Implementation-wise, there's nothing for middleware. It's only about types and docs.

Does it means that none of the middlewares above impact on or by the setState mutation?

Did you try if both work?

Both work, but I'm trying to understand the impact on mutation. If the pattern recommended is immer(devtools(...)) in the documentation, I don't understand why the tests are showing different implementation...

[dai-shi]

Does it means that none of the middlewares above impact on or by the setState mutation?

No, I just want to clarify that the code has no logic about middleware.
https://unpkg.com/browse/[email protected]/esm/vanilla.mjs

It means, there is no magic behind it, it's just a convention per se.

If the pattern recommended is immer(devtools(...)) in the documentation, I don't understand why the tests are showing different implementation...

It's fine for now if both work. I think it's better to change the doc to follow the test. Can you open a PR please?

[OrRosenblatt]

@dai-shi yes, I'll open a PR (sorry for not reacting so far, was out of town traveling)