@czwcode/rdx NPM

用处

通过提供组件的任务流管理器，定向更新组件内容
减少重复渲染
避免任务重复执行
避免由于请求返回时间的不确定性，导致展示数据出现问题
记录所有当前节点的运行状态，避免用户进行过多无用的操作

如何使用

feature

taskItem 组件更新
循环依赖的调度(保证运行时不成闭环)
阻塞第一次渲染，渲染统一由 context 管控

2.x 功能迭代

在 1.0 的版本基础上，新增调度中心的概念，调度中心可以统一管理默认值的数据，并检查是否要发起新的请求
通过 forceUpdate & shouldComponentUpdate 的组合方式强管控下层组件的渲染逻辑，
ReactFieldContext 新增了两个新的参数， value & state，并新增了两个校验方法，用来对每一个调度是否触发进行判断
immer 变为必须的依赖，通过 immer 可以很好的通过 shallowEqual 的方式校验调度的更新

功能设计

context 共享中心
- 状态
- 任务信息
- 节点数据
- 节点状态
  - 节点当前运行装填
  - 节点运行失败的错误信息
  - cancelMap 取消队列
- Action
  - 新增
  - 更新
  - 删除
任务调度中心
- 单个任务执行单个组件内部数据发生改变
- 多任务执行共享中心派发
- dfs 任务执行初始化任务执行
生命周期
- 初始化阶段
  - init 初始化
  - beforeExecute
  - execute
  - onPreChange
  - onChange
  - onError
- 更新阶段
  - 更新阶段初始化状态
  - beforeExecute
  - execute
  - onPreChange
  - onChange
  - onError
- taskInfo 更新
- addTask 新增的任务节点，会触发任务的节点的任务执行
- removeTask 移除任务节点，会触发所有依赖此节点的任务重新执行
- 刷新
群组任务(分为两个状态：控制下游群组的状态 | 不控制下游群组的状态)
- 下游节点状态更新
- 下游节点状态不更新

问题

当新增节点的时候，后续新增的节点的 dispatch 状态会晚于 useEffect

冒烟逻辑测试

任务调度是否正常执行，调度状态是否正常
组件接受的数据是否和 state 中的数据状态保持一致
任务新增是否用重新刷新
组件移除，依赖组件是否刷新
任务属性更新是否会刷新
任务是否按照依赖关系正常执行

3.0版本

管理模块状态，并支持组件间共享状态
获取依赖的组件的状态
模块状态改变了，通知所有的下游响应式函数进行执行
修改模块状态

视图渲染，脏检测机制
状态更新批处理机制
依赖包的缩减

思考

响应式函数、状态组件、管道
reset一个watcher，用户需要感知到上层是在执行reset
(局部状态怎么融合，怎么合并)https://img.alicdn.com/tfs/TB1TAoIh_M11u4jSZPxXXahcXXa-974-520.png

可以通过定义新的rdxNode类型来达到目的

和reducer怎么融合

可以通过定义新的rdxNode类型来达到目的

检测到环的方式怎么处理

依赖收集

声明式收集
自动化收集
- mobx
- vue
- recoil
- concent
- https://github.com/nx-js/observer-util?spm=ata.13261165.0.0.367462b4wTnzlR
- https://github.com/alloc/wana?spm=ata.13261165.0.0.367462b4wTnzlR

TODO

(废弃)~~useRdxReaction 支持id和rdxNode两种类型作为依赖条件~~
utils waitForNone（立即返回加载器）, waitForAll(等待所有依赖执行完成后返回), waitForAny(至少一个依赖更新了), noWait调研
(完成)selctorFamily, (暂时没有场景)atomFamily 设计
(待开发)scope and weight 如何接入？
(待开发)环检测后事件流逻辑是否有控制的必要，针对环情况的优化
(开发中)如何结合表单场景, 流的思路和常规代码思路结合
状态管理流的状态分析
(重要·)设置数据时的依赖环检测策略
- 目前暂时没有很好的检测策略
控制onChange回调的时机

冒烟逻辑测试

atom， watcher， reaction 单独的用例
reaction、watcher使用atom，的get 链路
reaction、watcher使用atom，的set 链路和reset链路

理论依据

主观输入(用户主动触发的场景)
所有触发任务执行了一次(保证页面是最新的状态触发的) 问题：

事件流使用情况分析

本地状态共享
远程状态获取&共享
动态入参的方式获取组件状态(可以使用外部的参数，还可以使用其他节点的共享数据)
动态入参的方式生成组件观察的状态

已知问题

(完成)selector中的依赖，如果是异步的情况，没有办法识别出来，因为通过调用该方法的方式识别依赖的，而不是等这个方法执行完成之后识别依赖的。解决方案：异步依赖有两种情况，一种是被观察这比观察者捕获依赖的顺序要快，这个时候不需要额外的处理，因为依赖检测可以在被观察者数据生成之前完成第二种是被观察者比观察者执行的要慢，那么观察者显然会先执行完，这个时候可以捕获到依赖，但是结果值不可以信任，需要重新获取这次的数据，并停止之前的依赖
(完成)watcher的值是一个虚拟的属性，不应该存储在全局的store中
(完成)rdxstore的数据如何序列化，并在下次使用，rdxstore应该是一个完全非受控的状态，只应该有默认的state设置，不应该有value和onChange
(完成)可以构造一个操作符，可以观察全局节点的执行情况，这样可以方便表单实现数据预览状态，也可以提供给提交的组件一个获取全局数据的机会
作用域的概念该怎么来营造，因为并不是所有东西都是立即执行，思路1：可以通过另外一个rdx来构造
(废弃)初始化设置默认值的代码有问题，需要考虑受控和非受控情况的区别
onChange的正确触发时机。默认值初始化的过程，不一定执行了调度，怎么监控这种情况
- 1. 任务执行完成
- 1. 任务初始化的时候 addOrUpdateTask
- 1. 数据变更的时候，如果没有下游任务，则触发，如果有则等待下游任务触发。
(完成)造一个监听所有数据的Watcher
atom原子设置数据时的问题，设置数据也可能是闭环，
(改造后的)状态管理和分析