Propagation Config 3: bubbles:true, composed:true

同学，我们今天讲一个比较重要的配置：事件冒泡的`bubble: true` 和 `composite: true` 同时开启的情况。这听起来有点技术，但你只要记住一点：，这是权限最大、也是代价最高的组合，。 我们想象一下，页面是由一层一层组件嵌套起来的，就像俄罗斯套娃，每个组件也可能有自己的阴影边界，类似一个封闭的小世界。普通的冒泡事件可能只在自己这一层里面传，但如果同时把`bubble`和`composite`都设成`true`，这个事件就会变得特别猛——它能穿过DOM的每一层，穿过每一个阴影边界，一直冲到整棵文档树的根部。也就是说，它路径上的每一个祖先组件，无论隔了多少层，只要它愿意，都能听到这个事件。 那这带来什么问题呢？ 首先，你的事件类型突然就变成了整个组件公共API的一部分。因为路径上任何一个祖先组件都可以去监听它，你就等于和每一个祖先组件都签了一个无形的合同：只要我发了这个事件，你们都有权处理。这个合同的“签名”范围太大了，以后你想改事件名字、改事件内容，都会牵连一大片，维护成本非常高。 更麻烦的是，，名称冲突，会变成一个真实的危险。如果两个完全无关的组件都用这个配置，而且碰巧发了同名的事件，比如都叫`itemselected`，那某个祖先组件可能就会错误地触发监听器，它分不清到底是哪个后代发来的。这就是典型的“说者无心，听者错意”。 如果迫不得已必须用这种模式，一定得给你的事件类型加个，命名空间前缀，，像`mydomain__myevent`这种格式。虽然写出来有点丑，监听器的HTML属性会变成`onmydomain__myevent`，但至少能保证全局唯一，不会跟别人撞名字。 总的来说，你要记住，避免同时用`bubble: true`和`composite: true`，除非你有一个非常明确、文档写得清清楚楚的需求，就是想让事件跑到遥远的祖先那里去。否则，这就像在小区里用大喇叭喊话，整栋楼都听见了，很可能吵到不该吵的人，还把自己绑在一堆承诺上。 好了，这个配置的影响我们就讲清楚了，下一步可以看看更安全的事件通信方式。