接上一篇 https://www.cnblogs.com/mrzhu/p/12403571.html
Flux 的初衷:
一个应用通常包含少许主要功能, 这些功能由几个顶层大组件来实现, 而顶层大组件通常并不是一个整体, 而是会被继续拆分为多个独立的具有通用功能的小组件
当项目逐渐复杂的时候, 可能会存在顶层大组件相互嵌套的情况, 如何来维护组件之间的信息流动?
Flux 推崇的 UI 状态保存在 store 中与 react 的双向绑定机制 (UI 数据和 UI 状态与 data 关联) 冲突吗?
react 是 view 层的一个框架, flux 推崇将 UI 状态全部移植到 store 与 react 的 data 与 view 的双向绑定并不冲突, 因为 react 的双向绑定是解决数据与视图的映射问题, 而 flux 存储 UI 状态 是解决组件数据共享问题. 我们完全可以在组件内部定义多个 data 以完成组件内部的私有交互, 同时把需要共享的 UI 状态 传给 flux, 让他来进行全局处理, 当 flux 中的 UI 状态改变的时候, 我们会把新的 UI 状态赋值给 data 以完成更新.
UI = render(data)的理解:
render 方法的参数 data 依赖于 flux 架构中的 state, 我们在组件中定义 render 方法的时候, render 应该是一个纯函数, 所有的变量都通过 data 属性传入进来, 然后应用监听 store 的改变, 一旦 store 改变 则拿到 store 中的 state, 重新执行 render(data=state), 之所以现在的组件没有这样做 是因为, 组件内部存在 data, 并且监听了 data, 当我们改变 data 的值的时候, 框架自动帮我们执行了 render(data=state), 但是我们应该明白 UI=render(data)的本来面目.
Redux 与 flux 的不同:
reduc 只有一个 store, 而且使用纯函数模式 每次返回一个新的 state
将一些可以自动化处理的事情给封装了起来, 比如注册事件, 自动获取值更新
Flux 中的元素:
Store:
store 是具有特定功能导向的, 与业务强耦合的, 即改变 store 状态的代码 应该就在的放在 store 中
因为 store 包含了业务逻辑, 所以为了方便管理, store 可以分多个
store 的执行顺序取决于在 dispatch 的注册顺序, 进而取决于 import 的引入顺序
store 导出方式是单例模式
Action:
action 就像一个邮件包, flux 系统的入口点并不关心这些包里面的数据长什么样子, 只关心它去哪里
动作需要单独划分模块管理
action 如果太颗粒化, 势必导致 view 层 在一个任务里面调用太多的 action 来处理任务. 可以构建一个更大的 action(这个 action 组合了两个独立的小 action)来实现更复杂的功能
Dispatch:
action 与 store 的连接器, store 在 dispatch 中注册方法, action 通过 dipatch 触发方法
waitFor 的用法是处理存储器之间的依赖, 表示在处理当前方法之前需要先去处理 waitFor 里面的 id 对应的 diapatch 中注册的方法
View:
视图要做的仅仅是展示数据和传递用户行为, 不做过多的业务处理
异步方案:
action 总是返回 promise, 这样的好处是 允许异步任务的同步执行, 同时可以让开发人员自己处理错误信息
store 代码例子:
来源: http://www.bubuko.com/infodetail-3446500.html