导语
优维低代码技术专栏，是一个全新的、技术为主的专栏，由优维技术委员会成员执笔，基于优维7年低代码技术研发及运维成果，主要介绍低代码相关的技术原理及架构逻辑，目的是给广大运维人提供一个技术交流与学习的平台。
连载第二十三期
《高级指引：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 context: – name: myContextRelatedToProp property: sourceProp
已废弃定义方式（绑定构件属性）：
bricks: – brick: my.source-brick exports: sourceProp: CTX.myContextRelatedToProp
绑定构件属性的方式实际存储的是引用关系，在消费时实时获取。对于以上 Context，使用<%CTX.myContextRelatedToProp %>获取的值为my.source-brick的属性sourceProp的值。
使用方式：
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: target: my.submit-provider method: resolve args: – q: “<% CTX.myContext %>”
在占位符中可以使用CTX.contextName获得名字为contextName的上下文的值；对于事件则提供了context.assign和context.replace两个内置动作，更多信息请参考 Events 事件 > 内建处理器：context.*。
注意：不能对绑定构件属性的 Context 执行context.*操作。
# 条件判断 If
对于使用自由变量或 Resolve 方式的 Context，可以配置if来按条件决定是否启用对应的 Context。更多关于条件判断的说明请参考 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”
⊙NOTE
需要声明依赖brick_next: ^2.22.13。
# 变更事件
有时候我们希望声明一个 Context 变量，但不对它立即赋值，而是通过特定事件触发赋值，并且希望能监听其变更事件。
可以在声明 Context 时定义onChange，例如：
path: “/my-app”context: – name: “myData” value: status: “loading” # `onChange` 和其它事件处理接口一样， # 可以设置为单个或多个（数组）事件处理器。 onChange: target: “#myBrick” properties: someProp: “<% EVENT.detail.status %>” # 另注：不能对绑定构件属性的 Context 设置 `onChange` 事件。
然后在特定条件发生时再对其赋值，例如：
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.*。
⊙NOTE
使用onChange需要声明依赖brick_next: ^2.19.7。
# 注意事项
在事件回调里始终能拿到当事件发生时、最新的 Context 的值，而在属性中，默认只能在构件初始时拿到 Context 的初始值，此时该 Context 相当于一个应用的常量，例如：
bricks: – brick: my.another-brick properties: oneProp: “<% CTX.myContext %>”
当 Context 值变化时，my.another-brick的对应属性不会自动更新。框架理论上可以实现联动更新，但相对困难，后续将视实际场景需求决定是否支持。
# 构件属性追踪 Context 变更
如果希望构件的属性能跟随 Context 的变化而变化，可以在表达式前面添加一句”track context”, （逗号运算符），可以激活 Context 追踪模式，当表达式中引用的 Context 变化时，该属性将自动重新计算并赋值。
例如：
bricks: – brick: my.any-brick properties: anyProp: “<% ‘track context’, CTX.myContext + CTX.myAnotherContext %>”
当myContext或myAnotherContext任一值改变时，my.any-brick将重新计算并赋值给属性anyProp。注意”track context”仅用于第一层属性赋值，可以用于自定义模板，但目前不能用于useBrick的构件属性。
⊙NOTE
这里参考了”use strict”;的用法，并利用了逗号运算符返回最后一个运算对象的特性。
⊙NOTE
使用”track context”需要声明依赖brick_next: ^2.27.24。
# 懒加载
默认情况下，如果 Context 定义为 Resolve，它会在页面加载前发起请求并阻塞渲染，但有些数据并不着急需要，可能只需在特定条件下再发起请求即可（例如打开抽屉时）。这时可以标记resolve.lazy: true将它设置为懒加载，该数据将不会默认发送请求，需要开发者在特定条件下主动触发context.load来发起请求。
context: – name: “myLazyData” resolve: useProvider: “my-provider” lazy: true # 可以为懒加载的数据配置一个初始值，默认为 `undefined` value: “Initial”brick: “my-brick”properties: dataSource: ‘<% “track context”, CTX.myLazyData %>’events: button.click: action: “context.load” args: – “myLazyData”
⊙NOTE
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 事件详情为更新后的 Context 值 – “<% EVENT.detail %>” error: action: console.error args: # Error 事件详情为错误对象 – “<% EVENT.detail %>” finally: action: console.info
# 主动强制更新
内置事件context.refresh可以强制更新一个设置了异步请求的 Context。
brick: “my-brick”events: button.click: action: “context.refresh” args: – “myAnyData”
context.refresh也支持配置回调事件，相关示例请见本文上一节。
# 依赖追踪
前面我们提到了”track context”用于构件属性自动追踪 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 %>”
⊙NOTE
对于指定了track: true的异步 Context，追踪到依赖变化后，将重新计算相关参数，但如果计算得到的请求参数没有发生任何变化，此时将命中缓存，不会发起新的请求。如果业务上需要强制更新数据，应使用context.refresh，该方法将忽略请求缓存。
记录沿途的心情。那样的生活才是我想要的。
