Redux createStore() is deprecated - Cannot get state from getState() in Redux action
Asked Answered
S

7

58

So, the createStore() Redux is now deprecated and configureStore() is recommended from @reduxjs/toolkit.

I'm pretty sure it's related to not being able to get userInfo state using getState() in my actions.

getState() of userLogin returns undefined. But when I remove getState(), the action works.

STORE:

import { configureStore } from '@reduxjs/toolkit'
import thunk from 'redux-thunk'
import {
  productAddReducer,
  productDeleteReducer,
  productDetailsReducer,
  productListReducer,
  productUpdateReducer,
} from './reducers/productReducers'
import { composeWithDevTools } from 'redux-devtools-extension'
import {
  userLoginReducer,
  userRegisterReducer,
  userDetailsReducer,
  userListReducer,
  userDeleteReducer,
  userUpdateReducer,
} from './reducers/userReducers'

const reducer = {
  // User
  userLogin: userLoginReducer,
  userRegister: userRegisterReducer,
  userDetails: userDetailsReducer,
  userList: userListReducer,
  userDelete: userDeleteReducer,
  userUpdate: userUpdateReducer,
  // Product
  productAdd: productAddReducer,
  productList: productListReducer,
  productDetails: productDetailsReducer,
  productUpdate: productUpdateReducer,
  productDelete: productDeleteReducer,
}

const userInfoFromStorage = localStorage.getItem('userInfo')
  ? JSON.parse(localStorage.getItem('userInfo'))
  : null

const preLoadedState = {
  userLogin: { userInfo: userInfoFromStorage },
}

const middleware = [thunk]

const store = configureStore({
  reducer,
  preLoadedState,
  middleware,
})

export default store

ACTION:

import axios from 'axios'
import {
  PRODUCT_ADD_FAIL,
  PRODUCT_ADD_REQUEST,
  PRODUCT_ADD_SUCCESS,
  PRODUCT_DELETE_FAIL,
  PRODUCT_DELETE_REQUEST,
  PRODUCT_DELETE_SUCCESS,
  PRODUCT_DETAILS_FAIL,
  PRODUCT_DETAILS_REQUEST,
  PRODUCT_DETAILS_SUCCESS,
  PRODUCT_LIST_FAIL,
  PRODUCT_LIST_REQUEST,
  PRODUCT_LIST_SUCCESS,
  PRODUCT_UPDATE_FAIL,
  PRODUCT_UPDATE_REQUEST,
  PRODUCT_UPDATE_SUCCESS,
} from '../constants/productConstants'

export const addProduct = product => async (dispatch, getState) => {
  try {
    dispatch({ type: PRODUCT_ADD_REQUEST })

    const {
      userLogin: { userInfo },
    } = getState()

// USER INFO IS 'UNDEFINED' - ERROR: CANNOT READ PROPERTY OF DATA
// ACTION WORKS WHEN REMOVING USERINFO FROM THE ACTION

    const config = {
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${userInfo.token}`,
      },
    }

    const { data } = await axios.post('/product', product, config)

    dispatch({
      type: PRODUCT_ADD_SUCCESS,
      payload: data,
    })
  } catch (error) {
    dispatch({
      type: PRODUCT_ADD_FAIL,
      payload:
        error.message && error.response.data.message
          ? error.response.data.message
          : error.message,
    })
  }
}

export const listProducts = () => async dispatch => {
  try {
    dispatch({ type: PRODUCT_LIST_REQUEST })

    const { data } = await axios.get('/product')

    dispatch({
      type: PRODUCT_LIST_SUCCESS,
      payload: data,
    })
  } catch (error) {
    dispatch({
      type: PRODUCT_LIST_FAIL,
      payload:
        error.message && error.response.data.message
          ? error.response.data.message
          : error.message,
    })
  }
}

export const listProductDetails = id => async dispatch => {
  try {
    dispatch({ type: PRODUCT_DETAILS_REQUEST })

    const { data } = await axios.get(`/product/${id}`)

    dispatch({
      type: PRODUCT_DETAILS_SUCCESS,
      payload: data,
    })
  } catch (error) {
    dispatch({
      type: PRODUCT_DETAILS_FAIL,
      payload:
        error.message && error.response.data.message
          ? error.response.data.message
          : error.message,
    })
  }
}

export const updateProduct = product => async (dispatch, getState) => {
  try {
    dispatch({ type: PRODUCT_UPDATE_REQUEST })

    const {
      userLogin: { userInfo },
    } = getState()

    const config = {
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${userInfo.token}`,
      },
    }

    const { data } = await axios.put(`/product/${product._id}`, product, config)

    dispatch({
      type: PRODUCT_UPDATE_SUCCESS,
      payload: data,
    })
  } catch (error) {
    dispatch({
      type: PRODUCT_UPDATE_FAIL,
      payload:
        error.message && error.response.data.message
          ? error.response.data.message
          : error.message,
    })
  }
}

