Context
有时候我们需要在多个构件之间交换数据。在 React 中，我们通常使用 Context 来解决这样的问题。在 Storyboard 中我们也可以使用类似的机制来解决编排时处理构件间的数据 交换问题。
示例
Context 分为定义及使用，在路由处可以定义 Context，该 Context 可以在定义它的路由的所有内部构件（及 useBrick）使用。
定义方式一（自由变量）：
routes:
- path: "${APP.homepage}/your-page"
context:
- name: myContext
# 初始 `value` 可以使用表达式。
value:
quality: good
# 初始 `value` 是可选的。
- name: myAnotherContext
定义方式二（异步 Resolve 的自由变量）：
routes:
- path: "${APP.homepage}/your-page"
context:
- name: myAsyncContext
resolve:
useProvider: my-provider
# 默认将使用 Provider 返回的数据作为该 Context 的值（brick_next >= 1.25.2 支持）。
# 如果需要转换数据，注意需使用 transform 后的 value 值。
transform:
# `CTX.myAsyncContext` 的值将是 `DATA.hostname`。
value: "<% DATA.hostname %>"
使用方式：
bricks:
- brick: my.source-brick
events:
something.change:
# - 'context.assign': use `Object.assign(context, newValue)` to update current context.
# function contextAssign(contextName, newValue) => void
#
# - 'context.replace': use `context = newValue` to replace current context.
# function contextReplace(contextName, newValue) => void
action: "context.assign"
args:
- myContext
- quality: better
- brick: my.trigger-brick
events:
something.submit:
useProvider: my.submit-provider
args:
- q: "<% CTX.myContext %>"
在表达式中可以使用 CTX.contextName 获得名字为 contextName 的上下文的值；对于事件则提供了 context.assign 和 context.replace 两个内置动作，更多信息请参考 Events 事件 > 内建处理器：context.*。
条件判断 If
Context 可以配置 if 来按条件决定是否启用它。更多关于条件判断的说明请参考 If 条件渲染。
例如：
context:
- name: "myData"
if: '<% !FLAGS["my-flag"] %>'
value: "My default value"
- name: "myData"
if: '<% FLAGS["my-flag"] %>'
resolve:
useProvider: "my.any-provider"
上述配置将在开关 my-flag 关闭时，将 CTX.myData 设置为固定值 "My default value"，而 my-flags 打开时，则将 CTX.myData 设置为 my.any-provider 的请求结果。被忽略的 Context 不会生效，也不会发起请求。
另外 Resolve 配置中的 if 同样有效，例如：
context:
- name: "myData"
resolve:
if: '<% FLAGS["my-flag"] %>'
useProvider: "my.any-provider"
变更事件
有时候我们希望声明一个 Context 变量，但不对它立即赋值，而是通过特定事件触发赋值，并且希望能监听其变更事件。
可以在声明 Context 时定义 onChange，例如：
path: "/my-app"
context:
- name: "myData"
value:
status: "loading"
# `onChange` 和其它事件处理接口一样，
# 可以设置为单个或多个（数组）事件处理器。
onChange:
target: "#myBrick"
properties:
someProp: "<% EVENT.detail.status %>"
然后在特定条件发生时再对其赋值，例如：
brick: "any-brick"
events:
success:
action: "context.assign"
args:
- status: "loaded"
error:
action: "context.assign"
args:
- status: "failed"
当 Context 发生变化时，onChange 注册的事件处理器将被调用，传递的事件对象的 detail 为该 Context 的值。关于 Context 变更操作请参考 Events 事件 > 内建处理器：context.*。
注意事项
在事件回调里始终能拿到当事件发生时、最新的 Context 的值，而在属性中，默认只能在构件初始时拿到 Context 的初始值，此时该 Context 相当于一个应用的常量，例如：
brick: my.another-brick
properties:
oneProp: "<% CTX.myContext %>"
默认情况下，当 Context 值变化时，my.another-brick 的对应属性不会自动更新。
构件属性追踪 Context 变更
如果希望构件的属性能跟随 Context 的变化而变化，可以为表达式添加标记位 =，使用 <%= %> 来激活绑定模式，当表达式中引用的 Context 变化时，该属性将自动重新计算并赋值。
例如：
brick: my.any-brick
properties:
anyProp: "<%= CTX.myContext + CTX.myAnotherContext %>"
当 myContext 或 myAnotherContext 任一值改变时，my.any-brick 将重新计算并赋值给属性 anyProp。绑定模式也可以用于自定义模板和 useBrick 的构件属性，但注意，它仅适用于构件的第一层属性赋值。
我们还支持使用类似 <% "track context", CTX.myData %> 的形式来激活绑定模式。
懒加载
默认情况下，如果 Context 定义为 Resolve，它会在页面加载前发起请求并阻塞渲染，但有些数据并不着急需要，可能只需在特定条件下再发起请求即可（例如打开抽屉时）。这时可以标记 resolve.lazy: true 将它设置为懒加载，该数据将不会默认发送请求，需要开发者在特定条件下主动触发 context.load 来发起请求。
context:
- name: "myLazyData"
resolve:
useProvider: "my-provider"
lazy: true
# 可以为懒加载的数据配置一个初始值，默认为 `undefined`
value: "Initial"
brick: "my-brick"
properties:
dataSource: "<%= CTX.myLazyData %>"
events:
button.click:
action: "context.load"
args:
- "myLazyData"
context.load 将确保一个 Context 只会被加载一次，避免发起重复的数据请求。虽然 context.refresh 也可以用于主动加载一个标记了懒加载的 Context，但通常情况下这里我们应该使用 context.load 来避免发起重复的请求。
context.load 和 context.refresh 同时还支持配置回调事件：
events:
button.click:
action: "context.load"
args:
- "myLazyData"
callback:
success:
action: console.log
args:
# Success 事件详情的 `value` 为更新后的 Context 值
- "<% EVENT.detail.value %>"
error:
action: console.error
args:
# Error 事件详情为错误对象
- "<% EVENT.detail %>"
finally:
action: console.info
异步加载
设置 resolve.async: true 可以将一个 Context 标记为异步加载，该数据请求不会阻塞渲染。与 lazy 类似，页面会先以该 Context 的默认值进行渲染，在页面完成 Mount 后，当数据加载完成后会触发其数据变更事件，设置了追踪标记的相关构件属性将自动更新。
context:
- name: "myAsyncData"
resolve:
useProvider: "my-provider"
async: true
# 可以为异步加载的数据配置一个初始值，默认为 `undefined`
value: "Initial"
brick: "my-brick"
properties:
# 在构件属性定义中使用异步加载的数据时，通常应该设置追踪绑定标记
dataSource: "<%= CTX.myAsyncData %>"
注意 async 与 lazy 的不同：
lazy使得一个 Context 的请求不会自动发起，需要主动调用context.load，其最早只能发生在 page load 之后，因此适合将页面的次要数据设置为lazy，这样可以使得其他更重要的数据优先被加载；async的 Context 也不会阻塞页面渲染，但仍会尽早地自动发起请求，因此对于页面的主要数据，适合设置为async，这样使得页面既不被特定请求阻塞，又可以更早地将主要数据呈现给用户。
如果 async 的数据加载在页面 Mount 之前就已完成，其数据变更仍会延迟到 Mount 之后再触发。
主动强制更新
内置事件 context.refresh 可以强制更新一个设置了异步请求的 Context。
brick: "my-brick"
events:
button.click:
action: "context.refresh"
args:
- "myAnyData"
context.refresh 也支持配置回调事件，相关示例请见本文上一节。
依赖追踪
前面我们提到了 <%= %> 用于构件属性自动追踪 Context 的更新，另一方面，我们还提供了让 Context 可以追踪其自身依赖的 Context 的能力。
例如：
context:
- name: "myTrackableData"
track: true
resolve:
useProvider: my-provider
args:
- <% CTX.myDepA %>
- <% CTX.myDepB %>
标记 track: true 后，当 myDepA 或 myDepB 变更时（使用 context.replace/context.refresh 等），myTrackableData 会自动重新发起请求并计算得到新的值。
对于普通变量的数据也可以追踪：
context:
- name: myTrackableData
track: true
value: "<% CTX.myDepA + CTX.myDepB %>"
对于指定了 track: true 的异步 Context，追踪到依赖变化后，将重新计算相关参数，但如果计算得到的请求参数没有发生任何变化，此时将命中缓存，不会发起新的请求。如果业务上需要强制更新数据，应使用 context.refresh，该方法将忽略请求缓存。
追踪带条件判断的 Resolve
有些时候我们希望根据条件判断分别使用远端数据或静态数据、并且该条件是动态变化的，对于这种场景可以同时设置 track、resolve.if 和 value，即可激活追踪条件判断。
当 resolve.if 解析为真时，将调用 Provider 获取远端数据；反之当其解析为假时，将使用静态值 value。另外注意此时 resolve 和 value 中使用到的任意其他 Context 数据变化时都将触发其重新计算。
context:
- name: "useRemote"
- name: "myConditionalData"
resolve:
if: "<% CTX.useRemote %>"
useProvider: "my-provider"
value: "My fallback value"
track: true
追踪带条件判断的 Resolve 依赖 brick_next: ^3.9.1 || ^2.91.1。
变更历史
| 组件 | 版本 | 变更 |
|---|---|---|
| brick_next | 3.9.1 | 支持追踪带条件判断的 Resolve |
| - | 3.4.1 | 支持 async |
| - | 3.0.0 | 不可以定义重复的 Context（使用 if 进行判断除外），不可以引用未定义的 Context |