页面嵌套是UIOTOS的最大特色，区别于其他前端低代码/零代码、WEB组态、大屏设计器。这也是实现复杂前端界面的关键。
文档：https://www.yuque.com/liuhuo-nc809/uiotos/fa6vnvggwl9ubpwg
既然有嵌套，就有加载。比如页面嵌套到对话框，作为表单弹窗；嵌套到页签，作为多页签内容。
那么问题来了，弹窗也好，页签也罢，怎么样在上层，给内嵌页面的组件通信？比如上层传数据，给到嵌套页面的表单组件。
方式1：属性继承和连线（或工作流）
本篇不展开，这是UIOTOS中除了嵌套之外的核心特色。这里要说连线有局限：一对多通信时，多根线变得杂乱，本来直观是优势，变成了劣势。
文档：https://www.yuque.com/liuhuo-nc809/uiotos/pcw3859p82d2h7i8
方式2：收发器“无线”通信
如下所示，收发器可以通过主题、地址、内容（类似MQTT）的方式，实现一对一、一对多通信，作为连线流程的补充。
那么，重点来了：
如果接收器的内嵌页，在发送器发送之后，才动态加载，数据会不会丢失？还有，多个页签，挨个切换初始加载，能分别收到已发送吗？
可以。先看测试示例和效果，再来分析这里的实现机制和原理。
- 1个内嵌页，接收器内容给文本框；
- 上层页面有Tab组件，3个页签，都嵌套上面内嵌页；
- 上层页面有对话框，同样嵌套上面内嵌页；
- 上层页面中，按钮触发发送器；另一个按钮触发弹窗（每次会重加载）
运行效果：
- 发送器执行后，第1个页签收到并显示，属于正常。
- 切换到页签2、3时，也能看到内容，说明出事加载时，虽然接收器初始监听晚于发送器，但是不影响也能接收到。
- 对话框初始弹窗，也能看到内容；但是第二次弹窗，就看不到发送器此前发送的内容了。
原理分析
发送缓存：UIOTOS对发送器做了全局缓存，这样动态加载的页面内，接收器后初始化，也能接收到先发送的数据，避免丢失。具体说明：
通过window全局对象，发送器每次发送，将自身的全局标识作为key，要发送的内容作为value（包括主题、内容、目标地址等）。因此，每次发送，会覆盖前一次的缓存。
接收器初始化监听时，会从全局缓存按时间倒序遍历，一旦有主题、地址匹配通过，就会响应。实现后先发送、后监听，保证数据不丢失。
消费模式：UIOTOS消息收发提供了消费者模式，一旦从缓存成功消费，接收器将把自身全局标识，追加到全局缓存的消息中，避免重复响应。
因为如果只缓存，并且每次都响应，会出现不合理的情况，比如下面：
表单增删改查（CURD）中，查看表单页，要隐藏提交按钮；新增表单页则要有提交。由同一个表单页面，嵌套来实现时，通过接收器可以来处理：判断是查看时，隐藏提交按钮，否则显示。效果如下：
点击查看时，发送器发送；而点击新增时，只打开表单，不用发送器，希望默认显示提交按钮。
如果没有消费者模式，先点击查看，发送器缓存了；随后再点击新建，表单页弹窗显示，页面重加载，接收器初始化监听，也会用到缓存，结果也把提交按钮隐藏了。消费者模式会这样处理：
- 接收器只要成功消费缓存数据，就会将自身全局标记，加到缓存的发送数据中（消费者列表）。
- 接收器初始监听，如果发现缓存的发送数据中，消费标记中有自己的全局标记，那么就不消费（不作响应处理）。
- 接收器的全局标记，取决于页面的逐层嵌套信息，不同页签嵌套通个页面，标记不相同。
- 发送器每次发送，会对这条消息的消费者列表，进行清理。确保接收器能够再响应。
文档：https://www.yuque.com/liuhuo-nc809/uiotos/hf6hq3949mqpg32u#GGKQd
关于
UIOTOS是一款前端零代码工具，首创的页面嵌套技术，可搭建业务系统、大屏组态、上位机HMI等复杂交互界面，实现与原型1:1的效果。
与NodeRed、APIJSON、IoT平台，或其他低代码平台等，形成前后端一体方案（有后端API接口即可），快速交付物联网项目。
示例：工业组态HMI
示例：园区业务系统
WX：iotosoft
