You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to suggest an update to the Redux documentation to define actions more concretely. Potentially it may make more semantic sense to replace the term "action" with "events".
The following is the current definition:
Actions are payloads of information that send data from your application to your store.
Due to this loose definition, the usage of the word "action", and the simple examples in the docs, most projects tend to use actions as instructions to update state. In my opinion, actions should have no implications of how the state of the application will change. It should be the exclusive responsibility of the reducer to do so. Instead, actions should be defined as important events that trigger reducers to update the state. How it updates though, should not be transparent from the action type string.
I say this not to be pedantic but because I believe that there are architectural benefits to be gained from this alternative ideology of what an action should represent. The following are the benefits I have noted so far.
Better use of component handlers: Component handlers will no longer need to dispatch and orchestrate multiple actions. Instead they can dispatch a single action represting the event and allow the different reducers to react accordingly. This is very beneficial as a component would have less insight on how state should change and is solely responsible for reporting the event (action) that occurred (Single Responsibility Theory).
Better use of side-effect handlers: Side-effect handlers will stop being used to merely dispatch more actions especially when no side-effect is present. (Due to reasons already mentioned in number 1)
Scaling With Ease: As existing business requirements are amended or expanded, the changes are isolated to the logic layer. The UI/Component layer will not need to be editted if there are no UI design changes.
Business Requirement Transparency: The reducer can now capture the entire business requirement if they are listening for events rather than instructions. For example,
The example reducer above transparently captures the "Increment score of the scoring team when a goal is scored" requirement.
I am aware some GitHub issues have already been opened related to this topic (#891, #797, etc). I just think that this may still be a topic of interest.
The text was updated successfully, but these errors were encountered:
Nope, not happening. This was settled years ago, and we're not changing it.
When we do get around to revamping the docs (see #3313 ), I intend to emphasize thinking of them in more "event" terms, but the name "action" isn't going to change.
I am happy with your answer. Amending the docs to emphasize thinking of actions in more event terms is great. I just thought that renaming them to "events" would send a straightforward message.
I would like to suggest an update to the Redux documentation to define actions more concretely. Potentially it may make more semantic sense to replace the term "action" with "events".
The following is the current definition:
Due to this loose definition, the usage of the word "action", and the simple examples in the docs, most projects tend to use actions as instructions to update state. In my opinion, actions should have no implications of how the state of the application will change. It should be the exclusive responsibility of the reducer to do so. Instead, actions should be defined as important events that trigger reducers to update the state. How it updates though, should not be transparent from the action type string.
I say this not to be pedantic but because I believe that there are architectural benefits to be gained from this alternative ideology of what an action should represent. The following are the benefits I have noted so far.
Better use of component handlers: Component handlers will no longer need to dispatch and orchestrate multiple actions. Instead they can dispatch a single action represting the event and allow the different reducers to react accordingly. This is very beneficial as a component would have less insight on how state should change and is solely responsible for reporting the event (action) that occurred (Single Responsibility Theory).
Better use of side-effect handlers: Side-effect handlers will stop being used to merely dispatch more actions especially when no side-effect is present. (Due to reasons already mentioned in number 1)
Scaling With Ease: As existing business requirements are amended or expanded, the changes are isolated to the logic layer. The UI/Component layer will not need to be editted if there are no UI design changes.
Business Requirement Transparency: The reducer can now capture the entire business requirement if they are listening for events rather than instructions. For example,
The example reducer above transparently captures the "Increment score of the scoring team when a goal is scored" requirement.
I am aware some GitHub issues have already been opened related to this topic (#891, #797, etc). I just think that this may still be a topic of interest.
The text was updated successfully, but these errors were encountered: