Skip to content
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

Rename Actions to Events #3385

Closed
alaboudi opened this issue Mar 24, 2019 · 2 comments
Closed

Rename Actions to Events #3385

alaboudi opened this issue Mar 24, 2019 · 2 comments

Comments

@alaboudi
Copy link

alaboudi commented Mar 24, 2019

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.

  1. 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).

  2. 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)

  3. 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.

  4. Business Requirement Transparency: The reducer can now capture the entire business requirement if they are listening for events rather than instructions. For example,

INITIAL_STATE = {
  home: 0,
  away: 0
};

const scoreBoardReducer = (state=INITIAL_STATE, action) = > {
  switch(action.type) {
    'GOAL_SCORED': {
       return { ...state, [action.payload.team]: state[action.payload.team] + 1}
    }
  }
}

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.

@markerikson
Copy link
Contributor

markerikson commented Mar 24, 2019

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.

@alaboudi
Copy link
Author

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.

Thanks for the response @markerikson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants