feat(): support batchUpdate context

[SailorF]

依赖检查

组件之间的依赖声明，是微服务组件架构下的重要信息，请确保其正确性。

请勾选以下两组选项其中之一：

• 本次 MR 没有使用上游组件（例如框架、后台组件等）的较新版本提供的特性。

或者：

• 本次 MR 使用了上游组件（例如框架、后台组件等）的较新版本提供的特性。
• 在对应的文件中更新了该上游组件的依赖版本（或确认了当前声明的依赖版本已包含本次 MR 使用的新特性）。

提交信息检查

Git 提交信息将决定包的版本发布及自动生成的 CHANGELOG，请检查工作内容与提交信息是否相符，并在以下每组选项中都依次确认。

破坏性变更是针对于下游使用者而言，可以通过本次改动对下游使用者的影响来识别变更类型：

• 下游使用者不做任何改动，仍可以正常工作时，那么它属于普通变更。
• 反之，下游使用者不做改动就无法正常工作时，那么它属于破坏性变更。

例如，构件修改了一个属性名，小产品 Storyboard 中需要使用新属性名才能工作，那么它就是破坏性变更。
又例如，构件还没有任何下游使用者，那么它的任何变更都是普通变更。

破坏性变更：

• ⚠️ 本次 MR 包含破坏性变更的提交，请继续确认以下所有选项：
• 没有更好的兼容方案，必须做破坏性变更。
• 使用了 feat 作为提交类型。
• 标注了 BREAKING CHANGE: 你的变更说明。
• 同时更新了本仓库中所有下游使用者的调用。
• 同时更新了本仓库中所有下游使用者对该子包的依赖为即将发布的 major 版本。
• 同时为其它仓库的 Migrating 做好了准备，例如文档或批量改动的方法。
• 手动验证过破坏性变更在 Migrate 后可以正常工作。
• 破坏性变更所在的提交没有意外携带其它子包的改动。

新特性：

• 本次 MR 包含新特性的提交，且该提交不带有破坏性变更，并使用了 feat 作为提交类型。
• 给新特性添加了单元测试。
• 手动验证过新特性可以正常工作。

问题修复：

• 本次 MR 包含问题修复的提交，且该提交不带有新特性或破坏性变更，并使用了 fix 作为提交类型。
• 给问题修复添加了单元测试。
• 手动验证过问题修复得到解决。

杂项工作：

即所有对下游使用者无任何影响、且没有必要显示在 CHANGELOG 中的改动，例如修改注释、测试用例、开发文档等：

• 本次 MR 包含杂项工作的提交，且该提交不带有问题修复、新特性或破坏性变更，并使用了 chore, docs, test 等作为提交类型。

[cypress]

Passing run #6655 ↗︎

0

6

0

0

0

Details:

Merge fffc09b into 8a73c0b...
Project: next-core	Commit: 9a74e86811 ℹ️
Status: Passed	Duration: 00:36 💡
Started: May 17, 2023 8:14 AM	Ended: May 17, 2023 8:15 AM

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[codecov]

Codecov Report

Merging #3064 (0a27724) into master (8a73c0b) will increase coverage by 0.04%.
The diff coverage is 100.00%.

❗ Current head 0a27724 differs from pull request most recent head fffc09b. Consider uploading reports for the commit fffc09b to get more accurate results

@@            Coverage Diff             @@
##           master    #3064      +/-   ##
==========================================
+ Coverage   93.21%   93.25%   +0.04%     
==========================================
  Files         296      296              
  Lines        9696     9757      +61     
  Branches     1829     1845      +16     
==========================================
+ Hits         9038     9099      +61     
  Misses        412      412              
  Partials      246      246              

Impacted Files	Coverage Δ
packages/brick-kit/src/core/StoryboardContext.ts	94.71% <100.00%> (+1.50%)	⬆️
packages/brick-kit/src/internal/bindListeners.ts	88.88% <100.00%> (+0.49%)	⬆️

[weareoutman]

还有这个问题，不知道我上次说清楚没，最好同步考虑下：

[SailorF]

目前已经支持这种场景，因为在批处理中（值更新过程）不会提交变更事件，需要等变更列表全部更新完之后，才会统一
执行dispatchEvent（它会自行分析依赖，并触发影响到的值的变更）; 并且目前这种操作是同步模式，对过往编排的影响应该不大；

场景：

- name: a
   value: 1
- name: b
   value: 2
- name: c
   value: a + b
- name: d
   value: c + 1

普通变更：

- action: state.update
   args:
      -  a
      -  a + 1
- action: state.update
   args:
      -  b
      -  b + 1

普通变更 dispatchEvent 的执行顺序是: a -> c -> d -> b -> c -> d

批量变更：

- action: state.update
   args:
      -  name: a
          value: a + 1
      -  name: b
          value: b + 1

批量变更 dispatchEvent 的执行顺序是： a -> b -> c -> d

[weareoutman]

场景不太一样，

假设 b 依赖 a，c 依赖 a 和 b:

- name: a
- name: b
  value: <% STATE.a %>
- name: c
  value: <% STATE.a + STATE.b %>

只更新 a:

action: state.update
args:
  - a
  - ...

这种情况，目前是 a 变更后，c 应该会触发两次更新：

   b -- c
  / 
a
  \
   c

具体 @willc001 看看是不是这样的

[SailorF]

   b -- c
 / 
a
 \
  c

实际如果只更新 a 并不会有这种场景的出现，因为批处理阻止了 context 值变更后的 dispatchEvent 事件；在变更过程中，我们会将变更列表收集起来，称之为 updateContexts, 然后根据 updateContexts 计算出其依赖链称之为 affectContexts, 然后等待值更新后，才触发事件变更；
这里 updateContexts = { a }; affectContexts = { b, c }
所以正确的执行顺序应该是： a -> b - c

[weareoutman]

注意这里不是走 state.update 数组，而是之前的更新单个 state 的语法

[SailorF]

如果是之前的写法那 c 就会变更 2 次了，这种是符合之前的预期的