跟混乱的页面弹窗说再见

对于一些快速迭代的产品来说，特别是移动端 C端产品，基于用户运营的目的，在 app首页给用户展示各种各样的弹窗是很常见的事情，在产品初期，由于迭代版本和运营策略变化地还不是太大，所以可能觉得没什么，但当产品运营到后期，各种八竿子打不着的运营策略轮番上阵，弹窗的样式、逻辑等都变了不知道多少遍的时候，问题就出来了

由于前期没有做好规划，首页的弹窗组件可能放了十多个甚至更多，不仅是首页有，首页内又引入了十多个个子组件，这些子组件内也有，搞不好这些子组件内还有子组件，子组件的子组件同样还有弹窗，每个弹窗都有对应的一组控制显隐逻辑，分散在多个组件多个方法中，但是首页只有一个页面，你不可能让所有符合显示条件的弹窗，全都一下子弹出来，反正我是没见过这么做的 app，那么如何管理这些弹窗就成了头等大事

而往往当你意识到这一点的时候，很可能也正是局势发展到无法控制的时候 治不了，等死吧

场景：A弹窗和 B弹窗位于主组件内，C弹窗位于主组件的子组件 C中，D弹窗位于主组件的子组件 B中，E弹窗位于主组件的子组件F的子组件G中

PM：我希望刚进入这个页面的时候，只有当 A弹窗 和 B弹窗以及 C弹窗，都不展示的时候，才展示 D弹窗，如果 D弹窗展示过了，除非 B弹窗之后又展示了一遍，否则无论什么情况下都不展示 E弹窗

FE：？？？

所以，防患于未然是很重要的 别问我是怎么有这个感悟的

稍加思考一下，其实这件事情并不难办，交给后端通过接口控制所有弹窗的显隐就行了 主要是架构的提前规划，以及低耦合的代码逻辑

弹窗的配置化

先确定一个大体思路，首先，必须要明确地知道当前页面共有哪些弹窗组件，包括页面的子组件以及子组件的子组件内的弹窗组件，这是必须的，否则你连有哪些组件都不知道怎么精确控制？

所以，还是上面那句话，提前规划，防患于未然是很重要的，不然等页面迭代了几十版，当初写代码的人都不在了你才想到去统计一下页面上到底有多少个弹窗，那真是够你喝一壶的

那么就需要在一个地方统一把这些弹窗全记录下来，方便管理，于是可以得到下面这种数据结构：

// modalMap.js
export default {
   
  // 记录首页 index页面内的弹窗项
  index: {
   
    modalList: [{
   
      id: 1,
      condition: 'modal_1',
      level: 100,
      feShow: true
    }, {
   
      id: 2,
      condition: 'modal_2',
      level: 22,
      feShow: true
    }, {
   
      id: 3,
      condition: 'modal_3',
      level: 70,
      feShow: false
    }],
    children: {
   
      child1: {
   
        modalList: [{
   
          id: 11,
          condition: 'condition_1_1',
          level: 82,
          feShow: true
        }, {
   
          id: 12,
          condition: ['condition_1_2', 'condition_1_3', 'condition_1_4'],
          level: 12,
          feShow: true
        }],
        children: