北京小程序组件开发：从踩坑到复用

做小程序这些年，我越来越觉得组件库是一个项目的骨架。尤其在北京做小程序开发，客户的需求往往来得快、改得也快，没有一套趁手的组件，每次改需求都像重新装修一遍房子。知码客一直讲「知码识途、匠心铸客」，代码是我们和用户沟通的语言，组件就是这门语言里的常用词。

为什么北京的项目更需要组件化

北京的小程序项目有个特点：业务方多、评审链条长、上线窗口紧。一个需求从提出到验收，中间可能经过产品、运营、法务好几轮。如果每个页面都各写各的，改一处文案就要翻十几个文件，返工成本极高。组件化不是炫技，是让改动有边界。

我经手过一个朝阳区的连锁餐饮小程序，门店点餐、会员积分、外卖配送三块业务，最初是三个人各写各的，结果按钮样式有五种、加载态有四种，客户提了一句「统一一下视觉」，我们花了整整两天。后来抽出了基础的 button、empty、loading 组件，第二次改版只动了三个文件。

自定义组件的三个关键点

1. properties 设计要克制

新手容易把组件做成万能盒子，属性开十几个，最后自己都记不住。我的经验是：属性只暴露业务真正需要的差异，样式差异尽量用外部类名解决。

Component({
  properties: {
    title: { type: String, value: '' },
    loading: { type: Boolean, value: false },
    disabled: { type: Boolean, value: false }
  },
  methods: {
    onTap() {
      if (this.data.disabled || this.data.loading) return
      this.triggerEvent('submit')
    }
  }
})

注意 triggerEvent 只传事件名，数据由父页面自己取，组件不替父页面做决定。这一点在海淀区一个教育类小程序里救过我们：同一个提交按钮在报名页和续费页行为不同，组件只负责触发，逻辑留在页面，后期加埋点也没乱。

2. 样式隔离别急着开

styleIsolation: 'isolated' 看起来安全，但实际项目里父页面经常要微调组件间距。我一般用 apply-shared，配合 externalClasses 暴露一个 custom-class，既保留封装又留了后门。北京不少客户喜欢在验收时临时调 UI，这个后门能省下大量沟通。

3. 组件通信优先用事件，别用 selectComponent

父组件调子组件方法，this.selectComponent('#xxx') 写起来爽，但组件一多、层级一深，就成了隐式依赖。我见过一个西城区的电商小程序，页面里塞了二十多个 selectComponent，后来组件改名，全项目搜替换，差点出事。能用 triggerEvent 加属性驱动解决的，就别伸手去拿子组件实例。

一个可复用的空状态组件

空状态是小程序里出现频率最高的组件之一，也是最容易被敷衍的。我们团队内部统一了一版：

Component({
  properties: {
    type: { type: String, value: 'default' },
    text: { type: String, value: '暂无数据' }
  },
  data: {
    icons: {
      default: '/assets/empty.png',
      network: '/assets/network.png',
      search: '/assets/search.png'
    }
  }
})

模板里根据 type 取图，文案可覆盖，再留一个 slot 给操作按钮。这个组件在通州一个社区服务小程序里复用了十几次，运营换文案不用找开发，直接改属性就行。

组件文档比组件本身重要

说实话，组件写得好不如写得让人敢用。我们给每个组件配一个 README，写清楚属性、事件、slot、使用示例，放在仓库根目录。北京团队协作节奏快，新同事接手项目，先看组件文档再看页面，半天就能上手。知码客做北京APP开发和小程序定制时，交付物里一直包含这份文档，客户后续换团队也不至于抓瞎。

组件化的本质不是少写代码，是让改动可控。北京的项目改得快，可控比优雅更值钱。

如果你也在做小程序，不妨先别急着写页面，花半天把按钮、空状态、加载、弹窗这四个基础组件抽出来。后面省下的时间，远不止半天。