加入收藏 | 设为首页 | 会员中心 | 我要投稿 汽车网 (https://www.0577qiche.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

什么是Reudx 缩减样板代码

发布时间:2023-04-07 08:44:08 所属栏目:教程 来源:
导读:Redux 很大部分受到 Flux 的启发,而最常见的关于 Flux 的抱怨是必须写一大堆的样板代码。在这章中,我们将考虑 Redux 如何根据个人风格,团队偏好,长期可维护性等自由决定代码的繁复程度。

Actions
Actions 是
Redux 很大部分受到 Flux 的启发,而最常见的关于 Flux 的抱怨是必须写一大堆的样板代码。在这章中,我们将考虑 Redux 如何根据个人风格,团队偏好,长期可维护性等自由决定代码的繁复程度。

Actions
Actions 是用来描述在 app 中发生了什么的普通对象,并且是描述突变数据意图的唯一途径。很重要的一点是 不得不 dispatch 的 action 对象并非是一个样板代码,而是 Redux 的一个基本设计选择.

不少框架声称自己和 Flux 很像,只不过缺少了 action 对象的概念。在可预测性方面,这是从 Flux 或 Redux 的倒退。如果没有可序列化的普通对象 action,便无法记录或重演用户会话,也无法实现 带有时间旅行的热重载。如果你更喜欢直接修改数据,那你并不需要使用 Redux 。

Action 一般长这样:

{ type: 'ADD_Todo', text: 'Use Redux' }
{ type: 'REMOVE_Todo', id: 42 }
{ type: 'LOAD_ARTICLE', response: { ... } }
一个约定俗成的做法是,action 拥有一个不变的 type 帮助 reducer (或 Flux 中的 Stores ) 识别它们。我们建议你使用 string 而不是 符号(Symbols) 作为 action type ,因为 string 是可序列化的,并且使用符号会使记录和重演变得困难。

在 Flux 中,传统的想法是将每个 action type 定义为 string 常量:

const ADD_Todo = 'ADD_Todo'
const REMOVE_Todo = 'REMOVE_Todo'
const LOAD_ARTICLE = 'LOAD_ARTICLE'
这么做的优势是什么?人们通常声称常量不是必要的。对于小项目也许正确。 对于大的项目,将 action types 定义为常量有如下好处:

帮助维护命名一致性,因为所有的 action type 汇总在同一位置。

有时,在开发一个新功能之前你想看到所有现存的 actions 。而你的团队里可能已经有人添加了你所需要的 action,而你并不知道。

Action types 列表在 Pull Request 中能查到所有添加,删除,修改的记录。这能帮助团队中的所有人及时追踪新功能的范围与实现。

如果你在 import 一个 Action 常量的时候拼写错了,你会得到 undefined 。在 dispatch 这个 action 的时候,Redux 会立即抛出这个错误,你也会马上发现错误。

你的项目约定取决与你自己。开始时,可能在刚开始用内联字符串(inline string),之后转为常量,也许再之后将他们归为一个独立文件。Redux 在这里没有任何建议,选择你自己最喜欢的。

Action Creators
另一个约定俗成的做法是通过创建函数生成 action 对象,而不是在你 dispatch 的时候内联生成它们。

例如,不是使用对象字面量调用 dispatch :

// event handler 里的某处
dispatch({
  type: 'ADD_Todo',
  text: 'Use Redux'
})
你其实可以在单独的文件中写一个 action creator ,然后从 component 里 import:

actionCreators.js
export function addTodo(text) {
  return {
    type: 'ADD_Todo',
    text
  }
}
AddTodo.js
import { addTodo } from './actionCreators'
 
// event handler 里的某处
dispatch(addTodo('Use Redux'))
Action creators 总被当作样板代码受到批评。好吧,其实你并不非得把他们写出来!如果你觉得更适合你的项目,你可以选用对象字面量 然而,你应该知道写 action creators 是存在某种优势的。

假设有个设计师看完我们的原型之后回来说,我们最多只允许三个 todo 。我们可以使用 redux-thunk 中间件,并添加一个提前退出,把我们的 action creator 重写成回调形式:

function addTodoWithoutCheck(text) {
  return {
    type: 'ADD_Todo',
    text
  }
}
 
export function addTodo(text) {
  // Redux Thunk 中间件允许这种形式
  // 在下面的 “异步 Action Creators” 段落中有写
  return function(dispatch, getState) {
    if (getState().todos.length === 3) {
      // 提前退出
      return
    }
    dispatch(addTodoWithoutCheck(text))
  }
}
我们刚修改了 addTodo action creator 的行为,使得它对调用它的代码完全不可见。我们不用担心去每个添加 todo 的地方看一看,以确认他们有了这个检查 Action creator 让你可以解耦额外的分发 action 逻辑与实际发送这些 action 的 components 。当你有大量开发工作且需求经常变更的时候,这种方法十分简便易用。

Action Creators 生成器
某些框架如 Flummox 自动从 action creator 函数定义生成 action type 常量。这个想法是说你不需要同时定义 ADD_Todo 常量和 addTodo() action creator 。这样的方法在底层也生成了 action type 常量,但他们是隐式生成的、间接级,会造成混乱。因此我们建议直接清晰地创建 action type 常量。

(编辑:汽车网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章