小程序组件开发，别急着写页面

前几天帮石家庄桥西区一个做社区团购的客户改代码，翻到一个两年前写的页面，光一个商品卡片就复制了七遍。改价格显示逻辑的时候我一处处改，改到第五处差点漏掉，心里直冒火。这活儿要是当初抽成组件，十分钟就能收工。今天就把我在石家庄做小程序这些年，关于组件开发攒下的经验聊聊，不整虚的。

先想清楚：什么该抽成组件

很多人一上来就急着封装，结果封出来一堆只用一次的“组件”，反而把简单的事搞复杂。我的判断标准很朴素：

• 同一个结构在当前项目里出现两次以上，且未来大概率还会出现；
• 这块 UI 有自己的交互状态，比如展开收起、选中态、加载中；
• 它需要独立维护，改动不应该牵连页面其他部分。

反过来，只在一个页面用一次、结构又简单的块，老老实实写在页面里就好。知码客接的石家庄本地单子里，不少是餐饮、零售类的小程序，页面本身不复杂，过度拆分组件只会让人找代码找得更累。

自定义组件的骨架怎么搭

微信小程序的自定义组件，核心就四样：json 里声明、js 里定义、wxml 写结构、wxss 写样式。拿一个最常用的商品卡片举例：

// components/goods-card/index.json
{
  "component": true
}

// components/goods-card/index.js
Component({
  properties: {
    goods: { type: Object, value: {} },
    showCart: { type: Boolean, value: true }
  },
  methods: {
    onTap() {
      this.triggerEvent('select', { id: this.data.goods.id })
    },
    onAddCart(e) {
      // 阻止冒泡，避免触发卡片点击
      this.triggerEvent('addcart', { id: this.data.goods.id })
    }
  }
})

页面里引用的时候，别忘了在页面的 json 里注册：

{
  "usingComponents": {
    "goods-card": "/components/goods-card/index"
  }
}

然后 wxml 里直接 <goods-card goods="{{item}}" bind:select="onSelect" /> 就行。看着简单，但坑都在细节里。

几个踩过的坑，说给你听

样式隔离别想当然

组件默认样式是隔离的，但如果你在组件里用了 class 去覆盖外部样式，会发现根本不生效。要么在组件 json 里把 styleIsolation 设成 apply-shared，要么干脆用外部样式类 externalClasses 暴露出去。我一般倾向后者，干净，不会互相污染。

properties 别乱传大对象

有次给石家庄一个做本地生活服务的客户写列表，把整个列表数据塞进一个组件的 property 里，结果滚动卡得不行。小程序的 setData 是有开销的，传大对象等于每次更新都全量同步。正确做法是传必要字段，或者用 observers 监听关键字段变化再局部处理。

事件名要起得能看懂

triggerEvent 的事件名别用 change、click 这种烂大街的词，组件一多就分不清谁是谁。我习惯用 select、addcart、loadmore 这种带语义的，页面里 bind:addcart 一眼就知道干嘛的。

组件拆分和项目结构

项目大了以后，组件目录最好按业务分，别全堆在 components 根目录下。比如：

components/
  base/        // 按钮、弹窗、loading 这类通用件
  goods/       // 商品卡片、规格选择
  order/       // 订单条目、状态标签

通用件和业务件分开，复用的时候心里有数。知码客这边做石家庄小程序定制开发，交付时都会把组件目录整理清楚，客户后面找别人接手也不至于抓瞎。

最后一句实在话

组件开发不是炫技，是为了让改需求的时候少骂两句。石家庄做小程序的公司不少，真正把组件这层地基打牢的不多，很多项目交付时页面能跑，一加功能就乱套。我们做石家庄APP开发和小程序定制这些年，越来越觉得“知码识途、匠心铸客”不是口号——每一行代码都是跟用户沟通的语言，组件写得清爽，后面维护的人就少受一份罪。你要是也在折腾小程序组件，欢迎来知码客坐坐，聊聊代码，也聊聊庄里的生意。