Status of redux core package.
romainmenke opened this issue · 11 comments
I just found out about https://redux.js.org/introduction/why-rtk-is-redux-today#why-we-want-you-to-use-redux-toolkit
The redux core package still works, but today we consider it to be obsolete. All of its APIs are also re-exported from @reduxjs/toolkit, and configureStore does everything createStore does but with better default behavior and configurability.
We use the redux core package exclusively and apparently for all the reasons the post says we should not use it :
- something without opinions
- something without configuration options
- something where we write (and thus own) the bugs
- small API surface
We chose the redux core package very deliberately over redux toolkit.
Yes we traded some convenience but we gained so much control.
We have very little interest in adopting opinionated libraries/frameworks that are sensitive to community trends.
We need low level, functional bits that we can rely on to remain largely unchanged for ±5 years at a time.
The redux core package is suitable for us, the redux toolkit is not.
Are there plans to abandon the redux core package as it exists today?
@romainmenke The redux core package is just "done". There is nothing to be added. Meanwhile, development has gone on for four years elsewhere.
There is no way we are going to abandon it in any way, since Redux Toolkit relies on it.
But, apart from keeping it running as it is, you will probably never see any updates to it in the future.
The api is done, it won't get any more features.
If you are happy with that: Of course you can still use "legacy Redux". But I would highly encourage you to implement a non-trivial example in both styles and compare before making the final call.
In all the years I have seen maybe two persons that actually wanted to stick to the old style, having tested both and given the choice.
maybe two persons
You can add our entire team to that list :D
There is no way we are going to abandon it in any way, since Redux Toolkit relies on it.
But, apart from keeping it running as it is, you will probably never see any updates to it in the future.
The api is done, it won't get any more features.
That is awesome!
We don't want new features or changes. (except for security patches, but given the nature of redux core those are unlikely)
But I would highly encourage you to implement a non-trivial example in both styles and compare before making the final call.
We are aware that there is a "complexity limit". At a certain point our approach becomes painful. This nicely aligns with our teams "complexity budget". If it becomes painful, it is something we should not be doing anyway. This friction is a good thing.
Thank you for confirming that redux core is not going anywhere :)
Have you considered using parts of RTK?
Honestly, there is not a single person that probably needs all of RTK, but the package consists of helpers and is tree-shakable.
Just adding createSlice (or if that is too fancy for you by creating action creators, createReducer) will probably greatly reduce the complexity on your side, while completely eliminating classes of bugs like accidental mutation of store values in non-Redux code.
Have you considered using parts of RTK?
We have, but there is no good way to enforce subsets of packages at an org level.
If I expose RTK then it becomes unclear which bits have been vetted and which have not.
We really do not mind the complexity of redux core.
There are also different types of complexity.
Using redux core results in more typing work, but this is a one time cost.
The code that is being written is not very complex.
It is easy to read and easy to follow the flow of data.
What we build are tiny islands of interactivity in projects that are 99% server side rendered. If we did build other things our requirements would also be different.
A result of what we build is also that the shape of our data types is simple and small.
We do not want to think or have opinions about these things :
- how do I write a state machine
- how do I subscribe to state changes
Redux core dictates how those two things work.
Our worst case scenario is a breaking change in a dependency that requires us to revisit and rewrite code that might be 10 years old.
We have, but there is no good way to enforce subsets of packages at an org level.
If I expose RTK then it becomes unclear which bits have been vetted and which have not.
You can do that with an eslint rule.
Our worst case scenario is a breaking change in a dependency that requires us to revisit and rewrite code that might be 10 years old.
But then you could still make the choice you do today: not updating to the new version/style.
As for RTK, we do have a few "breaking changes" in mind, for 2.0, but the related code is marked as "deprecated" for a few releases (that are months apart), will give you runtime warnings in dev since the last update and there is already codemod offered to apply them where it makes sense and the feature is widely used. Even before the deprecation, we already communicated the new preferred style for over a year in the docs.
I do not think you will ever get into this situation with Redux or RTK. We have a big userbase, move slow and don't break things.
Also, our code has so many users that you can be pretty sure that the bugs have been already found & fixed on our side - especially in things like createSlice that we have in since the 0.x versions.
At this point: I don't really want to "sell" RTK to you here, although I still believe it would be the better choice for you. But I do want to make sure that you make this decisions for the right reasons, and right now honestly, there seems to be a lot of fear projecting from other packages that might have burnt you in the past over to the Redux team.
there seems to be a lot of fear projecting from other packages that might have burnt you in the past over to the Redux team.
That is absolutely true and fair.
But when considering all the factors redux core has just always been good enough for us.
It ticked the most boxes.
You can do that with an eslint rule.
That is extra complexity which we just don't have with redux core :)
But then you could still make the choice you do today: not updating to the new version/style.
This is also extra complexity.
We would need to keep track of why we can't update that one package.
I do not think you will ever get into this situation with Redux or RTK. We have a big userbase, move slow and don't break things.
I do want to thank you (everyone working on redux) for this!
I came here slightly worried that we would need to do costly migrations, only to find the opposite.
Also thank you for the speedy and helpful replies here :)
I know we have a slightly different approach to all this than most users.
What works well for us might not work well for everyone.
Also thank you for the speedy and helpful replies here :)
Hey, thanks for not aggressively yelling at us - people have been very vocal about that one little strikethrough :)
(And we really need that to reach new users that come to us from outdated tutorial, of which there are many.)
I guess you made your decision.
Personally, I can only again recommend you give it another try - especially considering the extra complexity (and lies to the compiler) TypeScript adds to the whole thing without RTK in the picture.
But in the end, no matter which way you go: good luck with everything :)
@romainmenke : yeah, fwiw, we reallllllly recommend using RTK. You will have less code, you will have fewer bugs, and it will be easier to work with Redux that way.
I am very curious. You said "gain more control". Can you give some specific examples of how you're using Redux, and how writing the code by hand "gives you more control"? What use cases are you trying to solve?
I'd also disagree that RTK is "driven by community trends". We've specifically designed its API to address the many problems we've seen people run into using Redux over the years, and simplify all the standard Redux usage patterns we've taught in the docs and that people have used in their apps.
But yes, the fact that there are lots of people still using the original redux core package by itself is exactly why it's effectively frozen and we're not going to break anything.
You said "gain more control". Can you give some specific examples of how you're using Redux, and how writing the code by hand "gives you more control"?
That is not the type of control I meant :)
I don't know anything that I can only do in redux core and not in RTK.
redux core is smallest tool that did what we needed it to do.
- known exposure to a 3rd party
- limited set of knowledge needed by our team
- a low level lib is less likely to change
A larger, more feature rich tool would be much harder to control at an org level.
We are very careful and deliberate with the feature set of our "frontend toolbox". This reduces our maintenance/operating cost.
We are a web agency and we produce a lot of projects with a very small team.
Our clients often do not have a large maintenance budget and will want to keep using the same site for 5-10 years.
Our typical usage of redux is :
- 1 or 2 stateful components per project
- 1 reducer per component
- shallow and small data objects
- 1 or 2 subscribers to changes
This is tiny.
If we did build anything larger or more complex we would definitely use RTK.
I'd also disagree that RTK is "driven by community trends". We've specifically designed its API to address the many problems we've seen people run into using Redux over the years, and simplify all the standard Redux usage patterns we've taught in the docs and that people have used in their apps.
I will have interpreted this incorrectly from the blog post and gladly take it back.
@romainmenke : honestly, if that's how small your Redux usage is, you probably don't even need Redux in the first place :) like, useReducer would probably be fine:
But yeah, see these resources for more details on what RTK does and how we designed it:
- https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/
- https://redux.js.org/tutorials/essentials/part-2-app-structure
- https://redux.js.org/tutorials/fundamentals/part-8-modern-redux
- https://blog.isquaredsoftware.com/2019/10/redux-toolkit-1.0/
and given that RTK is from the exact same team that has been maintaining Redux for years, I would think that would eliminate the concerns about "known exposure to a 3rd party".
Also, RTK's own API is very stable at this point. RTK 2.0 will make some minor "breaking changes" in the form of removing a couple bits of deprecated options, but that's it.
honestly, if that's how small your Redux usage is, you probably don't even need Redux in the first place
That is correct :)
We use redux because we don't want to think about or have opinions on writing state machines or communicating state.
Redux core dictates how we must do that.
useReducerwould probably be fine:
We don't use react.
It's all vanilla with occasionally some lit html.
It is really not that I do not trust you, or the team behind redux.
I also do not think that RTK is bad or unsuitable in any way.
We picked redux core for reasons stated above and we never regretted that.
Switching now for existing projects is something that would be costly and we would like to avoid that. (that was my concern and why I opened this issue)
Given that we operate a mono repo it also doesn't make much sense for us to switch for new projects. That would add to the complexity of our stack and the mental model required to write code and make changes to existing code.
If we do however create a new mono repo for a new batch of client projects we will switch over to RTK :)