Yeah, a number of folks have said "we wish RTK is how Redux always was". I wish that too, but there's no way we (or more specifically Dan and Andrew) could have come up with Redux Toolkit's API at the beginning.

For background, please read my two "Tao of Redux" posts posts [0] [1] to understand why Redux was built this way to begin with. Specifically, it was designed to have a minimal core, and be extensible.

In addition, given the existing Flux library APIs, _and_ that Immer didn't exist, there's no way the Redux Toolkit API would have been feasible at the time. We were only able to come up with it after years of watching how people actually used Redux in practice, and what libraries they were writing on top of Redux to solve specific problems. (People have pointed out that RTK feels kind of like Vuex, which makes sense - Vuex was inspired from Redux's API to begin with.)

Software design is an iterative process. It's based on trying to solve problems, at a specific point in time, with inspiration from existing tools and technologies, and constrained by what is actually available at the time. AngularJS, Backbone, Flux, Redux, Vuex, Immer, NgRx, Redux Toolkit... all of these tools have specific inspirations and problems they were trying to solve. Understanding _why_ tools were created is hugely important.

On that note, my post on "Redux Toolkit 1.0" [2] covers how and why we were able to design RTK's API this way.

[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[2]https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...