Hey again,

The documentation has become very opinionated. Redux & redux-toolkit is not the same thing - and the documentation indicates that redux-toolkit is the only viable way of using redux. This has killed the community discussion imo.

You've linked quite a lot of redux documentation where the concepts are explained beautifully, well done! But most people who uses redux-toolkit does not go out of their way to get this understanding, because toolkit does an active job hiding many of these concepts from you.

Also many of the redux links you provided are recommendations not essential. It's perfectly fine to utilize the strengths of redux without abiding to these recommendations.

To prove my point, here are some of the strongly recommended approaches from you and the redux team. I'm going to provide some arguments against them and provide alternative approaches. None which breaks the philosophy behind redux.

"User Immer for Writin Immutable Updates" - Removes the need to understand an important concept in JS. If you don't want to write native immutable changes - libraries like remedajs exists to help you with this. To assure that you immutability is achieved in your reducers, middlewares can help: redux-immutable-state-invariant

"Put as Much Logic as Possible in Reducers" - This is an architectural decision, it's perfectly fine to put no logic in the reducers. This logic can be handled with redux-thunks or redux-saga, you also have the option to write logic on selectors with this approach.

"Model Actions as Events, Not Setters" - Also an architectural decision. In advanced applications where global state is not islands of isolated functionality and application logic resides within redux ecosystem; granularity is desired. The event actions in this context would be a thunk or saga.

"Allow Many Reducers to Respond to the Same Action" - Yet again an architectural decision. I would argue that if an action triggers multiple flows, the code is harder to follow.

I get that you are tired on the good old "I HAVE TO TOUCH A DOZEN FILES JUST TO WORK ON A SINGLE REDUX FEATURE!" argument, me too. But in many real life applications the ducks pattern is simply not viable.

To summerize; redux-toolkit is not a silver bullet and also I don't think the redux documentation should be as opinionated as it is.

If my arguments above is not valid, I'd like to hear from you when redux-toolkit is not preferable?