Remove the need for base Action Creators to be thunks #2895
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.
Currently, two of our base action creators are thunks, the action creator for updating "ONE" resource and the action creator for updating "MANY" resources.
The reason that these are thunks are to support dynamic accessor properties on the api endpoint configs. Every time a ONE or MANY action is dispatched the
dispatch
function is passed as part of the action. The reducer then uses this reference todispatch
to attach a thunk withObject.defineProperty ... get
on the objects stored in the Redux store. The only reason that these dynamically generated functions are thunks are so they can "cross-cut" the Redux state at runtime.This is an anti-pattern for multiple reasons. Functions should not be stored in Redux, because Redux stage should be serializable. Also, the Redux store should be as flat as possible, acting as a database for components to aggregate data and map this data to declarative properties.
Refer to this Redux Issue for an extended discussion.
reduxjs/redux#749
This PR removes this pattern, these dynamic properties, and implements flat state access for
linode.type
andlinode.image
, which were the only two use cases.