What is the best approach to migrate to a new state management tool?
I have a project that I'm working on with bunch of people and redux is used for state management, it's kinda chaotic...
What is the best way to migrate this thing to something more viable, like react query + zustand (if needed)?
My initial approach would be to start implementing new features using react-query + zustand, and also integrating it when refactor of old code is needed.
Is this the right thing, or is there some better option? (other than rewriting everything)
10 Replies
you can start using the new without changing the old tools
and change them overtime
thanks!
Also have a think to ensure moving is the rigjt approach
Ie why was it chaotic with redux?
You want to avoid a situation where you spend all this time and money moving to a new system and then later on are like "man this react query stuff is chaotic let's move to <insert new framework here>"
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
No, it's because I think redux is overkill for the application that we've built and continue building. Redux is not needed for my situation, because the app is an admin panel which most of it is just fetching/mutating data from/to an API, for which global application state is not really needed, thus developers write more code which is kinda useless, takes more time, and makes the code unmaintanable, and so on...
No, it's just plain redux with redux thunk middleware, it's like the old school way
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yeah rtk is nice
But also is it the most valuable refactor you could do
Not my job but your approach seems alright
Just need to make sure you do migrate everything over
And make it very clear what the desired architecture is
And why
I'd write up a business case if it really is a big deal
Thanks for your help @Scot. Everything that you said is definitely on point. I will make sure to look into everything in detail before making any decisions on this one.
Unfortunatley, I've seen my fair share of old redux code, and by far the most common problem is bad selector memoization, and just plain chaos around all the boilerplate.
RTK solves these out of the box. 👍
The second most common issue was shoving server state into redux.
RTK query solves that issue. 👍
The third most common issue was shoving routing inside redux... I just don't even want to talk about that, I still have PTSD.
If the project and the team is already heavily invested into the redux world, I'd probably stick with it. I would introduce slices with RTK, add RTK query, and be happy with it.
I don't think you should think much about switching to RTK and RTK query from old school redux boilerplate. Especially for new features.
Refactoring old, working code, is always a tough one, many factors there.
As @Scot mentioned, it's a good idea to have a reference implementation, and once there is agreement around that, things get easier.
Thank you @robotkutya for your detailed explanation, appreciate that. I totally agree with you