Mark `createStore` as deprecated

We don’t want anyone using the core createStore method directly in their apps today. We want them using configureStore from RTK instead.

We should tag createStore as @deprecated on both the 4.x and 5.x branches, and do another 4.x release.

edit

After a bunch of discussion, it’s become clear that a lot of people aren’t familiar with what RTK actually is, or what the technical differences are between the core createStore API and RTK’s configureStore. Let me provide some background resources.

First, I had a chance to do a livestream with Jason Lengstorf where we explained what people disliked about Redux historically, and how RTK was created to solve those issues. We then built a small example app with RTK+TS:

• https://www.youtube.com/watch?v=9zySeP5vH9c

Next, the “Modern Redux with RTK” tutorial page shows the differences in usage between “vanilla” Redux and RTK for things like store setup and writing reducers:

• https://redux.js.org/tutorials/fundamentals/part-8-modern-redux

And for a lot of additional background on why RTK was created and how it evolved, see my “Redux Toolkit 1.0” announcement post.

For the actual technical differences, Lenz had a very good explanation on Twitter today:

In short: configureStore calls applyMiddleware and combineReducers for you and sets up the devtools, all while having a more “sane” api than createStore. For that reason alone, it should be a technical successor of createStore. In dev, it also adds two additional middlewares per default (middleware added by configureStore is freely configurable): One checks for accidental store mutations, both between renders as well as inside the reducer. That means it eliminates a whole class of bugs that only surface in “UI sometimes not rerendering” or things “being out of order some time later” - hard and frustrating to find. The other warns if you put non-(de)serializable values like classes into the store. Not only do these make a lot of problems with the devtools or libraries like redux-persist, even something as simple as a Date instance can mutate itself out of the normal Redux data flow. So, even if you were not to use the rest of RTK (which still makes you life a lot easier beyond that, removing the need for action types and manual immutable logic), it would still be a good idea to install RTK and use only configureStore out of it, instead of createStore.

There’s some comparisons of the before and after setup here:

• https://redux.js.org/usage/configuring-your-store
• https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#store-setup

[phryneas]

I spend time in Discord every single day. I see people struggling hours and days to wrap their head around concepts they don’t need and having actual frustration of pain they would not have to have.
And honestly, telling someone about that afterwards is not a nice conversation to have.

In the last two years I have observed hundreds on Discord, another few hundred on Twitter and yet another few hundred on StackOverflow. And those are only the places I am looking. Those are the places where knowledge of Redux Toolkit already has spread and yet, still people are going a painful way. Not because they have a way of choosing, but because they do not know better.

One of too many examples:
Stephen Grider’s horribly outdated “Modern React with Redux Training Course” on udemy had at this point 260.000 people taking it, with 75.500 mostly positive reviews averaging at 4.7 stars.
Even if the next 10.000 users would give it 1 star, it would stick around for another year without losing it’s top spot.
And people are not giving it one star, because he explains Redux-Form (which is deprecated on the homepage of Redux-Form, on the github page and in the npm README since 2019) nicely. They think they learn relevant information. They don’t.
And to add insult to injury the course author regularly does minor changes to the course so it is “recently updated” and more people will fall for it. He knows about Redux Toolkit for years now and has chosen to ignore us trying to contact him.

People not only buy into this shit, they also fall victim to the sunken cost fallacy. They already have put money and lots of time into this course, so they will keep following what they learned there. At that point I can tell them that I am a Redux maintainer and that they learn outdated stuff and a good chunk of these people goes on for days, weeks and even multiple months until they come around to try RTK. (And then almost nobody goes back. I think I’ve seen three people go back so far to vanilla Redux, out of all those hundreds.)

I have spent the last few years telling every single person that they are learning from outdated sources. I spend at least half an hour each day (realistically: probably more around two hours) going through twitter, StackOverflow and Discord telling people. Thinking that this “naturally ages out over time” at this point is naive. I have tried. Mark does too.
It will not happen within the next 2, 3 or 4 years.
The current situation actively damages the reputation of Redux because to this day people tell the story that Redux has a lot of unneccessary boilerplate and that they would rather chop their arm off than take another stab at it.

We can do more to change that.

Adding a deprecation warning is the least we can do. Also, I do not agree that we are hijacking the intended @deprecated usage. @deprecated does not mean that something will disappear anytime soon. Only that it is outdated and not recommended. In the spritit of “not breaking the web”, deprecated browser features sometimes stay around for decades after their deprecation.
A deprecation tag alone says nothing unless the person seeing it also reads the deprecation message attached to it. We can be very clear in our messaging there that createStore is a fine function to use if you need very low level control and want to do things by hand, but that we are nowadays recommending alternatives that are better suited in almost all cases.

But newbies would at least get an indicator that they are wasting their time.

[timdorr]

Hmm, I don’t really think this is a good idea for the core library. It’s not truly deprecated; we’re not getting rid of the API. This is giving the false impression this API is going away.

Also, I don’t really think it’s our job to tell users how to use the library. If they want to do dumb, bad, illogical things with it, that’s up to them. As long as we’re pointing them in the better direction of RTK everywhere else, that’s what we should focus on.