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

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

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

减少错误：
- 如果直接在action creator或reducer中硬编码字符串类型的action type，容易因拼写错误或大小写不一致而导致reducer无法正确响应action。将type定义为常量可以确保类型的一致性和准确性。
可读性与维护性：
- 抽象出的常量可以清晰地表达action的目的，提高代码的可读性。当查看reducer或action creator时，一眼就能看出某个action是用来做什么的。
- 当应用变大，action类型增多时，集中管理的常量文件更便于查找和修改。
模块化与复用：
- 类型常量可以放在单独的文件中，方便不同模块引用和复用，增强代码组织结构。
lint工具支持：
- 一些开发工具和linter（如ESLint）可以通过配置规则来强制检查action type是否从已声明的常量中导出，进一步避免错误。
类型安全：
- 在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的组织方式，可以根据项目的规模和模块划分来灵活决定。以下两种常见的方式供参考：

按模块拆分成多个文件：
当项目较大、模块化程度较高时，可以将每个模块相关的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';

集中在一个文件中：
对于小型项目或者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的一致性和可读性，并且易于管理和维护。

__EOF__

本文作者：龙陌
本文链接：https://www.cnblogs.com/longmo666/p/17994767.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！