关于组件配置化的思考

配置化思想，其实可以在很多的地方使用。很多时候，我们在设计接口、应用、数据等情况下，配置化的方式可以允许我们获得更高的自由度。这里我们简单讲讲组件的配置化吧。

配置化思想

可配置的数据

数据的配置，或许大家会比较熟悉。像一些静态数据呀，或者说我们很多的管理端都是用来进行数据配置的。

应用中的可配置数据

最常见的数据配置，大概是应用里面的配置，文案呀、说明等，为此我们有了运营这样的职位。常见的方式，则是搭起一整套的运营管理平台，一些简单的文字或是数据，则可以通过平台进行配置。

代码中的可配置数据

有些时候，我们也会在代码里面放置一些可配置的数据。例如说，这个需求需要查询一周的数据，常见的做法是将天数配置为 7 天：

const QUERY_DAY_NUM = 7;

这样，当需要在紧急情况支持其他天数（五一、国庆、过年能假期）的时候，我们就可以只需要改动这里就好啦。

文件里的可配置数据

有些情况下，一些影响逻辑的配置数据，要是直接写到代码里，在调整的时候通常需要重新打包部署，这样情况下开销大、效率低。

所以在一些时候，我们会把这样的可配置数据，单独写到某个文件里维护。当需要调整的时候，只需要下发一个配置文件就好啦。

可配置的接口

关于接口的配置化，目前来说见过的不是特别多。毕竟目前来说，我们的很多数据和接口并不是简单的增删查改这样的功能，很多时候还需要在接口返回前后，做一系列的逻辑处理。

简单地说，很多的业务接口场景复用性不高，前后端除去协议、基础规范的定义之后，很少再能进行更深层次的抽象，导致接口配置化的改造成本较大。

配置化的实现有两点很重要的东西：规范和解决方案。如果说目前较好的从前端到后台的规范，可能 GrapgQL 和 Restful ，大家不熟悉的也可以去看看啦。

当然，或许有些团队已经实现了，也希望尽快能看到一些相关的解决方案啦。

可配置的页面

页面的配置化，可能也已经不少见了吧。像我刚出道的时候，也写过一个拖拽的 demo，虽然现在光想想那时候的 jQuery 代码就惨不忍睹，不过当时还是觉得自己挺牛逼的。

有些时候，一些页面比较简单，里面的板块、功能比较相似，可能文案不一致、模块位置调整了、颜色改变等等。虽然说复制粘贴再改一改，很多时候也能满足要求，但是配置化的思想，就是要把重复性的工作交给机器呀。

这种页面的配置，基本上有两种实现方式：

1. 配置后生成静态页面的代码，直接加载生成的页面代码。
2. 写通用的配置化逻辑，在加载页面的时候拉取配置数据，动态生成页面。

基于 SEO 和实现复杂度各种情况，第一种方式大概是目前比较常用的，第二种的实现难度会稍微大一些，同时对于 SEO 与单页应用有着相同的困境。

第一种方式，很多适用于一些移动端的模版页面开发，例如简单的活动页面、商城页面等等。

第二种的话，更多的是一些管理平台的实现，毕竟大多数都是增删查改，形式无非列表、表单和菜单等。之前我也捣鼓过一小会的 Angular 表单、列表等配置，可以看看Angular 自定义页面和这个Angular2 Schema Form Exemple。嗯，可能有些 bug，don't mind don't mind~

可配置的应用

可配置的应用，大概更多地是从业务和应用设计的角度出发。当我们设计一个应用的时候，页面是活动的、可变的、可配置的，这些都是需要考虑到的地方。

当然，如果说涉及到代码实现的话，那大概与上面的相关。配置化的思想，其实或许不局限于代码、工程和我们的工作，甚至我们完全可以拓展至我们的生活中。

组件配置化

那么这里我们来讲一下简单的配置化组件的实现把。关于组件的封装，我们在《一个组件的自我修养》一文也讲述过。

下面的组件，我们同样拿这样一个卡片组件来作为例子吧。

image

可配置的数据

首先是数据的配置，这大概是最基础的，当我们在封装组件的时候，很多数据都是通过作用域内的变量来动态绑定的，例如 Vue 里面则是data、props、computed等维护 scope 内的数据绑定。

作为一个卡片，内容是从外面注入的，所以我们可以通过 props 来获取：

<template>
  <div>
    <h2>{{model.question}}</h2>
    <div>
      <div v-if="model.withImage"><img :url="model.imageUrl" /></div>
      <div>{{model.content}}</div>
    </div>
    <div>
      <span @click="likeIt()">点赞</span>
      <span @click="keepIt()">收藏</span>
    </div>
    <div>
      <p v-for="comment in model.comments">{{comment}}</p>
    </div>
  </div>
</template>
<script>
  export default {
    name: "my-card",
    props: {
      // 传入数据
      model: {
        type: Object,
        default: () => {}
      }
    },
    data() {
      return {
        isContextShown: false
      };
    },
    methods: {
      likeIt() {},
      keepIt() {}
    },
    mounted() {}
  };
</script>

这里只展示简单的方式，我们会这样使用：

<my-card :model="cardModel"></my-card>

可配置的样式

样式的配置，通常是通过class来实现的。其实这更多地是对样式的配置化设计，与我们的 HTML 和 Javascript 关系则比较少。

样式的配置，需要我们考虑 CSS 的设计，通常来说我们有两种方式：

1. 根据子元素匹配，来描述 CSS。
2. 根据子 class 匹配，来描述 CSS。

根据子元素配置 CSS

这是以前比较常用的一种方式，简单地说，就是通过 CSS 匹配规则中的父子元素匹配，来完成我们的样式设计。

例如，我们有个模块：

<div class="my-dialog">
  <header>I am header.</header>
  <section>
    blablablabla...
  </section>
  <footer>
    <button>Submit</button>
  </footer>
</div>

样式则会这样设计：

.my-dialog {
  background: white;
}
.my-dialog > header {}
.my-dialog > section {}
.my-dialog > footer {}

或者说用 LESS 或是 SASS：

.my-dialog {
  background: white;
  > header {}
  > section {}
  > footer {}
}

通过这种方式设计，或许我们在写代码的时候会稍微方便些，但是在维护上面很容易踩坑。曾经我也喜欢这种方式写，后来在一次次的 DOM 结构调整过程中，差点掉坑里出不来，于是乎后面慢慢改用第二种方式。

根据子 class 配置 CSS

其实相对于匹配简单的父子和后代元素关系，使用 class 来辅助匹配，则可以解决 DOM 调整的时候带来的问题。

这里我们使用 BEM 作为例子来解释下大概的想法吧：

BEM

BEM 的意思就是块（block）、元素（element）、修饰符（modifier），是一种前端命名方法论。更多的大家可以去谷歌或者百度下。

简单说，我们写 CSS 的时候就是这样的：

.block{}
.block__element{}
.block--modifier{}

• block：可以与组件和模块对应的命名，如 card、dialog 等
• element：元素，如 header、footer 等
• modifier：修饰符，可视作状态等描述，如 actived、closed 等

这样的话，我们上述的代码则会变成：

<div class="my-dialog">
  <header class="my-dialog__header">I am header.</header>
  <section class="my-dialog__section">
    blablablabla...
  </section>
  <footer class="my-dialog__footer">
    <button class="my-dialog__btn--inactived">Submit</button>
  </footer>
</div>

搭配 LESS 的话，其实样式还是挺好写的：

.my-dialog {
  background: white;
  &__header {}
  &__section {}
  &__footer {}
  &__btn {
    &--inactived
  }
}

Emmmmmm。。其实大家看了下，就发现这样的弊端了，这样我们在写 HTML 的时候，需要耗费很多的时间来写这些 class 名字，更惨的是，当我们需要切换某个元素状态的时候，判断条件会变得很长，像：

<button :class="isActived ? 'my-dialog__btn--actived' : 'my-dialog__btn--inactived'">Submit</button>

简直惨不忍睹。当然我们也可以把修饰符部分脱离，这样使用：

<button class="my-dialog__btn" :class="isActived ? 'actived' : 'inactived'">Submit</button>

这样会稍微好一些。BEM 的优势和弊端也都是很明显的，大家也可以根据具体的团队规模、项目规模、使用场景等，来决定要怎么设计。

当然，如今很多框架都支持样式的作用域，通常是通过在 class 里添加随机 MD5 等，来保持局部作用域的 class 样式。常见的话，我们是搭配第一和第二种方式一起使用的。

可配置的展示

可配置的展示，更多时候是指某些模块是否展示、展示的样式又是如何等。

例如，我们需要一个对话框，其头部、正文文字、底部按钮等功能都可支持配置：

<div class="my-dialog" :class="{'show': isShown}">
  <header v-if="model.title">{{model.title}}</header>
  <section v-if="model.content">{{model.content}}</section>
  <footer>
    <button v-for="button in model.buttons">{{button.text}}</button>
  </footer>
</div>

我们可以通过model.title来控制是否展示头部，可以通过model.buttons来控制底部按钮的数量和文字。

这只是最简单的实例，我们甚至可以通过配置，来控制出完全不一样的展示效果。搭配样式的配置，更是能让组件出神入化。当然，很多时候我们组件的封装是需要与业务设计相关，这样维护性能也会稍微好一些，这些前面也都有说到过。

可配置的功能

功能的配置，其实很多也与展示的配置相关。但是我们有些与业务相关的功能，则可以结合展示、功能来定义这样的配置。

举个例子，我们的这个卡片可以是视频、图片、文字的卡片：

• 视频：点击播放
• 图片：点击新窗口查看
• 文字：点击无效果

这种时候，我们可以两种方式：

1. 每个功能模块自己控制，同时通过配置控制哪个功能模块的展示。
2. 模块展示会有些耦合，但在点击事件里，根据配置来进行不同的事件处理，获取不同的效果。

对应维护性和可读性来说，第一种方式会获得更好的效果。如果问什么情况下会用到第二种，唔。。。大概是同样的呈现效果，在不同场景下的逻辑功能不一样时，使用比较方便吧。

功能配置化这块就不过多描述啦，毕竟这块需要与业务场景密切结合，大家更多地可以思考下，自己的项目中，是否可以有调整的空间，来使得整体的项目更好维护呢？

结束语

我们讲述了很多的配置化场景，也针对组件来详细描述了一些配置化的方向和方式。随着科技越来越发达，很多简单和重复性的事情我们可以交给机器去做，这就需要我们把相似的部分提取出来抽象封装，把可变的部分结合配置来高效地调整。

抽象封装和配置化的搭配，其实能获得很不错的效果，我们在对一些事物的认知上，也能进行更深层次的概括和思考。

查看Github有更多内容噢: https://github.com/godbasin