Awesome response Mark. That really clarifies why those APIs were included.
You've really got me thinking about this and I'm planning to write a post about my thoughts on RTK, both the pros and the cons. I will link it here when/if it gets completed.
Sure, please do! I'd also suggest reading through my Redux Toolkit 1.0 post, which goes through the entire history and background of why RTK was created, what problems it tries to solve, the "vision" for the library, and the evolution of its development and APIs up to the 1.0 release.
Obviously I'm biased, but the only meaningful tradeoffs I personally see in using RTK over "vanilla" Redux are:
Byte size for the extra functions and dependencies
Immer is an abstraction layer, and it's possible for someone to look at some Immer-powered reducers and not realize that there's "magic" inside and that they still have to do updates immutably in the end
Because Immer wraps the draft state in a Proxy, debugging can be harder because logging or inspecting the draft shows the Proxy instead and the contents are very hard to read
On the flip side of those:
RTK's APIs quickly "pay" for themselves by reducing the amount of app code you have to write yourself
So yeah, RTK certainly isn't perfect, but I can only think of a couple very minor concerns, and those are in turn far outweighed by all the benefits: standardized APIs, smaller app code, and prevention of common mistakes.
Awesome response Mark. That really clarifies why those APIs were included.
You've really got me thinking about this and I'm planning to write a post about my thoughts on RTK, both the pros and the cons. I will link it here when/if it gets completed.
Sure, please do! I'd also suggest reading through my Redux Toolkit 1.0 post, which goes through the entire history and background of why RTK was created, what problems it tries to solve, the "vision" for the library, and the evolution of its development and APIs up to the 1.0 release.
Obviously I'm biased, but the only meaningful tradeoffs I personally see in using RTK over "vanilla" Redux are:
Proxy, debugging can be harder because logging or inspecting the draft shows theProxyinstead and the contents are very hard to readOn the flip side of those:
currentutil to view the current state if neededSo yeah, RTK certainly isn't perfect, but I can only think of a couple very minor concerns, and those are in turn far outweighed by all the benefits: standardized APIs, smaller app code, and prevention of common mistakes.
My post is here.
I hope I succeeded in providing an accurate and balanced review of RTK. At the end of the day, it's all just my opinion.