React 使用的Redux, action type 抽离成常量好还是直接写死好

React 使用的Redux, action type 抽离成常量好还是直接写死好？

在React与Redux结合进行状态管理时，将action type抽离成常量是一种更推荐的做法，而不是直接写死在代码中。原因如下：

1. 减少错误：

   • 如果直接在action creator或reducer中硬编码字符串类型的action type，容易因拼写错误或大小写不一致而导致reducer无法正确响应action。将type定义为常量可以确保类型的一致性和准确性。

2. 可读性与维护性：

   • 抽象出的常量可以清晰地表达action的目的，提高代码的可读性。当查看reducer或action creator时，一眼就能看出某个action是用来做什么的。
   • 当应用变大，action类型增多时，集中管理的常量文件更便于查找和修改。

3. 模块化与复用：

   • 类型常量可以放在单独的文件中，方便不同模块引用和复用，增强代码组织结构。

4. lint工具支持：

   • 一些开发工具和linter（如ESLint）可以通过配置规则来强制检查action type是否从已声明的常量中导出，进一步避免错误。

5. 类型安全：

   • 在TypeScript等强类型语言中，通过定义类型常量还能提供静态类型检查，有助于在编译阶段就发现潜在问题。

综上所述，在实际开发中，为了提升代码质量、降低维护成本和减少潜在错误，通常会将Redux中的action type抽离成常量。例如：

// actionTypes.js
export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';

// actions.js
import { INCREMENT, DECREMENT } from './actionTypes';

function increment() {
  return { type: INCREMENT };
}

function decrement() {
  return { type: DECREMENT };
}

export { increment, decrement };

// reducer.js
import { INCREMENT, DECREMENT } from './actionTypes';

const counterReducer = (state = 0, action) => {
  switch (action.type) {
    case INCREMENT:
      return state + 1;
    case DECREMENT:
      return state - 1;
    default:
      return state;
  }
};

这样，每个action都有一个明确且统一的type标识符，提高了整个应用的状态管理和更新过程的健壮性。

actionTypes 是根据模块拆分成多个，还是所有的模块都写到一个js里呢？
关于action types的组织方式，可以根据项目的规模和模块划分来灵活决定。以下两种常见的方式供参考：

1. 按模块拆分成多个文件：
   当项目较大、模块化程度较高时，可以将每个模块相关的action types分别放在各自的文件中。这样有助于代码结构清晰，方便模块间的独立开发和维护。例如：

   // modules/auth/actionTypes.js
   export const LOGIN_REQUEST = 'LOGIN_REQUEST';
   export const LOGIN_SUCCESS = 'LOGIN_SUCCESS';
   export const LOGIN_FAILURE = 'LOGIN_FAILURE';
   
   // modules/user/actionTypes.js
   export const FETCH_USER_REQUEST = 'FETCH_USER_REQUEST';
   export const FETCH_USER_SUCCESS = 'FETCH_USER_SUCCESS';
   export const FETCH_USER_FAILURE = 'FETCH_USER_FAILURE';
   

2. 集中在一个文件中：
   对于小型项目或者action类型较少的情况，可以将所有action types集中在一个文件中统一管理。这样可以减少文件数量，简化引入路径。

   // actionTypes.js
   export const LOGIN_REQUEST = 'auth/LOGIN_REQUEST';
   export const LOGIN_SUCCESS = 'auth/LOGIN_SUCCESS';
   export const LOGIN_FAILURE = 'auth/LOGIN_FAILURE';
   
   export const FETCH_USER_REQUEST = 'user/FETCH_USER_REQUEST';
   export const FETCH_USER_SUCCESS = 'user/FETCH_USER_SUCCESS';
   export const FETCH_USER_FAILURE = 'user/FETCH_USER_FAILURE';
   

   在第二种方式中，为了在一定程度上保持模块化，可以通过命名空间（如auth/LOGIN_REQUEST）来区分不同模块的action types。

总结来说，选择哪种方式主要取决于项目的实际需求和团队的编码规范。无论哪种方式，关键都是要保证action types的一致性和可读性，并且易于管理和维护。