Uknow | 优维低代码:Context 上下文
导语
优维低代码技术专栏,是一个全新的、技术为主的专栏,由优维技术委员会成员执笔,基于优维7年低代码技术研发及运维成果,主要介绍低代码相关的技术原理及架构逻辑,目的是给广大运维人提供一个技术交流与学习的平台。
连载第二十三期
《高级指引:Context 上下文》
▽
有时候我们需要在多个构件之间交换数据。在 React 中,我们通常使用 Context 来解决这样的问题。在 Storyboard 中我们也可以使用类似的机制来解决编排时处理构件间的数据交换问题。
# 示例
Context 分为定义及使用,在路由或构件处可以定义 Context,该 Context 可以在定义它的路由或构件所包裹的所有内部构件(及 useBrick)使用。
定义方式一(自由变量):
定义方式二(异步 Resolve 的自由变量):
定义方式三(绑定构件属性):
已废弃定义方式(绑定构件属性):
绑定构件属性的方式实际存储的是引用关系,在消费时实时获取。对于以上 Context,使用 <% CTX.myContextRelatedToProp %> 获取的值为 my.source-brick 的属性 sourceProp 的值。
使用方式:
在占位符中可以使用 CTX.contextName 获得名字为 contextName 的上下文的值;对于事件则提供了 context.assign 和 context.replace 两个内置动作,更多信息请参考 Events 事件 > 内建处理器:context.*。
注意:不能对绑定构件属性的 Context 执行 context.* 操作。
# 条件判断 If
对于使用自由变量或 Resolve 方式的 Context,可以配置 if 来按条件决定是否启用对应的 Context。更多关于条件判断的说明请参考 If 条件渲染。
例如:
上述配置将在开关 my-flag 关闭时,将 CTX.myData 设置为固定值 "My default value",而 my-flags 打开时,则将 CTX.myData 设置为 my.any-provider 的请求结果。被忽略的 Context 不会生效,也不会发起请求。
另外 Resolve 配置中的 if 同样有效,例如:
⊙NOTE
需要声明依赖 brick_next: ^2.22.13。
# 变更事件
有时候我们希望声明一个 Context 变量,但不对它立即赋值,而是通过特定事件触发赋值,并且希望能监听其变更事件。
可以在声明 Context 时定义 onChange,例如:
然后在特定条件发生时再对其赋值,例如:
当 Context 发生变化时,onChange 注册的事件处理器将被调用,传递的事件对象的 detail 为该 Context 的值。关于 Context 变更操作请参考 Events 事件 > 内建处理器:context.*。
⊙NOTE
使用 onChange 需要声明依赖 brick_next: ^2.19.7。
# 注意事项
在事件回调里始终能拿到当事件发生时、最新的 Context 的值,而在属性中,默认只能在构件初始时拿到 Context 的初始值,此时该 Context 相当于一个应用的常量,例如:
当 Context 值变化时,my.another-brick 的对应属性不会自动更新。框架理论上可以实现联动更新,但相对困难,后续将视实际场景需求决定是否支持。
# 构件属性追踪 Context 变更
如果希望构件的属性能跟随 Context 的变化而变化,可以在表达式前面添加一句 "track context", (逗号运算符),可以激活 Context 追踪模式,当表达式中引用的 Context 变化时,该属性将自动重新计算并赋值。
例如:
当 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 来发起请求。
⊙NOTE
context.load 将确保一个 Context 只会被加载一次,避免发起重复的数据请求。虽然 context.refresh 也可以用于主动加载一个标记了懒加载的 Context,但通常情况下这里我们应该使用 context.load 来避免发起重复的请求。
context.load 和 context.refresh 同时还支持配置回调事件:
# 主动强制更新
内置事件 context.refresh 可以强制更新一个设置了异步请求的 Context。
context.refresh 也支持配置回调事件,相关示例请见本文上一节。
# 依赖追踪
前面我们提到了 "track context" 用于构件属性自动追踪 Context 的更新,另一方面,我们还提供了让 Context 可以追踪其自身依赖的 Context 的能力。
例如:
标记 track: true 后,当 myDepA 或 myDepB 变更时(使用 context.replace/context.refresh 等),myTrackableData 会自动重新发起请求并计算得到新的值。
对于普通变量的数据也可以追踪:
⊙NOTE
对于指定了 track: true 的异步 Context,追踪到依赖变化后,将重新计算相关参数,但如果计算得到的请求参数没有发生任何变化,此时将命中缓存,不会发起新的请求。如果业务上需要强制更新数据,应使用 context.refresh,该方法将忽略请求缓存。