Add opt-out - with deprecation warnings - to the bans on getState, subscription Handling and dispatch in the reducers #3444
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Its not always easy to convert legacy code you may not even have written yourself, and as long as the continued acceptance of these antipatterns doesnt hurt other efforts I'd suggest the option for an opt-out of these bans, so that we dont force people to use older versions just because they feel like theres higher priorities than just completely revamping their applications state management right now.
This brings no breaking changes and the 'options' object may be expanded to allow for further configuration in the future. The documentation is riddled with warnings, and a console.error is set off every time a store gets created with one of these bans lifted. @timdorr this should COMPLETELY satisfy your apparent need to remove this behavior, as long as you dont provide a better reason I can accept or everyone else tells me they dont want to enable other people with legacy code to use the new features of Redux 4, just because these people think that using these functions in the reducer, while very bad, isnt the worst issue their app has currently and doesnt legitimize immediate complete workover of their potentially huge application.
This options object has been purposefully coded in a way that allows for expansion in the future, thus this does NOT prevent future expansions of arguments. I'd reccomend putting these in that options-object, as theyre unlikely to get used frequently and in that way - because of the non-sequential nature of the object-parameters - dont worsen the already bad situation currently where you have a headache with allowing different configurations without horrible syntax like passing in multiple
undefined
.If this gets accepted and people are interested in that I might bring another merge request later which would allow a 3rd parameter in reducers which is passed the global state - thats also mentioned in the issue #1568 mentioned by @timdorr, the thing is THATS CURRENTLY INCOMPATIBLE WITH YOUR OWN COMBINEREDUCERS - allowing for in-pattern usage of the global state without having to revert to store.getState, which makes store-injection in testing very hard. This too would not break normal usage of redux, and when you use object destructuring in the argument to limit the scope of parameters you inject from the global state it also shouldnt lead to a to large state potentially influencing the reducer.