Correct way to add middlewares

[leochoo]

https://redux-toolkit.js.org/api/serializabilityMiddleware
In the above doc, the middleware is added like this:

const store = configureStore({
  reducer,
  middleware: [serializableMiddleware],
})

However, many other examples add middlewares like this
https://redux-toolkit.js.org/api/configureStore

const store = configureStore({
...(omitted)
  middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(logger),
...(omitted)
})

1. Why are there two different ways to add middleware?
2. Is one way better than the other? Is there a preference?
3. How can I add multiple middlewares correctly? I was able to get mine working by coding middleware: [serializableMiddleware, logger] but is this correct?

[markerikson]

Yeah, that particular docs example dates back to the start of RTK, and is now outdated.

Originally, the middleware option just accepted an array.

Internally, configureStore calls a function named getDefaultMiddleware() to come up with its default list of middleware to add: thunk, plus the dev-mode check middleware. We originally exported that as a standalone function, so you'd do: `middleware: getDefaultMiddleware().concat(logger)``

But, later we found that didn't work great with TypeScript. So, we modified the middleware field to accept a callback function, which passes in a correctly-typed version of getDefaultMiddleware as an argument.

The only time you'd even consider passing an array by itself is if you want to completely replace the default middleware, which is generally not how it should be used.

The right answer overall is:

middleware: (gDM) => gDM().concat(middleware1, middleware2, middleware3)

[leochoo]

The right answer overall is:

middleware: (gDM) => gDM().concat(middleware1, middleware2, middleware3)

Hmm but this doesn't work for me.

The type matches but I still the error

...omitted

const serializable = createSerializableStateInvariantMiddleware({
  ignoredActions: [FLUSH, REHYDRATE, PAUSE, PERSIST, PURGE, REGISTER],
});

export const store = configureStore({
  reducer: rootReducer,
  middleware: (getDefaultMiddleware) =>   getDefaultMiddleware().concat(serializable, logger),  // this doesn't work.
  middleware: [serializable, logger], // <- this works
});

My midleware serializable has a type of const serializable: Middleware<{}, any, Dispatch<AnyAction>>
concat's definition is concat<AdditionalMiddlewares extends ReadonlyArray<Middleware<any, any>>>(...items: AdditionalMiddlewares): MiddlewareArray<[...Middlewares, ...AdditionalMiddlewares]>;

The type matches so I expect it to work but why doesn't it?

[leochoo]

I was able to get it working with this code...

 middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      serializableCheck: {
        ignoredActions: [FLUSH, REHYDRATE, PAUSE, PERSIST, PURGE, REGISTER],
      },
    }).concat(logger),

That said, shouldn't this documentation be fixed?
https://redux-toolkit.js.org/api/serializabilityMiddleware

Not only does it contain an old implementation of middleware, but TypeScript and JavaScript codes are also exactly the same.

[markerikson]

That's a totally different thing. That's not a TS error - that's the "serializability check" middleware warning you you're passing through non-plain-JS values.

FWIW we do specifically mention the redux-persist thing here:

https://redux-toolkit.js.org/usage/usage-guide#use-with-redux-persist

For the TS behavior... I'd need to see a CodeSandbox or your repo to really poke at it and see what's going on with the types.

[leochoo]

@markerikson Thanks for the link. Understood.

On a side note, while I greatly appreciate the effort behind Redux team and how difficult it is to organize the information well, I still find Redux documentation to be one of the most confusing ones to go through.

Is there room for contribution? or is this managed by the Redux team only?
Or do you know if there are any roadmaps for improving the documentation?

[markerikson]

We're absolutely always open and appreciate help working on the docs :)

That said... while it's getting off topic from the original question, can you point to some specifics about the docs that you feel makes them "confusing"? Is it about the fact that we've got three separate docs sites? The way the pages are organized in the table of contents? The actual explanations in specific pages?

FWIW we're pretty happy with the current docs content and structure atm. There are a lot of pages in the Redux core docs sites that were never updated to match our current recommendations, and I've been very slowly working on those for years : ) (see reduxjs/redux#3592 for an overview of the very long-running effort there.) But no, we don't have any immediate plans to drastically redo things.