563

现在有很多关于 redux 镇最新的小子redux-saga/redux-saga 的讨论。它使用生成器函数来监听/调度动作。

在开始讨论之前,我想知道使用async/awaitredux-saga的方法而不是下面的方法的优缺点。redux-thunk

一个组件可能看起来像这样,像往常一样调度操作。

import { login } from 'redux/auth';

class LoginForm extends Component {

  onClick(e) {
    e.preventDefault();
    const { user, pass } = this.refs;
    this.props.dispatch(login(user.value, pass.value));
  }

  render() {
    return (<div>
        <input type="text" ref="user" />
        <input type="password" ref="pass" />
        <button onClick={::this.onClick}>Sign In</button>
    </div>);
  } 
}

export default connect((state) => ({}))(LoginForm);

然后我的动作看起来像这样:

// auth.js

import request from 'axios';
import { loadUserData } from './user';

// define constants
// define initial state
// export default reducer

export const login = (user, pass) => async (dispatch) => {
    try {
        dispatch({ type: LOGIN_REQUEST });
        let { data } = await request.post('/login', { user, pass });
        await dispatch(loadUserData(data.uid));
        dispatch({ type: LOGIN_SUCCESS, data });
    } catch(error) {
        dispatch({ type: LOGIN_ERROR, error });
    }
}

// more actions...

// user.js

import request from 'axios';

// define constants
// define initial state
// export default reducer

export const loadUserData = (uid) => async (dispatch) => {
    try {
        dispatch({ type: USERDATA_REQUEST });
        let { data } = await request.get(`/users/${uid}`);
        dispatch({ type: USERDATA_SUCCESS, data });
    } catch(error) {
        dispatch({ type: USERDATA_ERROR, error });
    }
}

// more actions...
4

9 回答 9

502

在 redux-saga 中,与上面的示例等效的是

export function* loginSaga() {
  while(true) {
    const { user, pass } = yield take(LOGIN_REQUEST)
    try {
      let { data } = yield call(request.post, '/login', { user, pass });
      yield fork(loadUserData, data.uid);
      yield put({ type: LOGIN_SUCCESS, data });
    } catch(error) {
      yield put({ type: LOGIN_ERROR, error });
    }  
  }
}

export function* loadUserData(uid) {
  try {
    yield put({ type: USERDATA_REQUEST });
    let { data } = yield call(request.get, `/users/${uid}`);
    yield put({ type: USERDATA_SUCCESS, data });
  } catch(error) {
    yield put({ type: USERDATA_ERROR, error });
  }
}

首先要注意的是,我们使用表单调用 api 函数yield call(func, ...args)call不执行效果,它只是创建一个普通对象,如{type: 'CALL', func, args}. 执行被委托给 redux-saga 中间件,该中间件负责执行函数并使用其结果恢复生成器。

主要优点是您可以使用简单的相等检查在 Redux 之外测试生成器

const iterator = loginSaga()

assert.deepEqual(iterator.next().value, take(LOGIN_REQUEST))

// resume the generator with some dummy action
const mockAction = {user: '...', pass: '...'}
assert.deepEqual(
  iterator.next(mockAction).value, 
  call(request.post, '/login', mockAction)
)

// simulate an error result
const mockError = 'invalid user/password'
assert.deepEqual(
  iterator.throw(mockError).value, 
  put({ type: LOGIN_ERROR, error: mockError })
)

请注意,我们通过简单地将模拟数据注入next迭代器的方法来模拟 api 调用结果。模拟数据比模拟函数简单得多。

要注意的第二件事是调用yield take(ACTION). 动作创建者在每个新动作(例如LOGIN_REQUEST)上调用 Thunks。即动作不断地被推送到 thunk,而 thunk 无法控制何时停止处理这些动作。

在 redux-saga 中,生成器拉下一个动作。即他们可以控制何时监听某些动作,何时不监听。在上面的例子中,流指令被放置在一个while(true)循环中,所以它会监听每个传入的动作,这在某种程度上模仿了 thunk push 行为。

