1.一文彻底搞懂 DvaJS 原理
2.react项目使用redux-saga
3.探索React异步解决方案之redux-saga
4.redux-saga 浅析
一文彻底搞懂 DvaJS 原理
dva 首先是一个基于 redux 和 redux-saga 的数据流方案,同时为了简化开发体验,dva 还额外内置了 react-router 和 fetch,因此可以理解为一个轻量级的应用框架。
在使用 dva 时,经常会遇到疑问:如何解决概念多、高端手机站源码 reducer, saga, action 分离等问题?dva 的优势在于整合了这些概念,使得开发者可以更轻松地管理和控制应用的逻辑。
然而,dva 的劣势在于它并不是一个完全独立的框架,而是基于 redux 和 redux-saga 的扩展,因此可能在某些特定需求上不够灵活。
dva 适用于需要简化开发流程、整合多种功能的中小型应用,特别适合那些希望快速上手并专注于业务逻辑的开发者。
dva 的核心概念主要包括:app 实例的初始化、使用 create 方法创建 app、中间件的配置与管理、以及应用的路由管理。
dva 的应用最简结构包括:不带 Model 的基本应用结构,以及带 Model 的应用结构,后者允许更细粒度的管理状态和逻辑。
dva 的底层原理涉及了 dva-core 的核心功能,包括 app 实例的构造、store 的初始化、以及中间件的配置与管理等关键实现。
dva 与 React、React-Redux、Redux-Saga 的差异主要体现在数据流的控制、组件间的交互以及异步操作的处理方式上。原生 React 强调纯函数组件和状态的集中管理,React-Redux 则通过 Redux 提供了状态管理能力,而 Redux-Saga 则专注于处理异步操作。
Dva 的优势在于它整合了这些功能,提供了约定大于配置的网站正在施工源码 API,以及基于 Elm 的概念,使得编码体验更加友好和高效。它旨在简化应用开发流程,提升编码效率,同时保持代码的可读性和可维护性。
Dva 背后值得学习的思想是:关注编程的趣味性和简单性,追求代码的可复用性和易理解性。通过最小化框架的复杂性,Dva 使得切换框架变得轻松,同时鼓励开发者关注代码本身的质量和用户界面的友好性。
最后,dva 是支付宝前端应用架构发展中的一种选择,它代表了在 React + Redux 最佳实践基础上的进一步探索。通过 dva,开发者可以更高效地构建和管理复杂的应用。
react项目使用redux-saga
使用Redux-Saga之前,了解Redux的基本使用流程至关重要。从Redux官网获取详细信息。
在Redux-Saga的使用过程中,有一些关键步骤需遵循。解答1:Redux的使用流程包括store、actions、reducers和dispatch。解答2:Redux-Saga的使用流程则引入了effects,用于处理异步操作。
如何在项目中集成Redux-Saga?对于大量异步请求的处理,通过以下步骤来实现:首先,确保你的目录结构清晰。
在项目中,通常会有一个`Async.js`组件,负责展示加载状态或错误信息。`index.js`在store的入口文件中引入Redux-Saga,`reducer.js`则负责状态管理。`actionType.js`和`actionCreate.js`定义了actions类型和创建函数,ociuldr2源码`sagas.js`专门用于编写Saga逻辑,`api/index.js`和`fetch.js`用于封装AJAX请求。最后,通过`Provider`组件,将store注入到根组件中。
使用Redux-Saga时,遵循文档指引和示例代码,遵循基本流程:异步操作、效果(effects)处理、状态管理。确保你的项目结构清晰,遵循Redux-Saga的逻辑,实现高效、可维护的异步操作处理。
探索React异步解决方案之redux-saga
redux-saga是什么? Redux-saga是一个用于简化Redux应用程序中异步操作的库,目标是更优雅地管理副作用、提高执行效率、方便测试并在处理错误时提供更好的支持。它的设计基于康奈尔大学的研究,旨在解决分布式系统中长时运行事务的数据一致性问题。 什么是SideEffects? 在编程中,副作用指的是程序与外部世界(如用户、文件系统、网络上的其他计算机)进行交互的方式。在JavaScript中,这通常包括异步网络请求和浏览器缓存的读取等。 如何区别saga与thunk? 尽管都作为Redux的中间件,saga和thunk在实现上和设计理念上存在差异。saga通过命令/回答模式进行通信,每个saga都是生成器函数,以同步的方式处理异步逻辑。而thunk则通过将函数作为action传递给store,支持异步操作。 学习saga使用 saga提供了两个主要的pi远控源码中间件API,用于创建和运行saga。在安装依赖并关联store后,可以利用这些API来实现saga的运行。 saga中的关键概念 1. Task: 是saga运行的结果,提供执行和控制的接口。2. Channel: 用于在saga间传递消息,消息在被接收者请求前被缓存。
3. Buffer: 实现了消息的缓存策略。
4. SagaMonitor: 用于启动和监控saga事件。
saga的Effect创建器 Effect是包含执行指令的对象,用于指导saga中间件执行特定任务。例如,take用于监听特定action,put用于在store中发起action,call用于调用外部函数等。 saga的辅助函数和组合器 提供了一组函数来简化saga的编写,如TakeEvery、TakeLatest等,用于根据action模式生成saga。 Redux-Saga的测试 得益于saga的细粒度和低耦合性,使其在单元测试中表现出色。例如,可以测试特定的saga响应特定的action。 Redux-Saga使用技巧 1. 重试Ajax请求:在请求失败后自动重试。2. 撤销操作:确保在操作撤销时可以回滚到原始状态。
参考资料Redux-Saga 漫谈
Saga Pattern
Redux-Saga官方文档
Why saga
手写Redux-Saga源码
redux-saga 浅析
Redux提供了一种通过中间件来处理action的方式,其中,我们常用的中间件如redux-thunk(以下简称为thunk),它主要用于处理函数类型的action。除了thunk,还有其他常用的中间件,例如redux-saga(以下简称为saga)。saga提供了丰富的API,使我们能够更容易地处理异步操作。审计问题整改源码本文将主要探讨saga的实现方式。
saga这一概念源自后端事物,一个事物通常包含多个子事物,这些子事物组合在一起,就构成了一个saga。例如,用户购买火车票这一事物,就包括了订票、付款、退票、出票等动作。
在redux-saga中,一个generator函数被定义为saga函数,在此generator函数中,会包含对一个异步事务的完整处理流程。
effect在saga中是一个常见的概念,任务的发起都是通过effect来实现的,下文将进一步阐述这个概念。
让我们从saga提供的一个简单的API开始,即take。take是saga提供的一个监听action的API,其基本用法如下:
一个基本的结构还是很简单的,从这个示例中,我们可以发现几个特点:
总结一下,saga在初始情况下会进行注册操作,然后在saga函数中使用take进行监听。这个流程似乎有点发布订阅模式的身影,那我们就顺着这个思路来模拟实现一下take函数。
这里我们主要是模拟实现sagaMiddleware.run和take这两个函数。实现之前我们先了解下两个概念:
先实现一个task:
下面分析一下task函数的执行过程:
接下来的主要工作是实现runTakeEffect,这个函数的作用主要有两个:
由于这里需要对迭代器做存储,所以这里还需要引入saga中的另外一个概念:
runTakeEffect的实现:
解析一下runTakeEffect的逻辑:
现在一个大体的take函数基本实现完毕了,我们来模拟用户的操作事件来测试一下:
执行结果如下:
我们触发了两次chan.put,但实际上监听函数只执行了一次,这是由于在第一次执行完后就被销毁了。
saga提供了一个takeEvery的API,作为对take的补充,不同于take监听的一次性有效,它对action的监听是始终有效的,其基本使用方法如下:
可以看到,takeEvery有两个参数,第一个参数是监听的action,第二个参数是监听的执行函数
实际上,在实现takeEvery之前,我们可以使用一个无限循环的take来模拟下takeEvery,达到无限监听的目的:
原理很简单,就是使用一个死循环来实现,当上一个taker执行完并被销毁后,此时会再次进入下次迭代循环:
再次执行next,又到yield take('start')这句,再次向chan中添加监听方法,重复之前的过程,达到持续监听的目的。
了解了takeEvery要做到的事情,接下来就模拟实现一下。在这之前,还需要再了解一下saga提供的另外一个API:
接下来就是要重点实现task的部分:
修改后的task还是比较绕的,我们来分析一下它的执行过程:
最后,加入如下测试方法,会发现每次执行chan.put都实现了监听:
至此,就实现了takeEvery方法,现在小总结一下:
到此,对effect有一些认识了,这里对effect总结一下,先看一下官方的解释:
An effect is a plain JavaScript Object containing some instructions to be executed by the saga middleware.
意思是,effect是一个纯对象,包含一些指令信息,这些指令会被middleware解释执行。
通过上面的两个例子,我们已经认识到了两个effect,一个是take,一个是frok,它们实际上都是一个对象,相当于给执行器task发送指令,task通过判断effect的不同类型知道要处理什么样的任务。这就是task的本质。
所以基于这种通过effect给task发送指令的做法,我们再来模拟实现如call、cancle等API,实际上,saga中提供的effects中的API也是这么做的。
fork与call
在上面实现takeEvery的过程中,我们实现了一个辅助函数fork,fork的作用是启动一个新的task实现无阻塞调用。与之相对的是另外一个effect叫call,call的作用也是调用有副作用的函数,它是阻塞调用的。它的基本用法如下:
如上所述,调用yield call后,函数将被阻塞住,2秒过后才会继续向下执行到console语句
它的实现也是比较简单的,我们需要判断一下,call调用的函数返回的结果,如果是promise,就等其结果resolve后再继续执行迭代器的next方法,如果不是promise,就直接调用next方法继续迭代器的执行。
首先实现一下call,和fork类似,它也是返回描述effect的纯对象的函数:
然后再改造一下task函数,需要变动的地方就是在判断effect的类型的条件中增加一项:
最后再实现runCallEffect函数:
到此,一个基本的call方法就完成了。
需要提醒的是,此处我们使用了call直接调用了delay方法call(delay),这是没有问题的,但我们自己在上文中实现的fork却不能直接这么调用,这是由于fork是重启了一个task,而task的参数我们设定的只能是iterator和generator函数,因此fork的参数不能是一个基本的函数,所以在我们的fork版本中,需要这么来调用:
这里我们传递给fork的是一个generator函数,在此方法中再调用delay方法。
实际上,在saga的使用中,我们传给fork的函数不必是一个generator函数,可以是一个普通的函数,这是由于saga在runForkEffect函数中做了兼容处理,它会判断函数参数的返回值是否为一个iterator,如果不是则转化为一个iterator,这里我们为了方便描述,未做此兼容。saga做的兼容代码如下:
以上是对call和fork的使用简单的对比,并且基本能了解到阻塞与非阻塞调用的实现的原理。
在使用场景上,fork的非阻塞特性更适用于后台不影响主流程的代码(比如后台打点/开启监听等),这往往是加快页面渲染的一种方式。而call更适用于需要立即获取结果的异步调用,将异步的回调转为同步的写法,这就和async、await很类似,关于generator与async、await的联系可以参考我之前的这篇 文章。
cancle
saga还提供了一个很实用的effect类型即cancel,它可以取消正在运行中的task,saga在取消task后还做了两个工作,一个是取消saga中还未完成的逻辑,另一个是可以执行清理操作,以保持前后状态的一致性,比如异步操作中的loading状态。
先看一下它是如何使用的吧:
这是官网提供的一个例子,在这个saga中实现的功能是,fork一个登陆的方法authorize,同时监听用户的剩余操作,正常情况下,登陆流程走完会执行try中的语句,如果登陆出现异常会执行catch语句,这两个流程属于正常流程。
如果在登陆的过程中,用户发起了取消操作,saga检测到发起的action的type是LOGOUT,此时就取消掉fork发起的task,authorize进入到finally语句,并通过yield cancelled()判断是否是取消操作,此时再做取消操作的特殊处理
取消任务的操作实际上使用的场景并不是很多,主要是给用户撤销或是反悔的操作,弥补用户的误操作。下面简析一下实现原理
如官网所述,若要取消正在运行的任务,middleware将调用底层Generator对象上的return。这将取消任务中的当前Effect,并跳转至finally区块(若有定义的话)。
先设定一下我们要达到的目的:
在这个例子中,先使用fork来发起一个task,在这个task中2秒后会打印出sleep_done,然后监听了用户发起的action,如果action是cancle,就执行cancle取消掉task,最终打印出cancle_end。
然后在调用中,我们在1秒后发起了cancel的action,此时由于fork的task还未完成,所以将被取消掉,task中的consle语句将不被执行到。
接下来的任务就是修改task方法和创建一个cancel方法。首先cancle仍然是effect类型:
然后再改造task方法,主要是增加了两个地方:
再添加runCancleEffect方法:
在runCancleEffect中的操作很简单,就是执行了迭代器的return方法,终止迭代器的向下执行。
测试后,执行的结果符合我们的预期。
现在修改下测试例子,在3秒后再执行chan.put('cancel'):
期望的结果是,由于此时fork的task已经执行完毕,所以cancel并不能起到效果。sleep_done会被正常打印出来。
put
put的作用就是纯粹的发起一个action到store中,功能和dispatch一致。我们已经得出了实现一个effect的一般方法了,这里对于put的实现就不再展开了。当然实现put需要和redux联系起来,毕竟还需要引用其dispatch。
总结
通过上面的实践,我们大致能了解到saga的工作原理,实现的还比较的粗浅,很多场景也未考虑到,本文的主要目的是对于saga的工作原理有个认识。saga中还提供了很多强大的功能及对异常的捕获处理,这里未涉及到。