Redux Toolkit — Pro & Con
As Redux Toolkit becomes more popular and I dig deeper into it. I’ve learned to keep my mind open and that it’s not for every situation. Hearing some great new perspectives from other great developers keeps my mind more open than before, so read on if you will.
So let’s start from the basics and do a little run down on what is Redux and Redux Toolkit.
What is Redux? To summarize, Redux is known as a predictable state container that maintains the state of entire applications, made for JavaScript apps. This helps write apps that will then behave consistently, run in different environments and making it easy to test.
What is Redux Toolkit? Think of it this way, RTK is Redux but with a wrapper around it. It meets the same end goals as Redux but saves you from making common errors, simplifies the process and is the suggested best practice. RTK is wrapped around the Redux core, containing packages and functions that are essential for building an app with Redux and has become the official recommended approach for writing this logic. I recommend the docs to read more on both Redux and RTK.
The most common cases that have been simplified with RTK are your store setup, how you create reducers and writing immutable update logic, and my personal favorite is creating slices (slices of state).
Okay, now we know the purpose of Redux as a whole and why you would need it. Let’s not overthink this, React is great and it’s possible to make an app without RTK or just Redux, but as the app gets more complex, it will become harder to manage all that state making more errors apparent. Don’t forget, prop drilling happens when using React, so instead of passing props downs from parent to child or using callback functions to send data back up the ladder, Redux solves this problem by having a store. Your store puts all your state in One place that you can then pull your state from.
Doesn’t RTK sound great? Better than we imagined and my personal top two benefits of RTK are:
- Using your Store as your single source of truth — Predictability
- Redux has strict guidelines about how the code is organized, making the code outcome easier to maintain — Maintainability
So when would RTK not work? Here it comes, a new perspective from another developer that has been the reason for keeping my mind open and changed my point of view. Think of this scenario, you’re using RTK and you have all your state in your Store. You have a single source of truth, but you are trying to debug and pinpoint where an error is. Think of this app, having millions of components and folders, files and all your state in in one place, the Store — that’s like a needle in a haystack. So is debugging and solving the problem more problematic and time-consuming now? Seems like when an application becomes too large to handle, you will waste more time debugging than if it was at a smaller scale.
This was a weakness that was brought to my attention, when my only opinion of RTK was “this is the best and greatest solution for prop drilling and when you need a place to hold your state to manage it”. So if I could find a solution to this problem, some initial thoughts would be: organization of state and the output it gives the developer within the Store could help and lots of error handling prep, before the error would happen.
So let me ask you this, what are you thoughts on this and can you point out another weakness to RTK?
Always keeping an open mind — Thanks for reading!
xoxo,
Nicoll