If we took a class based approach to actions like we do with utility functions, then we could more easily override actions in child applications. Most of the time this doesn't matter for actions, but for some actions like runUrlConfig it would be helpful to be able to extend/customize that function in a child application.
Additionally, if we combined all of the actions into a single class, then we could have a default action class in the user space pre-populated to inherit from the _core action class (similar to our reducer setup) and all of our components could pull actions from there which means overriding the actions could be simpler. This would likely mean changing our mapDispatchToProps methods to favor specific functions instead of groups of functions like:
If we took a class based approach to actions like we do with utility functions, then we could more easily override actions in child applications. Most of the time this doesn't matter for actions, but for some actions like
runUrlConfig
it would be helpful to be able to extend/customize that function in a child application.Additionally, if we combined all of the actions into a single class, then we could have a default action class in the user space pre-populated to inherit from the _core action class (similar to our reducer setup) and all of our components could pull actions from there which means overriding the actions could be simpler. This would likely mean changing our
mapDispatchToProps
methods to favor specific functions instead of groups of functions like:instead of