Redux Saga
前言
使用Saga也有一段时间了，刚开始ReduxThunk转换到Saga的适应期中还是比较难受的，有很多思维上和逻辑上的转换；后来使用Saga的频率越来越高，为了更好地使用它就必须去了解它的实现原理和源码，在慢慢地犯错和修正的过程中有了一些自己的理解和更好的一些实现方案，在这里记录下来。
这篇文章主要是让一些对Saga持有困惑的初学者更好地了解和使用Saga，文章中提到的东西也比较杂，主要都是为了更好地理解Saga。
Side Effects 副作用
我们经常会提到副作用，就是为了处理副作用我们才会使用Thunk， Saga这些工具，那什么是副作用？
什么是副作用？
鲁迅说：副作用是在计算结果的过程中，系统状态的一种变化，或者与外部世界进行的可观察的交互。
简单地说，只要是跟函数外部环境发生的交互就都属于副作用。
是不是还是有点困惑？我们举些例子吧，副作用包括但不限于以下情况：
- 发送一个 http 请求
- 更改文件系统
- 往数据库插入记录
- 使用LocalStorage进行本地存储
- 打印/log
- 获取用户输入
- DOM 查询
- 访问系统状态
大概知道什么是副作用之后，我们继续了解两个词：纯函数 & 非纯函数
什么是纯函数？
纯函数：
函数与外界交互唯一渠道就是——参数和返回值。也就是说：
函数从函数外部接受的所有输入信息都通过参数传递到该函数内部；函数输出到函数外部的所有信息都通过返回值传递到该函数外部。
什么是非纯函数？
非纯函数：
函数通过参数和返回值以外的渠道，和外界进行数据交换。
比如，读取/修改全局变量；比如，从local storage读取数据，还将其打印到屏幕；再比如在函数里发起一个http请求获取数据。。
那为什么我们要追求纯函数？那它当然有它的好处了。
- 引用透明性：纯函数总是能够根据相同的输入返回相同的输出，所以它们就能够保证总是返回同一个结果。
- 可移植性／自文档化：纯函数内部与环境无关，可以自给自足，更易于观察和理解，一切依赖都从参数中传递进来，所以仅从函数签名我们就得知足够的信息。
- 可缓存性：由于以上特性，纯函数总能够根据输入做缓存，例如memoize函数，用一个对象来缓存计算结果。
- 可测试性：不需要伪造环境，只需简单地给函数一个输入，然后断言输出就好了。
让人讨厌的副作用？
说了这么多纯函数的好处，我们费劲心思将让人讨厌的副作用处理掉，那为什么还要写有副作用的代码啊？
但是回过头想想，副作用都是我们程序里的关键，假如没有副作用，一切都变得毫无意义了。
假如一个前端项目不能发起http请求从后端获取信息，
假如一个文件系统或者数据库不能让我们读写数据，
假如不能根据用户的输入从屏幕上输出他们想要的信息
这一切都没有意义了。
所以我们的任务不是消除副作用，而是要把副作用统一管理，避免一些不该出现的/我们并不希望出现的问题，让程序看起来更可控更纯洁～
所以我们才会在项目的状态管理中使用thunk，saga等手段处理副作用:)
Why Not Redux Thunk
Redux Thunk也是处理副作用的一个中间件，那为什么不推荐使用Redux Thunk呢？
鲁迅说： 因为丑！它不好看！
redux的作者提供了Redux Thunk中间件给我们集中地处理副作用，所以它的优点就是：可以处理副作用。
但是也就仅提供处理副作用这个功能，处理方式相当粗暴简陋（你看看thunk一共就10行不到的代码你就懂了），我说说缺点：
- 内部代码重复且无意义，逻辑复杂（丑）
- Action本应是一个纯碎的JS对象，但是使用Thunk之后Action的形式千奇百态（丑）
- 代码难以测试（因为丑）
举个丑例子
const GET_DATA = 'GET_DATA'
const GET_DATA_SUCCESS = 'GET_DATA_SUCCESS'
const GET_DATA_FAILED = 'GET_DATA_FAILED'
const getDataAction = id => (dispatch, getState) => {
dispatch({
type: GET_DATA,
payload: id
})
api.getData(id)
.then(res => {
dispatch({
type: GET_DATA_SUCCESS,
payload: res
})
})
.catch(err => {
dispatch({
type: GET_DATA_FAILED,
payload: err
})
})
}
综上，这不是我们高级而优雅的前端工程师想要的结果！！
Why Redux Saga
那为什么就推荐Saga了呢？
鲁迅说： 优雅！高级！一眼看不懂！
我们看一下官方介绍吧。
redux-saga is a library that aims to make application side effects easier to manage, more efficient to execute, easy to test, and better at handling failures.
从介绍中可以看到Saga有这么几个特点：
- 更容易管理副作用
- 程序更高效执行
- 易于测试
- 易于处理错误
那鲁迅为什么说人家优雅高级啊，高在哪儿啊？
Redux Saga之所以更受我们欢迎，因为它的核心就是巧妙地使用了ES6的特性——Generator，基于Generator实现异步流程的控制管理。
ES6 Generator
为了更好地理解Saga的原理，了解Generator的基础知识是必经之路。
（假如你已经很了解Generator的话可以直接跳过本小节）
来，这是一个简单的Generator函数的例子
function * generator () {
yield 'hello'
yield 'world'
}
let gen = generator()
gen.next() // { value: 'hello', done: false}
gen.next() // { value: 'world', done: false}
gen.next() // { value: undefined, done: true}
generator是生成器函数，*：是它的专有标志。
yield是暂停标志，每次程序运行到yield时都会暂停，等待下一次指令的执行；它只能在generator函数里，后面跟着一个表达式。
return是终止标志。
gen是由generator生成器函数生成的一个遍历器对象。
gen对象拥有next()方法，调用next方法会得到结构为一个内含value和done属性的对象，value是yield后面表达式的值，done是遍历是否结束的标志位。
只有执行了next才会开始调用generator函数。next传入的参数会当作上一个yield表达式的返回值，所以第一次调用next传入的参数是无效的。
我们通过一个复杂一点点的例子来了解Generator函数
function * generator (x, y) {
// yield
// 暂停标志
// 只能在generator里
// 后面接着一个表达式
let a = yield x + y
// ⚠️a拿到的是next传来的参数，而不是yield后面的表达式！
// ⚠️因此我们可以通过next函数在外部改变generator内部的行为
let b = yield x * y
// return
// 终止标志
return a + b
}
// gen
// 遍历器对象
let gen = generator(1, 2)
gen.next()
// {value: 3, done: false}
gen.next(9)
// {value: 2, done: false}
gen.next(8)
// {value: 17, done: false}
// 只有执行next才会调用generator
// next传入的参数会当作上一个yield表达式的返回值
// 所以第一次调用next传入的参数是无效的
看懂这段代码最关键的点就是
yield前面的变量拿到的是next传来的参数，而不是yield后面的表达式！
generator.png
（具体就不解释这段代码啦，有问题可以留言哈）
这为我待会儿要讲Saga核心第一个点作了一个小铺垫：
Generator通过yield和next来传递数据来控制函数的内部流程
Redux Saga
前面铺垫了这么多，终于要开始讲一下Saga了。
Saga是一个中间件，所以我们首先当然要去注册一下它啦～
import { createStore, applyMiddleware } from 'redux'
import createSagaMiddleware from 'redux-saga'
import reducer from './reducers'
import mySaga from './sagas'
// create the saga middleware
const sagaMiddleware = createSagaMiddleware()
// mount it on the Store
const store = createStore(
reducer,
applyMiddleware(sagaMiddleware)
)
// then run the saga
sagaMiddleware.run(mySaga)
export default store
注册的步骤很简单，调用createSagaMiddleware，用于创建saga中间件；讲saga中间件注入store中，并执行run操作，运行我们写的saga函数。
再来一个简单的使用例子：
import { createActions } from 'redux-actions'
import { call, put, takeLatest } from 'redux-saga/effects'
import { fetchDataApi } from '@api/index'
export const {
data: { fetchDataReq, fetchDataSucc, fetchDataFailed }
} = createActions({
DATA: {
FETCH_DATA_REQ: null,
FETCH_DATA_SUCC: rsp => ({ data: rsp }),
FETCH_DATA_FAILED: null,
}
})
function* fetchDataReqSaga() {
try {
const rsp = yield call(fetchDataApi)
yield put(fetchDataSucc(rsp))
} catch (e) {
yield put(fetchDataFailed(e))
}
}
function* watchFetchSaga() {
yield takeLatest(fetchDataReq, fetchDataReqSaga)
}
export default watchFetchSaga
这是刚刚Redux Thunk同样的小例子，发起一个action触发一个http请求，请求成功时发起success action，请求失败时发起failed action。
在Saga中会使用一种叫做Effect的指令来完成这些操作。如例子中
call，put，takeLatest等等，都是Effect指令。
通俗地讲（为了便于大家理解，具体意思下面会再做介绍），call作用是调用其参数中的函数，pull作用是发起一个action，takelatest作用是监听某个action的触发并执行回调函数。
Effects
Effects就是简单的JavaScript对象，我们可以把它视作是发送给saga middleware的一些指令，它仅仅是负责向middleware描述调用行为的信息，而接下来的操作是由middleware来执行，middleware执行完毕后将指令的结果回馈给 Generator。
也就是说我们只需要通过声明Effects的形式，将副作用的部分都留给middleware来执行。
这样做的好处：
1: 集中处理异步操作，更流利熟悉地表达复杂的控制流。
2: 保证action是个纯粹的JavaScript对象，风格保持统一。
3: 声明式指令，无需在generator中立即执行，只需通知middleware让其执行；借助generator的next方法，向外部暴露每一个步骤。
接下来看一下一些常用的effect指令
- put 用来命令 middleware 向 Store 发起一个 action。
- take 用来命令 middleware 在 Store 上等待指定的 action。在发起与 pattern 匹配的 action 之前，Generator 将暂停。
- call 用来命令 middleware 以参数 args 调用函数 fn。
- fork 用来命令 middleware 以 非阻塞调用 的形式执行 fn。
- race 用来命令 middleware 在多个 Effect 间运行，相当于Promise.race。
- all 用来命令 middleware 并行地运行多个 Effect，并等待它* 们全部完成，相当于Promise.all。
Saga辅助函数
Saga除了提供Effects，还会提供一些高阶的辅助函数给我们使用，而这些辅助函数实际上也是基于各个Effects实现的。
- takeEvery（take+fork）
- takeLatest （take+fork+cancel）
- takeLeading（take+call）
- throttle（take+fork+delay）
- debounce（take+fork+delay)
- retry （call+delay）
举个简单的例子，当用户点击按钮触发事件时：
- takeEvery会并发执行（take+fork）；
- takeLastest只执行最后一次（take+fork+cancel）；
- takeLeading只执行第一次（take+call）；
- throttle节流，触发后一段时间不会再次触发（take+fork+delay）；
- debounce防抖，等到一段时间后再触发；
- retry，多次重试触发；
Saga原理之Channel
了解完Saga的基本使用，我们开始进一步了解它的原理。先说说Saga中间件里头有一个Channel的东西，它可以理解为一个action监听的池子，每次调用take指令的时候就会将对应action的监听函数放进池子里，当每次调用put指令或者外部发起一个action的时候，Saga就会在池子里匹配对应的监听函数并执行，然后将其销毁。
channel
以下是简化过的Saga源码channel部分：
function channel () {
let taker
function take (cb) {
taker = cb
}
function put (input) {
if (taker) {
const tempTaker = taker
taker = null
tempTaker(input)
}
}
return {
put,
take
}
}
const chan = channel()
Saga原理之自驱动模式
可能你会有疑惑，为什么Saga中间件会自动按照程序设定的一般地接受指定的Effect指令去执行对应的同步/异步操作呢？
其实这就是Saga基于Generator的一种自驱动模式（这是我自己起的名字）
回过头想想上文提及Generator时归结出的一个结论：
Generator通过yield和next来传递数据来控制函数的内部流程
Saga就是利用了这一点，而且不止这样，Saga中间件内部有一个驱动函数（effectRunner)，它里面生成一个遍历器对象来不断地消费生成器函数(effectProducer)中的effect指令，完成指定的任务并递归循环下去。（这时候你可能会想到TJ大神的CO库）
这个驱动函数大概长这样
function task (saga) {
// 初始化遍历器对象
const sa = saga()
function next (args) {
// 获取到yield后面的表达式——effect指令
const result = sa.next(args)
const effect = result.value
// 执行effect对应的操作——call/put/take...
runEffect(result.value, next)
}
// 执行next函数
next()
}
这样就实现了一个自我驱动的方案，回想一下Saga中间件注册的步骤
调用createSagaMiddleware，用于创建saga中间件；讲saga中间件注入store中，并执行run操作，运行我们写的saga函数。
当执行run(saga)的时候其实就是启动了驱动函数（effectRunner)，它开始控制我们自己编写的业务流程Saga函数(effectProducer)，effectRunner通过next来控制流程和传递数据（执行结果），effectProducer通过yield来发布effect指令，这样就完美演绎了saga整个生命周期！！
saga.png
Saga源码
实际上Saga源码中也就这么一回事，我主要挑了channel和自驱动函数两块东西来分享，在Saga源码中有一个proc函数，其实就是上文提到的自驱动函数，它接收到effect指令之后进行effect类型分发，不同effect对应不同的操作。
saga.png
具体的源码解析就不在这里细说啦，大家可以自行查阅～（还不是因为怕说错被喷）
Saga测试
Saga还有一个优点记得吗？易于测试，由于业务代码都是声明式地调用，而不是真实地进行一些副作用操作，所以在写单测的时候可以通过断言的方式来测试，而不用mock一些繁琐复杂的操作。
最后
其实在使用Saga的过程中会有很多的疑惑，例如怎么才是更好的实现方式，怎么才可以更好的实现封装，减少冗余代码，本来想在这里和大家继续分享一些案例，但是实在是学识尚浅，也不确定什么才是s所谓的更好，所以还是鼓励大家一起去探索啦～
谢谢阅读～假如对你有帮助的话可以给我点个❤️～假如有任何疑惑或者描述错误的地方可以随意在评论区留言～感恩～
网友评论