Mark createStore as deprecated

[markerikson]

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]

Just a first wording suggestion:

 * @deprecated 
 * In most cases, you should be using the `configureStore` method
 * of the `@reduxjs/toolkit` package instead of calling `createStore` directly.
 * As `configureStore` is calling `createStore` internally, it will not be going
 * away, and your code will continue working but if you are just starting a 
 * new project, please be aware that we recommend using the official 
 * Redux Toolkit for any newly written Redux code since 2019. 
 * 
 * You should not be using this in a new project or when following a tutorial, 
 * except for learning purposes.

[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.

[phryneas]

The problem is that this is essentially the last resort how we can "contact" users that either never revisited the documentation or are following outdated tutorials.

Honestly, I'm less concerned about users that never revisited the documentation: it's on them.

But I deeply care for users that are learning from an outdated tutorial - or from e.g. a bootcamp where the teacher is still teaching vanilla Redux because they never revisited the documentation. (And there is even a bunch of teachers who should know better and still teach wrong stuff because they don't want to rework their course as long as it brings in money - and those courses keep getting good ratings because the users themselves don't know better. It doesn't help that one of those courses is the highest-rated "Redux" course on udemy)

They are not "at fault" here, but are being steered in a very wrong direction and will be deeply hurt as a result. And there is no other way to contact them than a "strikethrough" in the editor at this point. We will not be able to reach these users by an extra bright-red warning on the homepage or 10 new points in the style guide.
But to keep Redux relevant, we have to reach them.

I would be very fine to add another non-deprecated createStore__iKnow or something for people that really want to use createStore and don't want to see the @deprecated message.
But I am very convinced that we need to step up to this "next level of communication".

[timdorr]

Is it really a problem that people are using Redux directly without RTK? People do dumb stuff with other libraries. Heck, I do dumb stuff with other libraries all the time. It's not really up to the library to judge how I use it.

This is also an issue that naturally ages out over time. As those outdated tutorials get more and more outdated, they get seen less and less. There are plenty of old React tutorials still suggesting React.createClass() usage, but the React team hasn't put a warning on that API. Just because it's no longer the best way to use the library doesn't mean it needs to get marked as deprecated.

At the very least, I'm against this because it hijacks the usage of @deprecated in the code. What happens when we want to actually deprecate things? Now it's confusing to know which is which.

[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.

[markerikson]

I'm inclined to agree with Lenz here.

This doesn't prevent anyone from using createStore. All existing and new code will work fine.

But we really don't want people using it directly today.

This would at least give a visual indication to users in their editors that we encourage use of RTK instead. And frankly, as far as I can tell a majority of learners are coming into Redux without seeing that RTK exists, even today.

Ideally, users would:

• See the createStore deprecation message
• Learn that RTK exists
• Go read up on it and install it
• Also see that other APIs like createSlice exist and realize they can use those

[Brianzchen]

Hi, I'm chiming in because why not. I've used redux since 2016, I saw Mark posting about rtk last year or something and I've opted to not read it beyond the homepage cause it didn't interest me. I don't consider myself a newbie or a complete dumbass I hope.

But that doesn't mean using createStore is wrong. I like to create my own store and tooling around it. Sure it's not standard but I build hooks with react and custom middleware that fulfils my usecase well. Redux was always a simple core library and essentially telling everyone that if you want to use it directly means you're wrong then that just isn't right.

Yes redux has initial boilerplate cost and maybe it's complicated for new Devs but please, deprecation as a means to encourage rtk is not the correct move, that's not real deprecation unless you really plan to remove createStore some day. The right tool should be used for the job. Update the jsdocs to tell me to use rtk if I want an easier life but don't deprecate the API just because you don't like people using it.

Honestly it makes me sad how opinionated the JS ecosystem has become.

[phryneas]

If this is about the word "deprecation", we can happily also just add a runtime console warning that is visible in dev on every app start and can be disabled by setting global._IReallyWantToUseVanillaRedux.

Or we deprecate it with intent of future removal and add a __internal_createStore function in the next version.
Tbh., I'd be fine with that, too. I just don't think it's necessary.

Let's be real: Every other way of telling the users will be more disruptive than a strikethrough in the editor.

@Brianzchen I hope you don't take it personal, but you have just now given a prime example why that warning should be there:

• At the point you have heard the first time about RTK, it has already been the officially recommended approach for any newly written Redux code for two years.
• When you heard about it, you didn't check it out much further.
• You somehow have the impression that configureStore would lock you in and not allow you to use custom middleware.
• You also have the impression that this is just about initial boilerplate cost and not a massive improvement in day-to-day use and reduction of potential bugs.

Also, those subscribed to this issue might have noticed that there was one more comment here that was deleted by the author again. The author expressed anger because now Redux would become "all about React". Clearly the messaging that the RTK core has nothing to do with React and should be used by everyone independently of Framework did not get through there in the past three years.

Taking a step back, frankly Redux is probably one of the only libraries I can think of that did not introduce a breaking change to make life for their users easier because an old core api was replaced with a newer, more user-friendly one.

Thinking about libraries I am using in the ecosystem:

• Apollo has done so in what feels like almost every major version.
• Material UI has breaking changes left and right. (As most UI libs in general have regularly.)
• React Router had really breaking changes, because their approach shifted.
• React itself has had big paradigm shifts and they did officially declare mixins as harmful.
• RxJs had massive api/usage changes as well.

Those are just what comes to mind.

Maintaining a library is also about finding better ways for our users to use it. About giving them better ergonomics.

This is nothing to be fearful of. Yes, the old stuff still works. That doesn't mean there isn't a better way of doing it and maybe we should help our users to find the right tools instead of going "yeah there are docs here, if they don't read them it's their own fault".

[ematipico]

I really like that you authors care about the users, and I share the same sentiment.

There's also the fact that if people still rely on old documentation or don't care about updating themselves, it means that they don't care about the software they intend to use, or to be more specific, they care only about the software they intend to use to begin with, and redux might not be among them.

Software changes and it's harsh, sometimes. If the change brings positive outcome in the long run, so be it.

I think this is a good move and you should go ahead. RTK is more newbie friendly and lowers the barrier to adopt redux.

It could be called "archived" if deprecated is not the right wording. Or a warning might work too.

[zdhr]

The way I understand it is that you want to deprecate entry point to the library? So you want to deprecate the library itself?

What will RTK use, if createStore is deprecated? Some internal stuff? What should other "toolkit" libraries use?
Or will you just merge redux & RTK into some big blob with all of RTK's dependencies and without the possibility of (normally) using vanilla redux by itself?

What if I don't want to use RTK? I looked at it long and hard and decided I don't want to use it for multiple reasons. I don't think I'm the only one in the entire world.

If your concern is for newbies, then update documentation. Maybe add message to install log.
But please no deprecation and no annoying warnings in runtime in console with flags we will have to set to get rid of them.

[phryneas]

@zdhr have you read the suggested deprecation message above?

As configureStore is calling createStore internally, it will not be going away, and your code will continue working

Using createStore directly would get a deprecation message, since that is not the recommended approach to use Redux, by the Redux style guide and documentation, for over three years now. You can however always choose to just ignore the deprecation message. As the message states, createStore will not go away - we as library authors are just of the opinion that you should not be using it, since there are better alternatives.

If your concern is for newbies, then update documentation.

That has obviously no effect. Best example is your comment itself: We have done so for years and it seems you didn't notice, or you would not suggest this.

Maybe add message to install log.

That will not be noticed by anyone.

[mattpocock]

The fact that you're considering this approach gives me faith in the library as a whole going forward. Using @deprecated is essential because it provides VSCode users with a strikethrough on the createStore() func. It may 'feel' imprecise, but it's essential to have the visual indicator to trigger folks to look at the docs. If JSDoc/VSCode supported a @strikethrough tag, this would be preferred - but it doesn't.

I'm sure you'll do this too - but I'd recommend adding a long-form section to the docs with why this approach was taken and link it from the comment.

[markerikson]

Yep. That's exactly the idea here.

As seen in this thread and the responses to my tweet about this, there are definitely plenty of people who are still using vanilla/legacy Redux in existing apps today. We are not going to break anyone's code, even if/when we release a new redux major version. Period.

But...

We explicitly do not want any new learners adopting those practices today. And unfortunately, many learners never even think to look at our docs. Given the prevalence of all these horribly outdated courses and tutorials even today, adding a @deprecated flag is the only way we have to communicate this warning to people who otherwise will likely never hear of RTK in the first place.

[markerikson]

For the record, we did previously discuss the idea of moving the existing APIs into a @reduxjs/core package and moving what was then "Redux Starter Kit" into the redux package. But, that was all the way back in late 2018:

#3321: Discussion: Consider expanding the Redux core

I'd really still prefer to not go that direction today. We already did one big package rename from redux-starter-kit to @reduxjs/toolkit. We have a ton of docs and templates that refer to @reduxjs/toolkit. Additionally, shuffling packages would most likely require trying to merge all the separate Redux projects into a single monorepo, which in turn would lead to having to completely redo all the docs sites. (I've very briefly considered trying to have a single consolidated docs site so all the material is in one place, but the need to have a monorepo to make that work is basically a showstopper - that's just too much time and effort.)

Adding a single visible indicator to one API method is the lightest action we can take without requiring prohibitive amounts of effort on the part of either maintainers or users.

[gkatsanos]

I'm not sure if this is a useful comment, I clicked around the first tutorial presented in the docs, and the first example I landed on was using createStore. https://github.com/reduxjs/redux#basic-example . The example right after of course offers the simplicity of toolkit, but I think it'd be quite useful to make that more prominent in the docs. The same deprecation note as a highlight in the docs would go very far.

[denisw]

I am maintaining an alternative Redux utility library called redux-preboiled. I am sure there are other several alternatives to Redux Toolkit that do not have their any createStore wrapper.

To me, a deprecation of createStore would make no sense at all. Telling users that they literally cannot use core Redux without a deprecation warning unless they use Redux Toolkit strikes me as extremely weird. In fact, it feels like pressuring the user to use Redux Toolkit, for no technical reason whatsoever.

It would be more honest to simply roll Redux Toolkit into Redux and require them to be used as a whole. A pseudo-deprecation, on the other hand, feels to me like keeping up only the faintest illusion of a choice of utilities on top of core Redux, while in fact discouraging everything but Redux Toolkit so heavily that the choice might as well not exist.

[markerikson]

@denisw tbh that is the point. We want people using RTK, and for very good technical reasons (avoiding common bugs, etc).

I do respect that power users like yourself have built your own approaches on top of the Redux core, and we don't want to take away your ability to do that. That's why I keep pointing out that we're not going to break anyone's existing code.

But to be frank: while the explosion of early interest in Redux resulted in a giant ecosystem of addons, it's become extremely clear that what today's new Redux learners benefit from most is a single standard approach to learn and use. Having dozens of libs for generating action creators, and other similar behavior, is confusing rather than helpful.

As maintainers of both the Redux core and RTK, and the people who spend countless hours on a daily basis answering questions from people who are learning Redux, we see the problems that both learners and "typical dev" users run into all the time. RTK was designed to solve those problems... and it's succeeded.

So yes, from our perspective, we are trying to "eliminate the choice" in a sense, because we're trying to guide our users into a path that solves their problems before they even know those problems exist.

This is a delicate balance to strike here, and we're trying to take all potential use cases and constituencies into account. But in the end, we have to take the steps that we feel will result in the best possible experience for the largest possible portion of our userbase.

[phryneas]

@denisw don't you think that people might actually be reading the deprecation note? This whole discussion is so much hate around that one little tag, not around the text after.

Besides that: even Redux-Preboiled seems like it would massively benefit from using configureStore instead of createStore for store setup and just ignoring the rest of RTK.

[denisw]

I'm not "hating", I just find it important to point out that this is a misuse of the concept of deprecation. And while I'm sure many will read the note, it will still look like a problem to use createStore - that the code will break - while this is not the case. Editors will highlight the problem; linters will report it; static analyzers like SonarQube will flag it; and all despite there not being anything to fix.

I guess the deprecation will fulfill the purpose of making users aware of Redux Toolkit, and I understand that this is important to guide newcomers in the right direction. But to those that do not Redux Toolkit on purpose, this may have leave a bad taste. It may even feel like a "dark pattern" to push Redux Toolkit on them.

To be clear, it's not a lack of choice that I find problematic. I would be happy to see Redux Toolkit's features being rolled into Redux, even though this would make Preboiled effectively obsolete (RTK is quite similar and more full-featured anyway). What I think annoys me is the pretense of choice combined with questionable nudges like this one; this is what I meant with it not feeling honest.

[markerikson]

@denisw : as I mentioned above, we've had a couple prior discussions around the idea of shuffling the packages around, but those would both require a ton of effort and be more confusing to end users.

it will still look like a problem to use createStore

That's... still the point :) From our perspective it is a problem. (And so is the pattern of writing a bunch of Redux action creators/action types/reducers/logic by hand.)

It's much like React's deprecated lifecycles. componentWillReceiveProps still works. But it's a pattern the maintainers are specifically recommending against using, and it prints warnings if those functions exist. To avoid the warnings, you specifically have to effectively acknowledge that "I understand this is not the recommended approach, and I'm okay with that", by renaming it to UNSAFE_componentWillReceiveProps.

So for createStore, this situation seems exactly like the definition of "deprecation" to me:

deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use. Typically, deprecated materials are not completely removed to ensure legacy compatibility or back up practice in case new methods are not functional in an odd scenario. It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future.

Frankly, this is a sort of no-win scenario for us:

• Do nothing: continue to have tons of users get pushed into legacy Redux patterns, not even know that RTK exists, and end up with codebases that are buggier and full of boilerplate code and think that is "how Redux should be used"
• Shuffle packages around: have a subset of power users yell at us because they're now getting more deps and APIs than "they feel they need", and also now there's a lot of work to redo our docs and setup instructions and templates and maybe even entire repo structure
• Mark createStore as deprecated: have a subset of power users yell at us because they're still using createStore, but at least there's a chance that other users will learn about RTK as a result

I understand the complaints being raised in this thread and on Twitter, but at the same time I'm kinda confused at why you and a few others are saying that this feels like a "questionable nudge" or "crying wolf".

Is it because we're talking about labeling createStore as @deprecated without planning to remove the API? Would it somehow be better if we said "this is actually going away completely and all your existing code is gonna break unless you switch to RTK right now?"

[phryneas]

@denisw that's why I already suggested a potential second export with a different name, without the deprecation note.

In the end, this change will end up as

• users sees deprecation note
• user reads deprecation note
• user makes the conscious and educated decision to either use createStore__noDeprecationWarning or use RTK.

So for users who want to keep the current behaviour without a warning, it's a single code change. For a lot of other users, potentially eye-opening.

Mark already quoted the Wikipedia page on "deprecation" on Twitter, but I'm going to do it again here:

"the discouragement of use of some feature or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use"

We are 100% within the boundaries of that.

PS: seems Mark quoted it here, too, while I was still typing ^^

[markerikson]

So back to the original point of this thread.

My proposal atm would be:

• Add a @deprecated tag to createStore
• Add a new Redux core docs page that very clearly spells out "RTK is how we want people using Redux today. createStore is not going away, but we advise against using it or writing Redux logic by hand".
• As part of that @deprecated tag, have a message similar to what Lenz wrote at the top of the thread, and link to that page for more details.
• Also add export const createStore_legacy = createStore, with no deprecation warning. This would be equivalent to React's UNSAFE_componentWillMount. It runs, same behavior, but no deprecation notice.
• Publish this as Redux 4.2.0 .

If users do nothing, their code still runs 100% as-is. They just see a strikethrough version of createStore if they look at that file in their editor, and possibly get a notice if they're actually set up to do a code quality scan like SonarQube.

If that bothers them, they change one import name, and having acknowledged the fact that this is not the approach we want them doing, continue on their merry way, again with no code breaking.

I'd still prefer to avoid any further package shuffling shenanigans, if only because I'm lazy and that promises to be a gigantic amount of work I'd rather not take on :) But, I'm at least open to having a completely separate thread that revisits the idea of moving packages around to at least see what people's thoughts/ideas are there, with the understanding that it's still a hypothetical thought exercise with no immediate plans to actually change the status quo.

[sarimarton]

The way I see it is that the main appeal of base redux is at the very core of the 'boilerplate' people complain about: simplicity. RTK is an opinionated API layer, which promotes way more answers than questions were asked. Do I need that query stuff? Do I want to trigger side effects from component code at all? Do I want action creators or POJO actions? Do I want to define my event types? Do I want to use immer to avoid the spread-hell, or something else, like deep assign()? Do I want a general setter action when the user actually sets stuff? Do I want to use react as a 'glorified templating engine' and move business logic to middlewares, which can be easily migrated into state machines? (I do)

Lots of questions from which a few not compatible with RTK is enough for a dev to decide not to use it. I think the core motivation to not wanting people to use the base version is at least questionable. I see the 'custom solutions/onboarding problem' argument questionable too: I've seen so many unpleasant code bases where the dev tried to follow the 'recommended way' in every corner, but it eventually led to many implicit decisions. (A typical case is reaching out to APIs in an ad hoc way, without thinking in patterns.)

I also disagree with the semantics bending about the term 'deprecation'. The WP article mentions the 'removal' aspect permissively but I'd say it's the typical usage. It's also typical to deprecate something in favor of an alternative on the same abstraction level.

The honest version here would be to separate the 'redux' and 'RTK' brand, and focus on RTK in your discord etc. activity. That way you wouldn't be bothered by people using redux.

[eddhurst]

It's interesting that you have investigated consolidating the packages, and ultimately shelved it as an arduous task that would require significant maintainer time investment. It sounds like if it were a one click merge, you'd have done it by now.

From what I'm reading, it feels like the most consternation is around consumers being strong armed into using an opinionated api layer they feel like they shouldn't be shamed into using.

Is there an option to middle ground, now or in the future, where you don't blend the entire RTK but just port over what's needed for configureStoreto work. At which point this becomes a true proposal for deprecation with an internally supported replacement.

For right now that doesn't change much except perhaps the deprecation notice becomes an official "we are looking at ways to actively remove this as a public api, and replacing it with parts of RTK, but we're still working on the details"

Perhaps this doesn't solve for "we want to teach people to use RTK", but it also feels like pinning all those hopes and dreams onto a single deprecation notice is unrealistic, and would have to be considered as one step in a many layered plan.

[markerikson]

In the interest of keeping this particular discussion focused on just the "deprecation" aspect, I've created a separate discussion thread to discuss whether changing the package structure is A) anything we would even want to meaningfully consider, B) feasible, C) what it would hypothetically look like:

Discussion: Debate changing Redux packages to merge "Redux" and "RTK", again

[markerikson]

@sarimarton :

FWIW I don't think I'm "bending semantics" at all. What I'm describing exactly matches the Wikipedia definition I quoted: "discouraging use of a feature because it's been superseded, without completely removing it".

The honest version here would be to separate the 'redux' and 'RTK' brand, and focus on RTK in your discord etc. activity. That way you wouldn't be bothered by people using redux.

That really isn't going to happen, for multiple reasons. To us maintainers, RTK is "Redux" today. At the same time, we do have a responsibility to anyone using any Redux-related package. People are not going to stop asking questions, and we're not going to ignore questions just because they're using older practices. But trust me, it's realllly tiring to see yet another user posting a question in Discord and asking why their UI won't update, when RTK would have prevented that problem from ever happening in the first place.

@eddhurst :

This goes into both the historical background of how long Redux has been out there, and the "power users" who are using the Redux core by itself and don't want anything else (ie, several of the people commenting in this thread).

As I've said several times: we're not going to break anyone's code. Even when we put out major versions of our libraries, we aim to keep any potential changes to an absolute minimum. Sure, by the rules of semver we'd be totally clear to rename createStore to legacy_createStore with no fallback... but doing that would needlessly break valid running code. We're not going to do that. So, no, we're not removing createStore. But we do want to actively raise awareness of RTK, and nudge people to move over, just like React did with the UNSAFE_* lifecycle changes.

[migueloller]

I don’t think it makes any sense to have a library be installed where the main entry point is deprecated. If the maintainers intend for a different library to be used, then deprecate the whole thing and recommend the other library. Having to install RTK just to use configureStore just doesn’t make sense to me. The redux package just wouldn’t stand on itself anymore. It seems that the maintainers want to keep the popularity of Redux, while forcing everybody to use RTK, without paying the maintenance cost of making Redux itself evolve to provide RTKs features.

RTK is a different thing. It uses the Redux core internally, but it’s a different thing. Deprecating the core’s entry point just to push people to use RTK would leave a horrible taste in a lot of devs mouths, I think.

[josh-degraw]

There's a lot of debate here about semantics. At the end of the day, the idea here is to add a comment to the source code, as a way to encourage users to use the preferred tooling for the library, without breaking any existing code. There wouldn't be any console warnings, just a subtle visual indicator in certain IDEs that can gently nudge devs to investigate. Especially given the fact that there could be an alternative entry point that points to the exact same function and doesn't have that comment, I really don't see any real reason to oppose this.

I've been working with redux for years and the only reason I found out about RTK was because I happened to see Mark post about it on twitter. But I would absolutely fit into the target audience for this change, in the sense that if I hadn't already heard about it, but I saw that createStore was marked as deprecated, I would inspect the depreciation warning and look into RTK and embraced it. Adopting RTK has made my life much easier and our codebase much cleaner, and I have found and fixed multiple existing bugs directly because of it.

So in short I'm strongly in favor of this proposed change, largely because if it had been there a year or two ago, I would have been able to avoid a lot of headaches because I would have heard of and adopted RTK much sooner.

[markerikson]

Given the discussions in this thread, I've just published a new Redux docs page:

Introduction > Why Redux Toolkit is How to Use Redux Today

It includes:

• A review of what "Redux" really is (store, actions, reducers + immutable updates; optionally, standard patterns like thunks, normalization, selectors, DevTools)
• A look at what the redux core package actually does and does not provide
• A look at what the @reduxjs/toolkit package provides and how its APIs help cover the standard use cases commonly seen in Redux apps
• A more specific explanation of how we recommend RTK as the default standard approach for writing any Redux logic, and how RTK solves the problems that users have experienced over the years from following "boilerplate"-y patterns and hand-writing vanilla Redux logic

Hopefully this helps clarify some of the mindset here, and shows that Redux Toolkit really is "Redux", just improved.

[migueloller]

Just read the new docs page explaining RTK and its benefits over core Redux. Good job in that page, it's very well written.

FWIW, after reading it I still came out of it feeling like I've felt in the past when I've read about RTK: looks great, specially for beginners, but I prefer vanilla Redux. I'll share two reasons here. First, createSlice is biased towards a 1:1 relationship between reducers and actions while Redux has always been about a 1:n relationship between reducers and actions. Second, immer is great and getting it for free with createSlice is nice but there's a cost associated with that: bundle size. Now, for most applications that difference would make absolutely no impact. But no one here's arguing that core Redux is absolutely essential for all apps, just that it's important to understand that some advanced users might prefer it. Just my 2 cents.

Finally, to add some context, we use Redux to power Makeswift. It's been indispensable for the wire protocol we use for postMessage communications as seen in our @makeswift/runtime package. We decided to go with vanilla Redux and redux-thunk, because it's extremely light weight and gives us exactly what we need.

[phryneas]

@zdhr "deprecated" does not necessarily mean "it will be removed", but "there is something better, please use that".

And even with every other solution you might be using that is not Redux Toolkit, if you are manually calling createStore in your application, Redux Toolkit's configureStore is the better solution - even if it is the only API from Redux Toolkit you will end up using. (Ignoring libraries that implement an alternative implementation of configureStore themselves, but then you as a user would not be calling createStore.)

configureStore:

• automatically combines your reducers for you, no combineReducers call necessary (of course you can still do that if you e.g. want to set up a persisted rootReducer)
• automatically calls applyMiddleware for you. You can either
  • pass in your own array of middlewares, or
  • it sets up a set of "default" middleware:
    • thunk
    • (in dev) the serializability middleware: this warns you if you accidentally pass non-serializable values into your store, as these are known to cause all kinds of bugs with the devtools and various ecosystem libraries, such as redux-persist
    • (in dev) the immutability middleware: this checks for accidental state mutation in reducers and between dispatches and warns you about those. That eliminates a whole class of errors, even if you still stick to hand-writing all your reducers with switch..case or use another library for reducer creation
  • you can configure all of these, or opt out of some of those default middlewares, and choose to combine them with your manual middlewares. It is totally possible to opt out of thunk, add saga and keep the serializability & immutability middlewares
• it automatically sets up the devtools for you (of course you can disable them)
• it allows you to add store enhancers without having to call compose
• it allows you to pass in a preloadedState

All of that not with positional argument, but with a configuration object, which makes it very obvious for the reader on first sight what is actually going on there.

So, that single one fact alone is enough reason to deprecate one for the other. Even before we come to all the other reasons why we want to deprecate it - education being the most important one.

[migueloller]

I want to reword what I said before. I'm not against deprecating createStore. Following the definition given multiple times here "deprecated means that there is something better, please use that", I'm ok with createStore being deprecated. The problem is that usually, the "better thing" that can be used is provided by the same package. Having to install a separate package feels like the original package can't stand by itself anymore if its entry point is deprecated and the "better thing" is elsewhere. This is why I think the argument to just bring RTK into Redux as a major is fine.

As for the suggestions to deprecate createStore and add another entry point called initializeStore or something like that, the idea would be to simply rename the function, keeping the same API. In this case, deprecation is being used as a social tool to promote a different way of doing something in a separate package, instead of as a tool to suggest a "better thing" or more specifically, "a better API". I think that's what's rubbing people the wrong way. Not changing the behavior of the Redux package but taking advantage of what deprecation does to nudge people into using a separate package. Not because the package is moving to a separate API, but because people are not using the toolkit built in too that makes it easier and less bug-prone.

Hopefully the better explains why it feels weird to deprecate createStore without bringing RTK into Redux or for some other reason other than "we want people to use RTK".

[phryneas]

@migueloller we could of course just merge RTK into Redux, and honestly, at this point that would be the right thing to do if we were just having this whole discussion in a perfect world where there would not be two full sets of documentation maintained by essentially one person, two monorepos and 300k downloads of @reduxjs/toolkit a day that would essentially "hang in the air" afterwards.

We are trying to find a solution that we can realistically do (and humanpower/worktime is part of the question here) without interrupting users too much. And as it stands, it would probably both interrupt our RTK users more, just as our "plain Redux package users" if we were to suddenly merge one into the other. (also the ensuing discussion would probably even be more heated than this one)
It is probably just too late to do that at this point.
But if you want to get us to do it, please contribute to the discussion in #4326 (keeping the history of #3321 in mind). And maybe offer a lot of your time, because we will need people doing that if we should really consider it.

[migueloller]

@phryneas, I feel you. Another alternative is to deprecate redux and make @reduxjs/* packages the official ones. I just wanted to say that even though we're arguing here about deprecation and semantics, that the end of the day, y'all the maintainers are what make this possible and you're within your rights to make absolutely whatever changes you want. We wouldn't have RTK or redux, without you guys. Just wanted to make sure I said that. Really appreciate you guys.

So, what about merging redux into RTK? And then just stop upgrading redux after v8 and direct people to RTK? And perhaps the @reduxjs/core package can have createStore but by the time people move to @reduxjs/core they should already know and prefer to use RTK?

[mattpocock]

So, what about merging redux into RTK? And then just stop upgrading redux after v8 and direct people to RTK?

If this happens, where do the community of folks using redux go for help? Most likely to the same place they do now, to the Redux discord. They ask a question about the redux package, and they're directed to use @redux/core instead. In other words, the exact same flow as today. The "direct people to RTK" is a huge, manual, unpaid job.

I wonder if there would be a way to automate this to reduce the burden on maintainers? We'd need to add a visual indicator on the entry point of the redux package to catch users' eye. That indicator would link to an article explaining the issue in-depth.

The @deprecated flag is the way to automate this process, which your suggestion wouldn't do.

[migueloller]

@mattpocock, if redux itself is deprecated then that message can be added anywhere, createStore, NPM installs, etc. I apologize if I wasn't clear enough, but if redux was merged into RTK and stopped being upgraded then it should indeed be deprecated and people directed to its new home (i.e., @reduxjs/core or whatever new name the package has).

[mattpocock]

@migueloller And what the others have said is that's an enormous job - moving the documentation around and refactoring the monorepo's. Adding a deprecation notice on createStore achieves the same thing with less effort - and is also reversible.

[migueloller]

I'm not suggesting a monorepo refactor, but simply deprecating all of redux instead of just createStore and then adding 1 new monorepo package @reduxjs/redux (or some other name like @reduxjs/core) that is where the new core lives. The old Redux docs can stay up with a big banner pointing to RTK and the deprecation notices of redux can point to RTK and this way there's no manual work to direct people there. The repo for redux can be kept up but archived in GitHub with a notice in the README to go to the new package that lives in the RTK org, etc. The old legacy docs can also be kept up, but again just have a big banner directing people to RTK.

Anyhow, it's just an idea/suggestion. It doesn't have to be this way. I'm just trying to propose something that would achieve the maintainers' goals (deprecate core Redux so that people use RTK instead without having to do tons of work merging RTK into Redux or refactoring monorepos). I'm probably missing something since I'm not a maintainer, so I'll let the maintainers decide whether my suggestion/idea is useful or not.

[Methuselah96]

@migueloller And what the others have said is that's an enormous job - moving the documentation around and refactoring the monorepo's. Adding a deprecation notice on createStore achieves the same thing with less effort - and is also reversible.

It doesn't quite achieve the same thing. In my mind, having the two separate is causing a lot of the confusion and I feel like combining the two (even just in a monorepo and not the same package) would allow the messaging to be a lot more clear. For example, I think one website instead of two would make it a lot easier to communicate how to use Redux today.

I'm not trying to say deprecating createStore isn't the right next step, I just feel like we'll always fall short unless we just bite the bullet and do the work of putting the two packages in the same monorepo and having the documentation centralized on one website with clear messaging.

[phryneas]

Well, for what it's worth, @reduxjs/toolkit already re-exports everything from the redux package, so there will probably never be an installation that has both RTK and plain Redux in their package.json or imports from both.

[Methuselah96]

Personally I think package renames, with a monorepo and single website, are the best way to go:

redux -> @reduxjs/core
@reduxjs/toolkit -> @reduxjs/redux

This would include a migration guide that explains that @reduxjs/redux is the main package and @reduxjs/core is just for advanced and legacy usage. The new combined website would consistently teach/use @reduxjs/redux throughout and @reduxjs/core documentation would be confined to its own section.

This is obviously more work, but in mind way it's the best way to message how the maintainers feel about the current status of how these packages should be taught and used.

[markerikson]

On mobile and at a conference atm, but this is exactly the point I tried to make earlier.

Truly deprecating the entire Redux core package is an option. So is moving all of RTK into the core package. But it really would require converting everything to a monorepo as part of that. That is a massive amount of work that we simply do not have the time or energy to do. Additionally, there's package whiplash. We already renamed RTK once. Our docs say to use it. I do not want to further confuse users by telling them to switch packages from RTK back to a combined "Redux" package.

I am really, truly, trying to do the thing that will have the LEAST POSSIBLE DISRUPTION FOR ALL OUR USERS, and also not require hundreds of additional hours of unpaid labor for us maintainers, that we don't have time for, with very little net benefit for anyone in the end.

And I don't understand why people are having a hard time accepting what I have repeatedly, clearly, and plainly stated about my motivations, intent, and constraints here.

[markerikson]

@zdhr

Words have meaning. Deprecated means something will be sooner or later gone. Yet you stated multiple times you have no intention of removing it. So basically you'd be lying. That just feels wrong.

No. I quoted the definition of "deprecated" from Wikipedia. Deprecation does not always imply "removal". You're ignoring the plain statement I have made repeatedly about what I intend to do here.

RTK isn't the only thing out there that is using redux. Why it should have extra privileges?

Because we are the maintainers. We have spent thousands of hours writing documentation, responding to issues, answering question, fixing bugs, adding features. We have seen how people use Redux and what problems they run into.

Quite frankly, you have not.

Therefore, it's our responsibility to make decisions about how the libraries should evolve, based on what we think is going to result in the best experience for our users and help them with the things they're trying to build.

It's really the story of the Little Red Hen. "If no one else is going to help me with this, I'll do it myself".

We welcome input from the community. That's why I even filed this as an issue in the first place and asked for feedback. But at the end of the day it's our (unpaid! free time!) job to make the final decisions.

[markerikson]

Done. I've added the @deprecated tag to createStore, verified that it visually shows up with a strikethrough and the updated description tag in hover tooltips, and added a new legacy_createStore that is an alias of the same function with a different docblock.

This is now live in Redux 4.2.0:

https://github.com/reduxjs/redux/releases/tag/v4.2.0

[Methuselah96]

And I don't understand why people are having a hard time accepting what I have repeatedly, clearly, and plainly stated about my motivations, intent, and constraints here.

Yeah, deprecating createStore seems like the best option given your motivations, intent, and constraints. I just couldn't help talking about what the ideal seems like if the time constraint wasn't as restrictive. Congrats on getting this out.

[jamesisaac]

Because we are the maintainers. We have spent thousands of hours writing documentation, responding to issues, answering question, fixing bugs, adding features. We have seen how people use Redux and what problems they run into.

It doesn't really sound like "maintaining" when the course of action is effectively deprecating the original library, and replacing with a new high-level API. Surely there are people interested in actually maintaining the original, minimalistic Redux API, as conceived by Dan in 2015? Which is ultimately what originally gained huge traction, spawned a large ecosystem, and has acted as a solid foundation for countless projects over many years.

While you may feel all those people are wrong, and the new approach is superior, couldn't this have been more easily shown by having the Redux Toolkit library's proposed "single standard approach" exist as its own library wrapping Redux, letting the numbers and adoption speak for themselves? Why does it need to come at the expense of all those who are still happily using Redux's original low-level API?

Also, the presumption here that newcomers will pay attention to a deprecation notice, and "power users" can simply ignore it seems backwards to me. Newcomers are more likely to just follow whatever they see in their chosen tutorial, and be happy to have something that runs. Whereas experienced developers following best practices will be the ones who would not want to let a deprecated library call into their codebase.

[mattpocock]

@jamesisaac Have you read the thread above? Your various proposals have been answered. The library itself is not being removed or left unmaintained. How would you propose dealing with the issues faced by the current maintainers?

Surely there are people interested in actually maintaining the original, minimalistic Redux API, as conceived by Dan in 2015?

This feels deeply unfair to Mark and Lenz - they are the reason for Redux's continued relevance and prosperity.

[phryneas]

@jamesisaac "maintainer" simply means "the people in charge". Some libraries call their team "team", other libraries call their team "maintainers", it's the same thing. Riding on that word is a horrible take.

By the same logic, the React maintainers would not have been allowed to add ES6 classes, or hooks at a later time, because React with React.createClass was perfectly fine and their whole job was to keep the first api someone had invented alive - no matter how unergonomic it is by modern standards. And yes, createStore is horribly unergonomic compared to configureStore, which is it's successor.

Also, you are free to fork Redux. Just don't assume you will have a lot of success - there are already 15000 redux-named packages on npm.

Or just stay on the last version without the deprecation note. The Redux core is essentially done - those low-level apis are very unlikely to see any more changes, simply because after 7 years it is unlikely that anyone will come up with a newly found bug. (And remember, by your definition other than fixing bugs, there are no changes allowed.)

[jamesisaac]

@mattpocock Yes, I've read the whole thread. Where did I say the library was being removed/unmaintained? I said that a deprecation warning is hard for an experienced developer to ignore. Regardless of what the docblock says, many would see it as a red flag to have any deprecated library calls in a codebase.

This feels deeply unfair to Mark and Lenz - they are the reason for Redux's continued relevance and prosperity.

How are you determining this? If the problem is that too many people are still being introduced to Redux on the original API, doesn't that indicate the original unopinionated API is responsible for a lot of the relevance and prosperity?

@jamesisaac "maintainer" simply means "the people in charge". Some libraries call their team "team", other libraries call their team "maintainers", it's the same thing. Riding on that word is a horrible take.

Perhaps there is some relevance behind the word, particularly in a library which is used as a foundation in so many projects (2.1 million according to the stats GitHub pulls together).

By the same logic, the React maintainers would not have been allowed to add ES6 classes, or hooks at a later time, because React with React.createClass was perfectly fine and their whole job was to keep the first api someone had invented alive.

IMO this is not a reasonable comparison, as React.createClass purely existed as a workaround for lack of ES6 support..? It would be more like React deprecating React.createElement (the low level API which is wrapped by higher-level APIs). When in reality that is still perfectly usable and documented, and so are class components. Hooks and functional components have grown in adoption organically, without the React team needing to introduce deprecations.

Also, you are free to fork Redux. Just don't assume you will have a lot of success - there are already 15000 redux-named packages on npm.

I'm just sharing my opinion on the redux NPM package, as that's what I've incorporated into many projects since 2015. I'm aware that a fork is a viable solution, but obviously it's more disruptive than redux continuing to work with the same API it always has, without throwing out deprecation warnings.

Or just stay on the last version without the deprecation note. The Redux core is essentially done - those low-level apis are very unlikely to see any more changes, simply because after 7 years it is unlikely that anyone will come up with a newly found bug. (And remember, by your definition other than fixing bugs, there are no changes allowed.)

I mean that was pretty much my stance, that "Redux core is essentially done", barring the occasional bug fix or tweak in underlying implementation. So I'm voicing the side of those who would find it useful to continue to use it that way without pinning to an old unmaintained version of the package.

[phryneas]

Perhaps there is some relevance behind the word, particularly in a library which is used as a foundation in so many projects (2.1 million according to the stats GitHub pulls together).

The only people giving that word any relevance are the intentions of the people calling themselves by that word. We could also just reference as ourselves as "team" from tomorrow on, it would not change how we work.

I mean that was pretty much my stance, that "Redux core is essentially done", barring the occasional bug fix or tweak in underlying implementation. So I'm voicing the side of those who would find it useful to continue to use it that way without pinning to an old unmaintained version of the package.

The solution to that is, as per the release notes, the following change at one line in your application:

- import { createStore } from 'redux';
+ import { legacy_createStore as createStore } from 'redux';

You don't need to pin anything at all. It's just an option, if the above change seems too intrusive for you.

[phryneas]

How are you determining this? If the problem is that too many people are still being introduced to Redux on the original API, doesn't that indicate the original unopinionated API is responsible for a lot of the relevance and prosperity?

Following-up on that one:

The number of threads on twitter/reddit/hackernews saying "Redux is horrible" has decreased significantly while the number of threads saying "I like Redux again because of Redux Toolkit" has increased greatly. Fewer posts about "migrating away from the horrible boilerplate of Redux" are being written, or people are commenting under them that the author should really check out Redux Toolkit before daming the library.

In the last few years, a lot of people have voiced very loudly that they hate Redux. Those voices have gotten a lot less, both in frequency and volume. Without our efforts working on Redux Toolkit, Redux would likely not be a tool that newcomers would still learn because of the perceived notion that it is outdated and should not be used nowadays. It would probably be an irrelevant legacy tool, given one or two more years.

[jamesisaac]

The only people giving that word any relevance are the intentions of the people calling themselves by that word. We could also just reference as ourselves as "team" from tomorrow on, it would not change how we work.

Ok, but then the point in my original comment still stands, that it would be helpful to let someone maintain (actual usage of the word) the low-level Redux API, while the "team" who wants to build out Redux Toolkit continues to do so. They seem to be complementary libraries serving different use-cases.

Question on the new API - what are the solutions it provides for persistence (my main use-case for Redux)? A quick search through your docs and all the examples seem to use the createStore API: https://redux.js.org/introduction/ecosystem#persistence

The solution to that is, as per the release notes, the following change at one line in your application:

IMO a legacy_ prefix is essentially the same as deprecating it. Ultimately if someone is contracting me to build greenfield software for them, I would not import a library prefixing itself with legacy_ - the writing would clearly be on the wall that is not a future-proof solution, so it would be excluded for my options.

[phryneas]

Question on the new API - what are the solutions it provides for persistence (my main use-case for Redux)? A quick search through your docs and all the examples seem to use the createStore API: redux.js.org/introduction/ecosystem#persistence

You can use redux-persist just as you did before. As redux-persist has been unmaintained for quite some time, it unfortunately still uses symbols as action types and you will get warnings about that with the serializability middleware enabled in development environments. The Redux Toolkit documentation describes how to exclude redux-persist from that warning in the Usage Guide until they put out a release fixing that (development on their side has begun again under a new maintainer).

[phryneas]

IMO a legacy_ prefix is essentially the same as deprecating it. Ultimately if someone is contracting me to build greenfield software for them, I would not import a library prefixing itself with legacy_ - the writing would clearly be on the wall that is not a future-proof solution, so it would be excluded for my options.

Yes, if you start a new greenfield application using an api that has been superseeded for three years, requires four times the amount of code and is much more susceptible to bugs, that writing should probably be on all walls.

[jamesisaac]

The number of threads on twitter/reddit/hackernews saying "Redux is horrible" has decreased significantly while the number of threads saying "I like Redux again because of Redux Toolkit" has increased greatly.

I do know the type of discussions you're talking about here, but IMO this is the vocal minority. I imagine there are many developers who have been happily building on Redux for a long time, who don't spend their time getting involved in beginners' discussions about "is Redux is still worth learning or not?".

Personally I've revisited the Redux docs occasionally, read through the docs for RTK in the past, and decided it doesn't provide additional utility to me over base Redux. If I realised the eventual plan was to make it the only viable option, maybe I would have been more vocal earlier about how base Redux has served me perfectly since day 1.

Yes, if you start a new greenfield application using an api that has been superseeded for three years, requires four times the amount of code and is much more susceptible to bugs, that writing should probably be on all walls.

Pairing it with a type system, I've had precisely zero of these problems. I've had another look over the RTK docs and to me it is just additional APIs, re-solving problems that were already solved by following best practices or combining other complementary libraries (which has the benefits of those solutions being applicable to a wider domain than just reducers). I do not see any way it would lead to reduction of verbosity or bugs for my usage patterns.

I completely see your point that for a newcomer, jumping into RTK may be preferable. But my general point is that, Redux served its role extremely well as a low-level library, and it's nice having options available, with both solutions coexisting in parallel - which it doesn't seem there would be a barrier to. If "Redux core is essentially done", and people are writing all over forums "I like Redux again because of Redux Toolkit", then it sounds like RTK would become the preferred solution organically, without needing to be at the expense of deprecating a low-level tool, which has no actual deficiency, has a wide ecosystem, and many are productively using.

[phryneas]

sigh honestly:

If you yourself are educated enough that you decide for yourself not to follow the officially recommended best practices that the Redux team is propagating in the documentation and the Redux Style Guide because you know better, you surely are also educated enough that you can read and understand the deprecation warning, which contains the information that the api itself is not going away and make the conscious decision to ignore the deprecation warning in the same way as you are ignoring the style guide.

Ignoring one is the sameas ignoring the other. Both are an extremely clear "writing on the wall". It's your choice. Please stop complaining that you don't like one puzzle piece of that "writing on the wall". The decision has been made, the deprecation warning has been shipped, we are not going to take it back.

[markerikson]

This conversation is going in circles. All the points have been made, the release is already shipped, and further arguing isn't going to change things.