拉式方法允许实现复杂的控制流。例如,假设我们要添加以下要求

  • 处理 LOGOUT 用户操作

  • 在第一次成功登录时,服务器返回一个令牌,该令牌在存储在expires_in字段中的某个延迟后过期。我们必须每expires_in毫秒在后台刷新授权

  • 考虑到在等待 api 调用的结果(初始登录或刷新)时,用户可能会在中间注销。

您将如何使用 thunk 实现它?同时还为整个流程提供完整的测试覆盖?以下是 Sagas 的外观:

function* authorize(credentials) {
  const token = yield call(api.authorize, credentials)
  yield put( login.success(token) )
  return token
}

function* authAndRefreshTokenOnExpiry(name, password) {
  let token = yield call(authorize, {name, password})
  while(true) {
    yield call(delay, token.expires_in)
    token = yield call(authorize, {token})
  }
}

function* watchAuth() {
  while(true) {
    try {
      const {name, password} = yield take(LOGIN_REQUEST)

      yield race([
        take(LOGOUT),
        call(authAndRefreshTokenOnExpiry, name, password)
      ])

      // user logged out, next while iteration will wait for the
      // next LOGIN_REQUEST action

    } catch(error) {
      yield put( login.error(error) )
    }
  }
}

在上面的示例中,我们使用race. 如果take(LOGOUT)赢得比赛(即用户点击了注销按钮)。比赛会自动取消authAndRefreshTokenOnExpiry后台任务。如果在通话过程authAndRefreshTokenOnExpiry中被阻止,call(authorize, {token})它也会被取消。取消自动向下传播。

您可以找到上述流程的可运行演示

于 2016-01-21T20:12:13.793 回答
115

除了库作者相当彻底的回答之外,我还将添加我在生产系统中使用 saga 的经验。

专业版(使用传奇):

  • 可测试性。测试 sagas 非常容易,因为 call() 返回一个纯对象。测试 thunk 通常需要您在测试中包含一个 mockStore。

  • redux-saga 带有许多有用的关于任务的辅助函数。在我看来,saga 的概念是为您的应用程序创建某种后台工作程序/线程,它充当 react redux 架构中缺失的部分(actionCreators 和 reducers 必须是纯函数。)这导致了下一点。

  • Sagas 提供了独立的地方来处理所有的副作用。根据我的经验,修改和管理通常比 thunk 操作更容易。

缺点:

  • 生成器语法。

  • 很多概念要学。

  • API 稳定性。似乎 redux-saga 仍在添加功能(例如 Channels?)并且社区没有那么大。如果库有一天会进行非向后兼容的更新,则存在问题。

于 2016-06-10T07:41:24.953 回答
36

我想根据我的个人经验添加一些评论(同时使用 sagas 和 thunk):

Sagas 非常适合测试:

  • 您不需要模拟带有效果的函数
  • 因此测试干净、易读且易于编写
  • 使用 sagas 时,动作创建者大多返回纯对象字面量。与 thunk 的 promise 不同,它也更容易测试和断言。

