原文: Comparing Redux and Relay, 作者: Mikhail Novikov (reindex CTO & Co-founder)
注: 译文内容根据个人对Redux和Relay的使用经验而翻译, 如发现任何问题, 望指正(可留言或Email: [email protected]).
开发React应用, 有时必须要解决管理客户端state的问题. 现代应用程序不应总是等服务器的响应, 切换页面就要重新请求, 而应该让页面展现尽可能地快. 应用的状态管理层(也可称为缓存层或模型层)正是负责处理这些逻辑.
Redux和Relay在应用中就是负责这一层. 本文会用一些常见的示例代码来比较这两个库。
架构概述
Redux和Relay的灵感都源于Flux(一种架构模式用来设计应用程序, 和MVC属同类). Flux的基本思路是让数据从应用的数据存储中心(Stores)到组件(Components)始终单向流动(单向数据流). 组件调用Action创建函数(Action Creators), 将Actions发送给Store. Flux最初由Facebook提出, 但是他们并没有提供一个已集成好Flux的现成库. 之后, 开源社区很快出现了许多Flux实现, 还有更多自定义实现在闭源代码库中 :). Flux很适合作为React的数据模型, 因为它禁止数据从子组件向上传递到store, 数据的修改必须通过dispatch(action)完成.
Redux
Redux简化了Flux架构. 把Flux中多个Store的概念简化成只有一个Store.
Store的数据可以通过转换方法传给组件(provider把store的数据传给connect, 让它把这些数据传给组件).
Store可以通过reducers处理action. 最大的区别是, reducer是纯函数, 接收2个参数, 现有的state(previousState)和action, 并返回新的state.
Action, 在Flux中通常是改变state的操作, 在Redux中是函数式转换(Flux里的action是函数的形式，但在redux里是普通的js对象). 任何数据都可以储存在Redux store.
Redux是一个很小的库. Action可以通过中间件来拦截或改变, 开源社区中也有很多中间件可用. 通过中间件, 编写功能完善的Redux应用会更容易.
Relay
Relay在很多方面也受到Flux启发. 只有一个store，通过action去改变(在Relay中称为Mutations). 然而, Relay禁止开发人员直接控制Store的内容. 相反, Relay根据GraphQL查询语句去自动处理, 储存或修改服务端数据.
组件通过编写GraphQL查询片段(fragments)来描述依赖的数据, Relay会根据当前组件树中所有组件的依赖数据描述去自动优化查询(把多个组件的请求合并为1次GraphQL请求).
对Store的修改(写操作)可以通过mutation(变更)来实现, mutations在客户端和服务器端都修改数据, 保持数据一致. 不同于Redux, 在Relay中只能变更在服务端声明过的数据, 并且服务器必须有一个GraphQL服务.
Relay提供了许多很赞的功能. Relay负责所有数据的获取, 并确保所需数据无异常. Relay有完善的分页支持, 很适合类瀑布流类的场景(无限滚动). Relay mutations可以做到乐观更新(Optimistic Update), 即: 页面UI先改变, 再以服务器返回结果为准更改页面UI, 如果出错会回滚.