Naming convention of events in redux js

Question

Redux will be dispatching actions for state change. What are naming conventions of action types in redux?

Answer 1

There are a few conventions around the community, I'll list the ones I know of and think are useful here:

1. The most common convention is to keep the action types ("event types") in CONSTANT_CASE.

   This avoids spelling errors, where the action has a type of my_type, but the reducer expects a type of my-type or My_Type.

2. Another very common convention is to save the action types in a separate file as constants, e.g. var MY_ACTION_TYPE = 'MY_ACTION_TYPE';, and to use them from there.

   This also avoids spelling errors, so you don't expect an action to have a type of MY_ACTION_TYP. If the variable doesn't exist, you'll get an error immediately, especially if you're linting.

3. A not quite as common, but imho very useful, convention is to scope the actions to a project and a domain. This approach was popularized by Erik Rasmussen in his "Ducks" proposal, which specifies that action types have to be in this shape: var MY_ACTION_TYPE = 'appname/domain/MY_ACTIONTYPE'.

   This avoids the case of two action constants having the same value. E.g. imagine you have a admin area and user facing area, and both have forms dispatching a 'CHANGE_USERNAME' action type. This will make two reducers pick up the same action, where one shouldn't pick the other one up. This can happen on accident, and is very annoying to track down. By prefixing them with the app- and domain name, one avoids this issue: 'appname/admin/CHANGE_USERNAME' is different from 'appname/user/CHANGE_USERNAME'!

That's all the conventions I know of and use, but I'm sure somebody else has more – what have you used and found useful in your projects?

Answer 2

There are also some conventions around naming asynchronous action types. If you have a set of actions to represent an api call to get a user, you can split them up into something like:

• FETCH_USER_REQUEST - for when you first send the api call
• FETCH_USER_SUCCESS - for when the api call is done and successfully returned data
• FETCH_USER_FAIL - for when the api call failed and responded with an error,
• FETCH_USER_COMPLETE - sometimes used at the end of the call regardless of status