萨迦更强大。你可以在一个 thunk 的动作创建器中做的所有事情,你也可以在一个 saga 中做,但反之亦然(或者至少不容易)。例如:

  • 等待一个动作/动作被调度(take
  • 取消现有例程 ( cancel, takeLatest, race)
  • 多个例程可以监听同一个动作(take, takeEvery, ...)

Sagas 还提供了其他有用的功能,这些功能概括了一些常见的应用程序模式:

  • channels监听外部事件源(例如 websockets)
  • 前叉模型 ( fork, spawn)
  • 风门
  • ...

Sagas 是伟大而强大的工具。然而,权力伴随着责任。当您的应用程序增长时,您可能很容易迷失方向,因为您可能会弄清楚谁在等待分派动作,或者分派某个动作时发生的一切。另一方面,thunk 更简单,更容易推理。选择一个或另一个取决于许多方面,例如项目的类型和规模、项目必须处理的副作用类型或开发团队的偏好。在任何情况下,只要让您的应用程序简单且可预测。

于 2017-10-12T22:06:55.870 回答
31

2020 年 7 月更新:

在过去的 16 个月里,React 社区中最显着的变化可能是React 钩子

根据我的观察,为了更好地兼容功能组件和钩子,项目(即使是那些大型项目)倾向于使用:

  1. hook + async thunk(hook 让一切变得非常灵活,因此您实际上可以将 async thunk 放置在您想要的位置并将其用作普通函数,例如,仍然在 action.ts 中编写 thunk,然后 useDispatch() 来触发 thunk:https: //stackoverflow.com/a/59991104/5256695 ),
  2. 使用请求
  3. GraphQL/阿波罗useQuery useMutation
  4. 反应提取库
  5. 数据获取/API 调用库、工具、设计模式等的其他流行选择

相比之下,redux-saga目前与上述方法相比,在大多数正常的 API 调用情况下并没有真正提供显着的好处,同时通过引入许多 saga 文件/生成器增加了项目复杂性(也因为最后一个版本 v1.1.1redux-saga是在 9 月 18 日2019,那是很久以前的事了)。

但仍然redux-saga提供了一些独特的功能,例如赛车效果和并行请求。因此,如果您需要这些特殊功能,redux-saga仍然是一个不错的选择。


2019年3月的原帖:

只是一些个人经验:

  1. 对于编码风格和可读性,过去使用 redux-saga 最显着的优势之一是避免了 redux-thunk 中的回调地狱——不再需要使用许多嵌套 then/catch。但是现在随着 async/await thunk 的流行,在使用 redux-thunk 的时候也可以写成 sync 风格的 async 代码,这可以看作是对 redux-thunk 的一种改进。

  2. 在使用 redux-saga 时,可能需要编写更多样板代码,尤其是在 Typescript 中。例如,如果想要实现一个 fetch 异步功能,数据和错误处理可以直接在 action.js 中的一个 thunk 单元中执行,只需一个 FETCH 操作。但在 redux-saga 中,可能需要定义 FETCH_START、FETCH_SUCCESS 和 FETCH_FAILURE 动作及其所有相关的类型检查,因为 redux-saga 的特点之一就是使用这种丰富的“令牌”机制来创建效果和指示redux store 方便测试。当然,不使用这些动作也可以编写 saga,但这会使其类似于 thunk。

  3. 在文件结构方面,redux-saga 在很多情况下似乎更加明确。可以在每个 sagas.ts 中轻松找到与异步相关的代码,但在 redux-thunk 中,需要在操作中看到它。

  4. 简单的测试可能是 redux-saga 的另一个重要特征。这真的很方便。但需要澄清的一点是,redux-saga “调用”测试在测试中不会执行实际的 API 调用,因此需要为 API 调用之后可能使用的步骤指定示例结果。因此,在编写 redux-saga 之前,最好详细规划一个 saga 及其对应的 sagas.spec.ts。

  5. Redux-saga 还提供了许多高级功能,例如并行运行任务、takeLatest/takeEvery、fork/spawn 等并发助手,这些功能远比 thunk 强大。

总之,就个人而言,我想说:在许多正常情况下和中小型应用程序中,使用 async/await 风格的 redux-thunk。它将为您节省许多样板代码/操作/typedef,并且您无需切换许多不同的 sagas.ts 并维护特定的 sagas 树。但是如果你正在开发一个大型应用程序,它具有非常复杂的异步逻辑并且需要并发/并行模式等功能,或者对测试和维护有很高的需求(尤其是在测试驱动开发中),redux-sagas 可能会挽救你的生命.

无论如何,redux-saga 并不比 redux 本身更难更复杂,也没有所谓的陡峭学习曲线,因为它的核心概念和 API 非常有限。花一点时间学习 redux-saga 可能会让你在未来的某一天受益。

于 2019-03-27T13:26:00.657 回答
9

根据我的经验,我回顾了几个不同的大型 React/Redux 项目,Sagas 为开发人员提供了一种更结构化的代码编写方式,这种方式更容易测试,也更难出错。

是的,一开始有点奇怪,但大多数开发人员在一天内就对它有足够的了解。我总是告诉人们不要担心从什么yield开始,一旦你写了几个测试它就会来找你。

我见过几个项目,其中 thunk 被视为来自 MVC 模式的控制器,这很快就变成了无法维护的混乱。

我的建议是在你需要 A 触发 B 类型的与单个事件相关的东西的地方使用 Sagas。对于可能跨越多个动作的任何事情,我发现编写自定义中间件并使用 FSA 动作的元属性来触发它更简单。

于 2018-06-14T21:04:03.187 回答
4

Thunks 与 Sagas

Redux-Thunk并且Redux-Saga在一些重要方面有所不同,两者都是 Redux 的中间件库(Redux 中间件是拦截通过 dispatch() 方法进入 store 的操作的代码)。

操作实际上可以是任何东西,但如果您遵循最佳实践,则操作是一个普通的 javascript 对象,带有一个类型字段,以及可选的有效负载、元和错误字段。例如

const loginRequest = {
    type: 'LOGIN_REQUEST',
    payload: {
        name: 'admin',
        password: '123',
    }, };

Redux-Thunk

除了分派标准动作之外,Redux-Thunk中间件还允许您分派特殊功能,称为thunks.

Thunks(在 Redux 中)通常具有以下结构:

export const thunkName =
   parameters =>
        (dispatch, getState) => {
            // Your application logic goes here
        };

也就是说,athunk是一个函数,它(可选)接受一些参数并返回另一个函数。内部函数接受一个dispatch function和一个getState函数——两者都将由Redux-Thunk中间件提供。

Redux-Saga

Redux-Saga中间件允许您将复杂的应用程序逻辑表达为称为 sagas 的纯函数。从测试的角度来看,纯函数是可取的,因为它们是可预测的和可重复的,这使得它们相对容易测试。

Sagas 是通过称为生成器函数的特殊函数实现的。这些是ES6 JavaScript. 基本上,在您看到 yield 语句的任何地方,执行都会跳入和跳出生成器。将yield语句视为导致生成器暂停并返回产生的值。稍后,调用者可以在yield.

生成器函数就是这样定义的。注意 function 关键字后面的星号。

function* mySaga() {
    // ...
}

一旦登录传奇注册到Redux-Saga. 但是yield第一行的 take 会暂停 saga,直到一个带有 type 的 action'LOGIN_REQUEST'被发送到 store。一旦发生这种情况,执行将继续。

有关更多详细信息,请参阅这篇文章

于 2019-07-31T15:11:13.233 回答
1

一个速记。生成器是可取消的,异步/等待 - 不是。因此,对于问题中的一个示例,选择什么并没有真正的意义。但是对于更复杂的流程,有时没有比使用生成器更好的解决方案。

所以,另一个想法可能是使用带有 redux-thunk 的生成器,但对我来说,这似乎是在尝试发明一辆带有方形轮子的自行车。

当然,生成器更容易测试。

于 2018-06-14T22:11:29.450 回答
0

这是一个结合了两者最好部分(优点)的项目redux-sagaredux-thunk您可以处理 sagas 上的所有副作用,同时通过dispatching相应的操作获得承诺: https ://github.com/diegohaz/redux-saga-thunk

class MyComponent extends React.Component {
  componentWillMount() {
    // `doSomething` dispatches an action which is handled by some saga
    this.props.doSomething().then((detail) => {
      console.log('Yaay!', detail)
    }).catch((error) => {
      console.log('Oops!', error)
    })
  }
}
于 2017-05-23T03:39:00.100 回答
-2

更简单的方法是使用redux-auto

从文档中

redux-auto 简单地通过允许您创建一个返回承诺的“动作”函数来解决这个异步问题。伴随您的“默认”功能操作逻辑。

  1. 不需要其他 Redux 异步中间件。例如 thunk、promise-middleware、saga
  2. 轻松地允许您将承诺传递到 redux并为您管理它
  3. 允许您将外部服务调用与它们将被转换的位置放在一起
  4. 将文件命名为“init.js”将在应用程序启动时调用它一次。这对于在启动时从服务器加载数据很有用

这个想法是将每个动作都放在一个特定的文件中。将文件中的服务器调用与“待处理”、“已完成”和“已拒绝”的减速器功能放在一起。这使得处理 Promise 变得非常容易。

它还自动将一个辅助对象(称为“异步”)附加到您的状态原型,允许您在 UI 中跟踪请求的转换。

于 2017-06-24T13:25:10.933 回答