export const deleteProduct = id => async (dispatch, getState) => {
  try {
    dispatch({ type: PRODUCT_DELETE_REQUEST })

    const {
      userLogin: { userInfo },
    } = getState()

    const config = {
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${userInfo.token}`,
      },
    }

    const { data } = await axios.delete(`/product/${id}`, config)

    dispatch({
      type: PRODUCT_DELETE_SUCCESS,
      payload: data,
    })
  } catch (error) {
    dispatch({
      type: PRODUCT_DELETE_FAIL,
      payload:
        error.message && error.response.data.message
          ? error.response.data.message
          : error.message,
    })
  }
}
Salmagundi answered 20/4, 2022 at 17:52 Comment(2)
This post does not seem to ask a question.Vickyvico
@Vickyvico this post was used as an audit (which I failed), but I agree with you. It's not a good question or a real one.Culinary
H
213

I'm a Redux maintainer, and the person who added that "createStore is deprecated" message :)

For the record this has nothing to do with your actual application code. It is specifically a message to users like you who are using "plain Redux" - it's trying to tell you that you're following patterns that are much harder to use, and we want you to use Redux Toolkit instead because it will make your life much easier :)

You'll note that this isn't even a runtime warning being printed in the console - it's literally just a visual indicator in your editor, like createStore.

Please see these Redux docs pages for more details on why we want people using Redux Toolkit to write Redux code, and how to do so:

Habited answered 20/4, 2022 at 23:16 Comment(56)
Thank you for your response, Mark and Emile. I created a test app for the purpose of learning Redux toolkit. I started by making the counter. Then I connected a backend and db and I am making axios requests from the reducer. I've been successful to a degree and wondering if you can provide any docs or videos on more advanced redux toolkit functionality such as sending requests to the backend etc?Salmagundi
Yes, the "Essentials" tutorial I linked in my answer specifically goes over all of the features in Redux Toolkit, including how to handle data fetching. Also, note that in Redux, a reducer may never make async requests of any kind! That needs to be outside the reducer - usually in a "thunk" function.Habited
@Habited if I understand your comment correctly the idea behind the deprecation of createStore is only to inform « plain redux » users that RTK exist, meaning you will not delete createStore in a future major version?Reservoir
Correct. We are not going to break actual working code. Even though the rules of semver would give us license to actually make real breaking changes in a major version, we are not going to remove the createStore API. However, per the linked post, we want everyone to stop using createStore, and switch to using configureStore (and the rest of Redux Toolkit) instead. Thus the attempt to nudge people and let them know that RTK exists.Habited
@Habited with RTK, do we still need to use redux-thunk, and import applyMiddleware from redux?Octad
@Habited Please, please, please, don't use deprecation messages as SPAM. I understand you think reduxtoolkit is better, but that is your opinion. There's a lot I like about the createSlice pattern, and I wouldn't mind that being part of redux or existing on its own, but I do not want many of the stuff it comes with, and I definitely not want my mutable code magically transformed into immutable operations.Hialeah
@Guy : it's "marketing" in the sense that "we want people to read this and learn about RTK", sure. But that's literally the point of "deprecation" in the first place: the people who make a tool telling the people that use the tool "stop using it this way, that's not how it should be used anymore". This has been true for every framework and every language. For example, Java has had a similar @deprecated attribute for years: docs.oracle.com/javase/8/docs/api/java/lang/Deprecated.html . That's literally the whole point of it in the first place :)Habited
@Guy : We also want existing Redux devs to use RTK, because we want every Redux dev to use RTK. But yes, there is a small but somewhat vocal minority of users who only want to use the Redux core by itself, and don't like RTK for various reasons. That's why this is a "deprecation", and not a major version that actually removes createStore - we're not going to break working code. But as maintainers, it's our job to point people to the approach we feel works best for using Redux, and that's RTK.Habited
I also would like to express my discontent about this disuse of a depreciation message.Whitehead
@Whitehead : Please read the linked article. This is not a "disuse of a deprecation message". This is an intentional notification to our users that there is a better way to write Redux code, same as any other library that marks some API as deprecated.Habited
this message really a mistake, it make programmers get confused. hope you revise yourself.Marrilee
@Habited we use redux for managing a few middlewares with our routing library (found) and do not use any redux APIs directly. It doesn't make sense for us to add a new dependency and extra bytes to avoid this warning. I am happy to ignore the warning but this really shouldn't be removed. It needs to be possible to use base redux without deps.Hearty
@monastic-panic: please read the linked articles and release notes - we are not going to actually remove createStore! and there is no runtime warning - just a visual strikethrough in your editor when you import. However, yes, we want everyone to be using RTK, or at the very worst, acknowledge that RTK exists and make an informed choice that you still wish to stick with legacy Redux code.Habited
I did read them, i understand it's not going to get removed, what is frustrating folks is that "deprecated" almost always means "will be removed" and so they have to go google around to understand the risk of ignoring a warning that means "Must fix" for most code. e.g. i had to spend a some time finding this SO thread in order to understand it is safe to disable the build warnings we have complaining about deprecated code.Hearty
In any case i popped in not to complain and take up your time, but to raise an additional use case for redux as part of other tools and so the message is confusing/misleading. Having read the linked articles i still think it would be a mistake to use RTK for our cases and that's fineHearty
This "deprecation" cost my team an hour today, and we're not going to use RTK because we already handled composing reducers and middlewares. This caused confusion in our team, and if you're not actually removing createStore from the API, it is unnecessary confusion. My opinion is that the right thing to do is removing the deprecation and adding notes to the documentation instead.Robbie
@Robbie : sorry to hear that your team was confused, but the linked doc page clearly explains why we did this and why we want people to use RTK instead. Note that it's not just about configureStore - it's also createSlice for simpler reducers and generating action creators, RTK Query for data fetching, and the other APIs included in RTK that make Redux usage better. (Note that we could have published a major that actually did remove createStore, but we didn't because we care about not breaking running code - thus the deprecation to give users notice that RTK exists.)Habited
Another person chiming in to say that using deprecation warnings this way seems like a mistakeConductivity
@robbie_c: could you explain your thoughts further? I honestly don't understand this train of thought. Would folks have preferred that we actually remove createStore in the next major version (which would of course break working code)? The approach we took definitely fits the definition of "deprecated": "discouraging 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".Habited
The approach I would have taken: keep the redux library as is, but make sure that all documentation makes it clear that rtk is the recommended way to create new applications. It sounds like this was already done, so no further action needed.Conductivity
Changing the function name breaks semver, we bumped up a minor version (I believe 4.1.2 to 4.2.0) and due to createStore -> legacy_createStore, needed to do some unexpected work fixing this. To be clear, under semver, package maintainers are meant to keep forwards compatibility across minor version changes. If this is accidentally broken, the maintainers are meant to publish a patch version ASAP which fixes it.Conductivity
See "What do I do if I accidentally release a backwards incompatible change as a minor version?" here semver.orgConductivity
Of course the actual fix was trivial, but it still requires time and effort to understand the reasoning ("is it important that we actually change this soon? oh it turns out that it's just guidance for new projects, grumble")Conductivity
(note: I said the "fixed" version that reverts the name createStore -> legacy_createStore should be a patch version, semver recommends it be a minor version, :shrug: less strong feelings there. I also appreciate it was't accidental, but the link is just intended to be an example of what to do in a similar situation)Conductivity
Fundamentally, deprecating something is intentionally causing pain to your users. Usually this is for a good reason, e.g. because they will NEED to change how they use your code soon, and it's better for them if they adapt now rathern than later. This wasn't the case here, my understanding is that the redux team are not really suggesting that maintainers of pre-2019 codebases NEED to port their code to RTK, it's just a suggestion that they could consider it, and it's strongly recommended to use rtk for new projects.Conductivity
@Conductivity : fwiw, I very intentionally made sure that the "deprecation" only amounted to adding a @deprecated tag, which results in a visual strikethrough in an editor. No runtime warning. Existing code continues to run exactly as-is, no changes, and thus no semver breakage at all. In that sense, you didn't even have to "fix" anything - you could have left your code untouched and nothing would break. However, we absolutely want all Redux users using RTK! This was the only way we could reach out to many users who never look at our docs. (All clearly stated in the links)Habited
Apologies, I was wrong about semverConductivity
@Habited If you want all users to use RTK you should provide an API and a set of tools that is as elegant, rich, testable as the method offered by combining saga and typesafe-actions. You can't say "it's deprecated, but nothing will break". You either state that we need to schedule a full refactoring or you state the opposite.Periphrastic
@DavideValdo : I'm... honestly not sure what you're saying there. The point of RTK has always been that you can use as much or as little as you want, and that you can either use it starting day 1 in a new Redux project or incrementally migrate an existing project. It's not an all-or-nothing proposition. Can you clarify what you mean by the "provide an API and set of tools" sentence? I don't know what you're trying to describe there. (We did recently add a "listener middleware" to RTK that's designed to replace most saga usages: redux-toolkit.js.org/api/createListenerMiddleware )Habited
Most of all, I would be practically missing these patterns: redux-saga.js.org/docs/advanced/Channels. I'm guessing RTK Query might be the answer to my concern, but seems very different and hard to refactor starting from saga channels.Periphrastic
Yeah, the listener middleware was designed to do 80-90% of what sagas can do, in terms of responding to actions, running side effects, and even forking off "child tasks"... but channels are something we explicitly opted to not implement. if you're using those, sagas are actually a useful tool.Habited
Yeah I have a lot of code built upon the native Firebase SDK, which already handles caching quite comfortably.Periphrastic
redux.js.org/api/createstore should explain the deprecation. It doesn't mention it and doesn't mention Redux Toolkit.Lotte
@DanielDarabos good point! Just filed github.com/reduxjs/redux/issues/4546 to cover this, and will try to get to it in the near future.Habited
I'm also here to express my strong discontent with deprecating createStore. One of the main appeal of react and redux was that it lends itself well to functional programming, and the enforced RTK alternative does the exact opposite. It doesn't follow the original philosophy of redux, it's more like a createReactApp for redux. If you want to advertise RTK, put it on the github and npm pages, not a cryptic deprecation. And if you want to force on people only using RTK with redux, go ask the owner to change the license. This isn't in the spirit of MIT license.Sickert
@Sickert : I have to completely disagree with you on all levels. RTK is still Redux. You're still doing "functional programming". You're still creating a single store, and writing reducers with immutable updates. There's just less code to do both. Also, we maintain all of the Redux libraries together. We are the owners. I have personally published all of the recent Redux, React-Redux, Redux-Thunk, and RTK package versions. You can still use createStore if you want. But we strongly believe RTK is the best way to write Redux code and want you to use it.Habited
@Habited I'm not doing functional programming when I'm forced to use Immer as part of RTK. Also, you may believe that RTK is the best way to write redux code for your code, but judging by the backlash and my personal experience, it is not the best in a general case, so your belief may be a bit blind. The whole philosophy of redux was that it's just a one part of many, a simple functioning lib. RTK on the other hand is not that, it makes too many decisions for me. I don't want Immer, I want to use ramda. RTK just plain isn't able to do that.Sickert
@Sickert : fwiw, the people complaining in this thread and a couple of our issues, despite the vocalness, are a tiny minority. We get highly positive comments daily on how much people love using RTK, and love using Immer. So, yes, from that feedback I can safely say that RTK is the best way to write Redux code. If you choose not to use it, that's your decision. But as I've said, our job is to teach people what we firmly believe is the best approach, and that includes pointing out that hand-written Redux is not what we think they should be using.Habited
@Habited I just found that createStore is deprecated, went looking on to why and found this thread. If something is DEPRECATED, it WILL BE REMOVED in future versions. Do not use deprecation flag as advertisement. That's just wrong. I use saga, can't refactor to RTK. As others said, put up a banner on your github repo, NOT IN DEPRECATION NOTICES. That's like if your coffee roaster would say "WARNING: Your favorite coffee is deprecated. Drink that one. It tastes different, you don't like it and you have to buy new machine for it, but we'll bombard you with WARNING again until you do. DO IT!"Garibay
@DaliborFilus : as I've said repeatedly: "deprecation" does not mean removal. See my much longer answer at github.com/reduxjs/redux/discussions/… . And again: all that changed was a visual strikethrough in the import. That's all. Also: you can use sagas with RTK. You can use any middleware with RTK and configureStore, because it's still Redux! Please read all the links I posted in that answer to understand what RTK really is and how to use it.Habited
@kca : we released Redux 4.2.0 a year ago, with a very clear update notice. We don't control your build pipeline or how strict your lint checks are. In this case, the deprecation notice is indeed doing its job and letting you know that RTK exists and that we want you to use it. As mentioned, how you decide to handle that is now up to you.Habited
My recommendation is to fork React and remove this deprecation notice. That way, where React is being use in the enterprise, we can pass our audits instead of having to constantly explain the quality team why this really isn't a quality warning.Cush
@Cush : first, it's Redux, not React :) Second, you're welcome to fork Redux (it's MIT), but it'd be pretty silly to do so. Third, per all the discussions and release notes: the right answer is to switch to RTK's configureStore by following our migration guide: redux.js.org/usage/… . And finally, if for some reason you really don't want to use RTK, the 1-line "fix' is to import { legacy_createStore } instead and use that (also pointed out in the release notes!).Habited
Thanks mark. We'll consider forking Redux instead. The issue is that Redux Toolkit is not a new version of Redux. Redux is a separate, otherwise Redux Toolkit would simply be subsumed by by Redux and releases as the new version of Redux. Certainly major changes to APIs are not uncommon in software, and this will be acceptable. The deprecation warning in one product that point to another is what's causing the issues. We'll make the proposal internally and see how it goes.Cush
@Cush you seem to have missed what I said :) First, literally nothing about Redux actually changed. Nothing is breaking. Nothing is erroring. There is just a visual strikethrough because of the @deprecated tag. Second, per the release notes that I've mentioned, literally all you have to do to ignore this is change from import { createStore } to import { legacy_createStore }. Same function. No @deprecated tag. That's it. No need to fork. (And there's no "points to another" here.) Please read the release notes!: github.com/reduxjs/redux/releases/tag/v4.2.0Habited
Having to explain why depracation warning is being disabled will be confusing. Using legacy_createStore() may be a better option. Using legacy_createStore is the only way to now use Redux now which makes Redux itself legacy. That's what I'm going to say, and that Redux Toolkit is now required to use Redux. It would have been much better if Redux simply included RTK. None of this would have been an issue for us in that case. Or, officially state that Redux is in maintenance only and everyone should migrate to RTK. That would have also been much less confusing.Cush
@Cush Um.... MARKING createStore AS DEPRECATED IS LITERALLY TRYING TO TELL EVERYONE TO MOVE TO RTK! :) Like, that's the entire point of all this in the first place. And we said that, in the 4.2.0 release notes, in redux.js.org/introduction/why-rtk-is-redux-today , and redux.js.org/usage/migrating-to-modern-redux , and redux.js.org/tutorials/fundamentals/part-8-modern-redux . "Making Redux itself legacy": YES, that's what I'm trying to tell you :)Habited
the flip side: there are people who do not like the idea of RTK. Unfortunate, but true. We did debate whether we could just move all the RTK APIs into the redux core package, and decided early on that there were too many social and technical issues involved to choose that option: github.com/reduxjs/redux/issues/3321Habited
@Habited put a banner up on Redux front page that Redux is now only a maintenance project and people should move to Redux RTK, similar to angularjs. Or something similar so educators stop teaching Redux. Also with regard to the conversation in issue 3321, had you indicated that Redux would be modified to spit out warnings, the conversation may have gone in a different direction. I also would have said keep Redux and add Redux Toolkit separate because I would not have imagined that Redux would be crippled in the way it was done.Cush
"Redux" as a concept is still the same: a single store, updated immutably, triggered by dispatching actions. That hasn't changed, so there's no need for a banner. The preferred syntax for that is what's different. The docs have been updated to teach RTK as the default, and repeatedly explain why RTK is the default. If folks want to keep using the original core redux package, they can. As I've said repeatedly, we're not going to break working code. NOTHING IS "CRIPPLED". literally the only change is a @deprecated tag on createStore and a visual strikethrough.Habited
@Habited You're simultaneously trying to say that nothing has changed while also saying that Redux is now legacy. Which is funny, because that means this is either a highly innovative way to turn IDEs into a brand new marketing channel, or it means that RTK is now built on top of deprecated software, in which case I'd like to make a snark recommendation for RTK devs to start searching for a non-deprecated alternative for Redux. Redux going legacy should be all over the front page AND in the createStore annotation. Shrodinger deprecations or pipeline advertisements are not the way to do it.Sickert
@Sickert : that's actually what I'm saying. createStore still works. It's not broken. We don't want people using it because it's the outdated approach - we want them to use RTK and configureStore instead. We marked createStore as deprecated to notify people about this, in their IDE, where they see the code, because most people don't read our docs, and boot camps still teach outdated patterns. The concepts of "Redux" have not changed. I did this in the absolute least disruptive way possible, and yet folks are still yelling at me. Would y'all prefer I hard-deprecated it instead?Habited
We're about to release redux core 5.0. It will still have createStore. It will still work. It will still be marked @deprecated. By the rules of semver, I would be within my rights to delete the original createStore method as a breaking change in a major version. But I'm not going to do that, because that would break anyone who upgrades, or follows old tutorials. I'm trying to nudge people to use a better approach, while not breaking existing code. And instead I get yelled at for trying to improve the ecosystem and help our users. This is why maintainers burn out, folks.Habited
@Habited If you're worried about people using legacy redux and bootcamps still teaching obsolete practices then put the legacy message on the front page. As it is now with the deprecation only in the annotation, it looks like a bait and switch. That's why so many people are upset I believe. It looks like RTK is trying to milk the redux buzzword despite being a competitor with a very different design philosophy. It looks like when a company buys a competing brand and then sticks the purchased logo on their own products. It looks like a deception and people don't respond kindly to that.Sickert
@enry: I don't understand how it can be "milking" and a "buzzword" when we build and publish both libraries. It's not a "competitor" in that sense. I literally hit the publish button on every release, myself. I have been the primary maintainer of both libraries since 2016. How in the world can I be doing a "bait and switch" when I'm the one doing the work on both packages? Dan worked on Redux for 1 year. I've worked on everything Redux for 7+ years. I'm serious. How is me (and the other maintainers) saying "we've built a better version of Redux" deceptive?Habited
I will happily put a notice about "RTK is the right way to use Redux" on our docs home page. We've already got the existing intro page that literally says that exact same thing, and that I've linked repeatedly in this discussion, but I guess that isn't enough for you. My concern and point is that beginners don't read our docs in the first place, so most of the goal of the deprecation is to show them that something has changed, directly in their IDE.Habited
I
51

Also you can use import like this:

import { legacy_createStore as createStore } from 'redux';
Ignaz answered 5/7, 2022 at 7:42 Comment(1)
Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.Maeda
W
11

I was getting the same warning, and I did what VS code told me to do. I imported legacy_createStore.

import {legacy_createStore} from 'redux'

Or you can use an alias so that your code remains the same.

import {legacy_createStore as createStore} from 'redux'
Woadwaxen answered 4/2, 2023 at 7:27 Comment(0)
A
3

Guys I'm in 2023/07 and as of Redux >= version 4.0.0 , configureStore is the recommended way to create a Redux store using Redux Toolkit. Redux Toolkit's configureStore wraps around the original createStore method, and handles most of the store setup for us automatically, so initially install reduxjs/toolkit

npm install @reduxjs/toolkit

or if you are a yarn-er

yarn add @reduxjs/toolkit

and then where it's intended

import { configureStore } from '@reduxjs/toolkit';
import rootReducer from './reducers';

const store = configureStore({ reducer: rootReducer })

In my opinion less boilerplate code and just simplicity,and who wouldn't want that.

Audieaudience answered 27/7, 2023 at 23:4 Comment(0)
F
3

As a React Module

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

As a Node Module

const redux = require("redux");
const createStore = redux.legacy_createStore;
Fimbriate answered 20/10, 2023 at 20:8 Comment(0)
P
1
  • The createStore is deprecated. You are creating a redux store using vanilla Redux. This pattern is much harder to use. That's why the creator of redux wants us to use Redux Toolkit. You can create store using Redux toolkit very easily. From Redux Toolkit you can use configureStore which wraps around createStore API and handle the store setup automatically.

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

    for more detail ===> https://redux.js.org/tutorials/fundamentals/part-8-modern-redux

Prologue answered 12/9, 2022 at 5:20 Comment(0)
H
0

Add createStore as this below:

import { legacy_createStore as createStore } from 'redux';
Herr answered 28/2, 2024 at 15:15 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.