首页 > 其他分享 >优维低代码:Context 上下文

优维低代码:Context 上下文

时间:2022-10-08 18:01:42浏览次数:59  
标签:Context value context 优维低 brick 上下文 my name

优维低代码:Context 上下文_ide

优维低代码:Context 上下文_ide_02

导语

优维低代码技术专栏,是一个全新的、技术为主的专栏,由优维技术委员会成员执笔,基于优维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,该方法将忽略请求缓存。


标签:Context,value,context,优维低,brick,上下文,my,name
From: https://blog.51cto.com/u_15605878/5738438

相关文章

  • golang 使用 context 进行并发控制(转)
    转自以下两篇文章:并发控制-context篇、Go通关11:并发控制神器之Context1.前言context翻译成中文是”上下文”,即它可以控制一组呈树状结构的goroutine,由于goroutine派生......
  • 聊聊Linux中CPU上下文切换
    目录什么是CPU上下文CPU上下文切换上一任务的CPU上下文保存在哪?进程上下文切换内核空间和用户空间top命令查看CPU资源系统调用进程上下文切换和系统调用的区别?进程切换的......
  • 关于request.getServletPath(),request.getContextPath()的总结
    最近对于request中的几种“路径”有点混淆,查找网上资源都没有很好的总结,希望此文章能够帮助我理解一下这几种“路径”。+++++++++++++++++++++++++++++++++++++++++++++++......
  • 关于 SAP UI5 ODataModel.createEntry 返回的 context 对象
    在返回的上下文中使用创建的API返回的Promise对象,以便在持久化或重置时获得通知。使用isTransientAPI,您可以确定创建的上下文是transient的还是持久的;请注意,对于尚......
  • 前端程序员学习 Golang gin 框架实战笔记之二分析 context
    上一节:前端程序员学习Golanggin框架实战笔记之一开始玩gin之前讲到了如何使用gin,这一节我们来分析和调试一下它的代码。New()第一行的gin.New(),其实还有一种......
  • 深入理解JS作用域链与执行上下文
    变量提升:变量提升(hoisting)。我可恨的var关键字:你读完下面内容就会明白标题的含义,先来一段超级简单的代码:<scripttype="text/javascript">varstr='Hello......
  • GoLang Context
    GoLangContext介绍在开发大型应用是,尤其是服务器软件中,有时除了函数自身工作所需的信息之外,了解更多关于它正在执行的环境的信息是有帮助的。例如,web服务器器函数正在处......
  • ContextCapture-硬件配置推荐
    ContextCapture倾斜摄影的空三计算、三维建模应用。非常耗费硬件资源,适当调整硬件配置,可以显著提高模型处理时间。硬件常见问题随着倾斜摄影建模算法成熟,应用越来越广泛,......
  • spring:beanfactory与applicationcontext的设计
    beanfactory接口提供的方法:getBean,getBeanProvider,containsBean,isSingleton,getType,getAliaseslistableBeanFactory:不会取到手动注册的bean,为什么要这么做呢,因为有些bea......
  • 关于 SAP UI5 ODataModel.createEntry 返回的 context 对象
    在返回的上下文中使用创建的API返回的Promise对象,以便在持久化或重置时获得通知。使用isTransientAPI,您可以确定创建的上下文是transient的还是持久的;请注意,对于尚......