-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getDefaultMiddleware deprecated #1324
Comments
The reasons are:
Can you give a specific example of where and how you're using the export version? |
To give you some more context:
The flow goes like this:
Because of the size of the injected thunk arguments, I want to avoid doing it in step 1, if that makes sense 🙂 |
Hmm. I'm not clear on why you need to re-add the default middleware if you're using something like I would expect that those only need to be defined and added once, and then If you could put together some kind of a sandbox or something that demonstrates this, it would help me understand how this is supposed to behave. |
Because I want to set up the thunk middleware after creating the store (not immediately in What I can do as a workaround is to use the I'll try to prepare a sandbox. |
Yeah, that's part of what I don't understand. I can't see any reason to delay loading the thunk middleware, especially if you're modifying the list of middleware later. Oh. You did say something about injecting an API client. Mmm... what if you added the thunk middleware on startup, but gave it something like a And yeah, skipping the thunk middleware on startup and then creating it yourself later would also be an option. |
Yeah, the only reason is the stuff we're injecting as I agree this is not a common use case but having |
Agreed on both counts. I guess we could reconsider the deprecation. To be honest I really hadn't even thought about anyone needing or trying to create or modify middleware after store creation. |
But also encourages a big chunk of our users to use an api that gives them less type safety and hurts them in the long run. |
Also true, and the corollary to that argument is that RTK is meant for the "80% use case" and to push people towards "correct Redux usage". |
I agree with that by all means, I was just wondering why is it being deprecated and removed. Type safety is a good argument if there's nothing we can do to improve the original function. I'm sure there will be workarounds for cases like mine. Thank you for your time, I guess we can close this issue 🙌 |
What's the reason to deprecate and eventually remove this function? I was only able to find #958 (comment) as a reasoning. We're using it for dependency injection in thunks and due to code-splitting, we need to do it post store creation (using
redux-dynamic-middlewares
). I don't see any way to do this using the callback notation. Is there any chance of this function not being removed? Great job with the library, by the way, thank you!The text was updated successfully, but these errors were encountered: