I use redux a lot, but i had never really tried redux-toolkit before. It took me a while to overcome the impression “oh look, data flying everywhere” and to recognise the familiar redux patterns — especially in the wildly terse createSlice.
What can I say about it? It’s wonderfully succinct compared to the boilerplate-dense standard redux experience. It’s darn clever to use a Proxy to encapsulate the object in draft state.
However, I am not convinced. Do I really need an opinionated library in case me or someone else in my team decides to slap an api call in a reducer? That would never pass a code review, anyway. And the library is so unconvinced that devs understand immutability that it makes it invisible, encouraging — heck, forcing — us to do something as horrid-looking as
state.users.push(...payload);
because immutability will be taken care of away by it, out of sight. Well, hmm, no, I suspect it’s not for me; although it may have its place in a team of redux-haters. Who am I to judge? 🙂 I won’t probably use it tho.
https://gist.github.com/barbaracassani/4b07c3b1f0ec49ff9b661eece78a1769
EDIT: a few months later and… once you get used to its admittedly quirky API (notably, the distinction between reducers and extraReducers feels awkward), it’s actually pretty neat to use. It drastically reduces the amount of boilerplate and duplication that affects normal Redux, and having Immer to handle immutability becomes really comfortable really quickly. So, I have been using it, with satisfaction.