3 ms·

Yeah, the toolkit does help a lot actually, I do appreciate you guys for coming up with that. But I wished that it was more like that from day 1. As others have

Yeah, the toolkit does help a lot actually, I do appreciate you guys for coming up with that. But I wished that it was more like that from day 1. As others have mentioned, it was the "Redux Experience", the sheer verbosity and redundancies that went along with it, for not much gain imo. I'd have liked a lighter abstraction layer.

acemarke 7y ago
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-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [2]https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
- apotheon 7y ago
  I'll have to look at that the next time I need to build the kind of JavaScript app for which it's appropriate. I haven't done that kind of work in a couple years or so. Thanks for the explanation.

acemarke 7y ago

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-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [2]https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/ https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

apotheon 7y ago
I'll have to look at that the next time I need to build the kind of JavaScript app for which it's appropriate. I haven't done that kind of work in a couple years or so. Thanks for the explanation.