We adopted Redux when it first came out. While you are correct in that the API is very simple, and the strategy of Redux is simple, implementing state with Redux is anything but. I recall making several passes through the tutorials to grok the what is required to implement Redux in an app. Configuring the store, configuring the 'mother reducer', learning about HOCs, considering implications on the rest of the architecture, implementing selectors, unit testing, state "slices" and what that could or could not mean, leveraging the 'backloors' (ie 'ownProps') it was really overwhelming to me. After taking a hiatus from React for Angular, I found myself architecting a new React app, encountering RTK for the first time.I got to say that my impression was that it does a really good job in building the right abstractions for an engineer just trying to architect an app and manage its state. Granted that I would not really be qualified as a 'new user', I thought it was a step in the right direction for the purposes of Redux adoption. I would argue that the new concepts of RTK are also present in vanilla Redux, but in a more transparent way, IE the considerations I had just mentioned. Thinking about it, RTK is really just an abstraction that wraps vanilla Redux, essentially putting it on rails. With any rail system, you trade in some flexibility for safety in terms of removing chances for misuse. In that respect, RTK adoption should probably considered on a case by case basis. my 2 cents 😊.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We adopted Redux when it first came out. While you are correct in that the API is very simple, and the strategy of Redux is simple, implementing state with Redux is anything but. I recall making several passes through the tutorials to grok the what is required to implement Redux in an app. Configuring the store, configuring the 'mother reducer', learning about HOCs, considering implications on the rest of the architecture, implementing selectors, unit testing, state "slices" and what that could or could not mean, leveraging the 'backloors' (ie 'ownProps') it was really overwhelming to me. After taking a hiatus from React for Angular, I found myself architecting a new React app, encountering RTK for the first time.I got to say that my impression was that it does a really good job in building the right abstractions for an engineer just trying to architect an app and manage its state. Granted that I would not really be qualified as a 'new user', I thought it was a step in the right direction for the purposes of Redux adoption. I would argue that the new concepts of RTK are also present in vanilla Redux, but in a more transparent way, IE the considerations I had just mentioned. Thinking about it, RTK is really just an abstraction that wraps vanilla Redux, essentially putting it on rails. With any rail system, you trade in some flexibility for safety in terms of removing chances for misuse. In that respect, RTK adoption should probably considered on a case by case basis. my 2 cents 😊.