跳至主要內容

内置交互启动器

黄健大约 5 分钟进阶使用

内置数据交互流章节中,有简单提到过PageNow中的内置数据交互流属于主动触发式交互,也就是说必须用户与组件进行交互后,才会发起内置数据交互流,例如页面加载完成后,用户点击了Tab列表组件中某一项时,才会发起一次内置数据交互流。

有没有什么办法可以页面加载完成后,不需要用户做任何操作即可发起一次或多次内置数据交互流呢?内置交互启动器就是为了解决此类场景而存在的。

本章节基于内置数据交互流中讲解的示例为基础,如果对内置数据交互流不了解,可以先前往进行查阅了解。

内置交互启动器

使用内置交互启动器,对原有示例中的配置不需要做任何修改,仍然保持原本Tab列表与多行文本组件之前的配置,确保发送端打开发送权限,并且配置发送的内置交互变量,接收端打开接收权限,API接口地址中通过 {{}} 语法读取内置交互变量,然后在页面中添加一个内置交互启动器的组件

之后我们即可对内置交互启动器进行配置,目的是在页面中显示的去触发一次内置数据交互流,内置交互启动器中可以添加多个交互队列,一个交互队列的类型可以分为【采用预设】与【完全自定义】,下面分别对其进行讲解说明:

采用预设

通过配置预设的配置项来决定本队列需要发起的内置交互流的相关信息,值得注意的是:一个采用预设的配置只能发起一次内置交互流,如需要一次发起一组内置交互流,请使用完全自定义。

配置项说明:

  • 发起的交互变量:指定当前队列发送的内置交互流绑定的内置交互变量。(根据内置数据交互流章节中的示例,这里我们配置为 tabValue)
  • 延迟发起:可以设置延迟发起来延迟执行发起交互流
  • 发起值:发起值通过JS代码编辑,默认格式为 value = '',发起值可以通过一系列JS代码进行计算赋值,最终必须将计算结果赋值给value变量,否则发起的内置交互流中,绑定的交互变量将会默认使用undefined值。

配置完成之后,我们打开预览查看一下页面的网络请求

通过查看网络请求,我们看到其中调用了两次getText接口,第一次的str参数值为hello,这一次调用是多行文本组件自身默认起始加载调用的默认接口地址, 第二次的str参数值为123456,这一次调用则是由内置交互启动器发起的,说明我们的内置交互启动器已经生效了,在页面加载完成后,又由内置交互启动器发起了一次内置交互流来触发多行文本组件的重绘加载。

完全自定义

如果队列采用完全自定义类型,那么发起内置交互流的操作将完全由用户自定义编写的JS来执行,当我们发起内置交互流的逻辑比较复杂的时候,例如需要在一次异步调用之后发起内置交互流,或者需要发起一组内置交互流,就需要使用完全自定义类型。

通过脚本方式发起交互流的写法如下所示:

// 手动发起一次内置交互流
// 第一参数:发起的交互变量;第二参数:发送值
PnUtil.manualLaunchInteractionStream(bindingVariateName, value)

// 手动发起一组内置交互流
// 参数为一个数组,其中包含多个数据对象表示每一次交互流的相关数据
// bindingVariateName:发起的交互变量
// value:发送值
PnUtil.multiManualLaunchInteractionStream([
  {bindingVariateName: '', value: ''},
  {bindingVariateName: '', value: ''}
])

根据此前的实例,完全自定义的写法如下所示:

PnUtil.manualLaunchInteractionStream("tabValue", "123456")

受控模式

细心的伙伴应该会发现,我们使用内置交互启动器来发起内置交互流的时候,由于组件自身默认会请求一次API接口,然后又由内置交互启动器触发了一次内置交互流促使多行文本组件进行重绘又发起了一次接口请求,总共发起了两次请求,显然第一次请求是多余的, 通过【受控模式】,则可以解决此种多余请求的问题。

受控模式解释:当页面处于预览或发布状态下,组件自身初始化时将不请求数据也不执行任何初始化运行脚本,由其他地方的JS脚本或内置交互流启动器来控制发起首次请求

在以上的示例中,我们可以在多行文本组件中打开组件的受控模式,如下图所示:

打开多行文本组件的受控模式之后,页面初始化完成后,多行文本组件将不会进行自身的默认请求,后续由内置交互启动器来触发重绘进行请求,预览一下页面,再次查看网络请求:

可以看到,多行文本组件默认的str参数为hello的请求已经没有了,只有一次str=123456的请求。