前言
作为一个写了好几个月的Uniapp小程序的打工狗，我总结了一下在前端中信息是如何传递的，得出了一个比较标准化的信息流通过程。（主要是Uniapp写起来比较恶心，写多了出Bug都不知道Bug在哪里）
信息
什么是信息，就是用来交互的数据，我把前端分为视图层和业务层。
- 视图层：将数据转换为界面
- 业务层：给数据
而又因为我们的界面常常是多级层次，所以界面是有包含关系的，即父子组件，兄弟组件。
组件化的难点：组件信息流通
现代前端页面都是组件化开发，组件化开发的特点就是将复杂页面划分为多个功能模块和可以高度复用的通用组件。将简单问题复杂化。但是有好也有坏。
组件化的缺点就是因为将视图层的逻辑简单化了，业务层也被打散了。所以信息的流通成为了难点。即如何保证组件拿到的数据是所需要的数据。
这里就引出了我们信息流通的内容
信息流通
信息流通分类
| 流通方式\主动被动 | 主动 | 被动 |
|---|---|---|
| 直接 | 通知（触发器），直接调用 | 回调函数 |
| 间接 | 发布订阅 | 全局缓存 |
Tips:为了让数据的流通可以操控，这里父子组件的流通是，父通知，直接调用子组件。子回调函数通知父
通知
监视一个数据被赋值的时候，触发函数。
WPF可以通过get,set来设置
Vue使用watch来监视
直接调用
直接拿到子组件对象调用其中方法。
WPF使用X:Name
Vue使用ref来设置别名
回调函数
WPF直接使用依赖注入，bind{一个Action委托}
Vue使用emit回调
发布订阅
先订阅，再发布。才能订阅到消息
先发布，再订阅。就错过了之前的消息。
WPF可以使用prism，设置一个全局的事件聚合器
uniapp可以使用uni.$emit和uni.$on来触发
发布订阅一般是topic+pyload的形式。即订阅头+负载。但是我个人建议使用:topic+{key,value}的形式。这样三层结构，用了面向对象的思想。可以按照topic进行分类。更容易将消息进行管理
发布订阅如何配置
配置分为两种：一发多订和一订多发
- 一发多订（推荐）
- 一发多订类似于广播站，保证了信息的可达性，穿透性。类似于提前把所有的信息发布出去，想要的接收的就接收。
- 一订多发
- 一订多发类似于监听器，只监听一部分信息。保证了信息的边界性。
我们发布的信息一般是通用性的信息，是希望所有组件想要听到就听到的。所以建议一发多订的模式。
全局缓存
这里的全局缓存可以是网页缓存，static对象，数据库数据，后端信息。即可以直接拿取的数据。
使用建议
信息具有边界性和可达性。
-
边界性保证信息超出边界就消失，防止误触。
-
可达性保证信息传达到各个角落，防止信息丢失
-
对于父子具有包含关系的信息。采用直接信息传递，即通知（触发器），直接调用，回调函数。
- 因为我们希望这些信息不保存，用完即丢弃，限制其传播范围，保证信息的边界性。因为是临近关系，通过父组件直接控制子组件保证信息的可达性。
-
对于跨层级，比如祖孙。或者同级的兄弟。或者不可测层级的消息传递时。使用间接信息传递。
- 因为比起信息是否能限制的传递来避免误触发，我们更希望保证信息的可达性。通过严格的信息调用控制来保证信息的边界性。
总结
通过几个月的uniapp实战项目。我掌握了前端信息交互的逻辑。以后写别的界面程序。例如桌面端，网页端，或者游戏端。我感觉我都很清楚我要干什么。