Vue业务组件设计思想： 巧用slot插槽实现UI和业务解耦

Vue业务组件设计思想： 巧用slot插槽实现UI和业务解耦

写在前面

• 本文主要分享笔者在组件设计和重构过程中总结的经验技巧，核心内容是分享Vue组解耦设计的编程思想，而非高大上的前沿技术,和组件的高级实现。

技术/知识核心

• vue / slot插槽

          本文通过使用slot实现vue组件的解耦设计，因此在阅读本文之前，最好有Vue.js开发经验和slot插槽使用经验。当然这不是必须的，正如前面所说，本文主要是分享如何使用slot实现组件UI样式和业务逻辑的解耦，核心在于解耦的思想。

正文

         首先介绍一下本文的背景，笔者最近正在开发一个业务数据下发的H5应用，根据业务需求和前期的设计界面，整个应用以列表以及列表跳转到详情页的界面为主。这个场景应该不难想象对吧！简单的分析一下这个需求，首先详情页面由于业务逻辑，应用场景，数据格式等各不相同，只能按需设计。而整个应用中涉及的list界面风格则大同小异，通常这种情况下都是现搜索一下当前的UI组件库，看看是否有满足条件的list组件，然而并没有，好吧只能自己动手设计了。

• 为了让各位看官有一个比较直观的印象，在个人电脑上使用PPT简要勾画了整个界面的UI结构。list组件涉及的UI界面大致如下图所示（忽略我用PPT设计的丑图）。

         从UI设计的角度来说组件本身并不复杂，复杂的地方在于不同界面处理的业务数据都是不一样的，一旦将数据应用到UI上，就会发现很多不尽人意的地方。同时不同界面受众不同，关注点也不同。因此针对不同的界面做一些个性化的调整是必要的。

方案一： 为每个界面单独设计一个组件

        不要问我为什么这样设计，有过实际开发经验的朋友都知道，项目初期需求变更是非常频繁，因此最开始我计划为每一个界面单独设计一个list组件，这是我的组件库是下面这样的：

- components
|- list-a.vue
|- list-b.vue
|- list-c.vue
......

        这样一来，即使后期业务需求变更，前端代码也能够很快的调整以响应业务。但若是整体变更，比如用户说标题不够明显需要加大加粗，那就需要同时对所有的组件都进行调整。若是后期再新增新的通用功能，那就需要将所有你的组件重新撸一遍。
        仔细分析下来，为了一丝灵活性和牺牲组件最重要的可复用性显然不妥，一旦业务有较大的调整，对于后期维护来说是相当痛苦的。

方案二：将所有的功能都组合到一个组件，使用prop和$emeit实现交互

        这应该是大多数人采用的方案了，该方案将所有的功能都封装在一个组件中，通过v-if等指令控制UI的显示效果，即可满足各自业务需求，同时也能达到组件复用的目的，是比较通用的做法。但是，在组件内将UI和业务逻辑耦合在一起，势必会增加组件的使用成本，假设应用同时由几个开发者一起协同完成，对方若要了使用你的组件，可能需要先阅读组件的说明文档（对于这种业务性质的组件，谁会去写文档并维护呢？）这样就势必会增加沟通的成本，再进一步若你先阶段封装的功能无法满足未来的业务模式，那针对该组价进行扩展该是多么痛苦的一件事情啊。既要满足新业务又不能对既往页面产生影响。
        这样想来这种方案也不可取，因为未来业务具有不确定性，不可预知性，一旦当前组件无法满足未来业务，要么回头重构组件，要么针对未来业务设计新的组件，这样一来又陷入了方案一的问题中。

方案三：利用slot实现UI和业务的解耦设计

        方案二之所以无法满足未来业务归根结底在于可扩展性差，那么有没有什么办法可提提高组件的可扩展性呢？答案是有的，那就是利用slot插槽（对slot不熟悉的同学请自行补课）
        slot可谓是组件设计的利器，将通用的UI封装起来，同时利用slot插槽给业务开发一个入口，这样就可以实现通用部分由组件管理，业务部分由开发人员自行设计，并通过slot插槽与通用UI组件结合。
        再次用上图为例：

通用部分比如check-box / number－box 等直接集成到业务组件list-common.vue中，而和业务相关的比如主体区域，注脚和描述部分通过具名插槽开发给业务自行设计。这样即使未来的业务有较大的变化都可以基于此list-common组件进行设计和封装，同时将业务部分剥离之后也大大降低了组件的使用成本。

---

(完)