B端配置化平台实践（基于VUE）

为什么现在很多公司都有自己的配置平台？

1.提高人效（主要原因）

通过配置平台配置页面，减少开发量，快速上线。

2.减少后台项目代码体积

一个业务系统对接配置化平台，往往只需要加载配置化平台提供的一个 json渲染器 即可

这个是我司crm系统对接配置化平台的实现

可以看出来，一个页面只需要这几行代码就可以了，之后不管页面如何修改，都不需要更改crm系统代码。 （渲染器的具体实现下面会写。）

B端配置平台服务于哪类页面

接受：简单，通用，高频的页面，比如统计页面这类的，上面是一些选项，然后渲染出一个表格这种的，一个系统会有很多这类页面
拒绝：复杂的页面，定制化UI,这种页面往往实现起来困难，且无法复用，走配置需要开发很多纯业务组件，只服务与这一个页面，收益不大，还不如写代码来的快。

与产品的battle(平衡需要配置页面的标准)

在配置化平台出来后，往往会面临一个问题，就是产品总会提出一些需求，当前的组件库不支持，这种情况下，总不能一直去提供更多的组件去支持产品提出的各种需求，这样就需要一直去迭代组件库，这样做配置平台就没有达到减少开发量的目的。
这个时候，就需要和产品沟通，定出一个标准，什么样的需求走配置化，而不是通过配置平台满足产品的各种‘奇葩’需求。
一个后台，整体界面风格和一些操作行为应该是统一的，需要‘教育’产品提出的需求也向这个方向靠拢，这样才能更好的用配置化去支撑。

配置化流程

一个配置化系统大体可以分为两步
1.通过配置化平台生成一个json，一个可以描述页面结构的json
2.业务系统获取json，渲染出页面来
可以看的出来，配置化的核心其实就是json（一个页面描述文件），接下来分别说一下两部分的实现

配置化实现核心（json渲染页面）

现在开发页面都是通过组件式的方式开发，不管是vue还是react,一个页面往往是由一个组件树的方式呈现。所以只需要有一个描述文件(也就是json)，可以很好的描述组件树就可以。之后把这个json文件转成相应的代码，渲染出来就行了。

第一步，定义一个合理json结构

简单的一个例子，描述一个组件，需要描述出组件名（componentName）和props(组件需要的数据，cid，showBorder那些)其实就可以了.

把json转成相应的代码

只需要把这个json最终转成这样的vue代码其实就已经完成了。
这个json的描述规则就很简单，componentName对应组件名，componentList里面的是子组件，之后同级的cid啥的都当作props传入组件实例里。
tip: 这里j-container,j-select这些组件，一定要保证已经注册到项目中，至于方式，不管是全局注册，还是动态加载注册都可以，看各自的考量

如何把json转成vue代码

其实很简单，只需要写一个递归组件就ok了

之后在入口文件，拿到json对象,传入上面那个node组件里，就渲染出来了

上面其实已经讲述了，如果通过json文件渲染出页面来，其实也看的出来，配置化说白了就是维护一个json来，页面拿到这个json,渲染出来，ok
这里，一些公司在做配置化的初期，往往是没有配置化平台的，而是直接编写json,然后渲染。但这样，对开发倒是还好，但没法给运营或者产品同学用，因为她们并不了解json里面具体每一个字段的含义，所以就需要开发一个配置平台来

配置平台要做的事情

其实很简单，配置平台就是吐出一个json文件来。
这是我这边做的一个简单的配置化平台

很简单，主要组件列表，画布，属性编辑三部分，实现起来也很简单，核心维护一个公有的jsonInfo对象，然后对这个jsonInfo对象做增删改查
1.组件列表，加载配置化平台的组件库就行

    // 默认jsonInfo对象
    {
        componentName: 'j-container',
        componentList:[]
    }
    // 之后当你选中选择框组件，是可以拿到这个组件的属性的，然后把这个组件放到jsonInfo对象里面就行,伪代码
    jsoninfo.compoentList.push(
    {
        componentName: 'j-select'
    })

2.画布，拿到jsonInfo对象，执行上面说的那个Node递归组件，渲染出来就行
画布上的一些操作，比如在画布里面点击删除，就在jsoninfo里面把这个组件移除就行了
说白了就是对这个jsonInfo进行增删改查
3.属性那一栏也是一样的，当在画布里面选中一个组件，是可以拿到这个组件的属性的，之后渲染到属性那里就行了。
这里着重说一下，我这边组件的设计,相对重要一点。。。

以select组件为例，props里面的每一个属性都会有一个editProps属性，这个属性的作用是用来描述label字段的，在属性那一栏渲染如何渲染，就是通过editProps属性。当选中select组件，遍历props的属性，当遍历到label的时候，通过editProps，知道label用JarvisInput组件来渲染，JarvisInput组件实际就是input，这个时候在input里面输入内容，改变label的值，同时在jsonInfo里面加上就行了，这一块需要认真想一想

归纳一下

到这里，一个配置平台也就出来了，简单说，就是通过配置平台拖拖拽拽，生成一个json文件，用来描述组件树，然后在项目里面，通过json文件生成相应的vue组件树，然后渲染出来。

遇到的问题

1.组件联动

顾名思义，就是两个完全独立的组件，如何关联，比如两个select组件，选中select A 某一项，select B 组件隐藏。
方案1：通过事件的方式，给组件配置上要订阅的事件和要发布的事件.

这种是我之前实现的方式，发现很麻烦，需要定义很多事件消息，而且写起来很麻烦，在配置平台也很难很好的配置出来，上手难度很高，不适合给产品运营同学使用

方案2:有一个类似于管理全局数据的地方，每一个组件有一个keyName,这个keyName用来表示这个组件的值。如下图，组件aa和bb, 会写出类似global.aa和global.bb，同时通过defineProperty监听每一个组件的set,这样每一个组件的任何改变其实都是知道的。

这样，再写出一些描述清晰的语意代码就行了，如上图，watch ‘bb’,就是监听bb,当bb===1的时候，我的status置为show,这里status是业务组件的属性，不用太过关心。
在配置平台，把这些特殊语意片段转成图形的操作，再抽象一下，会更加方便～～。

2.组件库的版本管理

会有这样的情景，配置化平台出来了，系统A和系统B都接入了配置化系统，组件库版本是v1,当用了一段时间，配置化平台组件库升级到v2,这个时候json也许变得更加的‘花哨‘，这个时候系统A因为用的组件库还是v1版本，更新不及时，就不能支撑最新的json配置文件，就会有问题。
我这边的解决方案就是锁版本，保证json文件如果是在v1版本生成的，就加载v1版本的组件库。

3.json文件格式设计的合理性

我在前期做配置化的时候，是直接写json文件，然后渲染成页面，并没有图形化的配置平台,这个时候

1.没有考量到每一个组件props里面都加一个类似editProps这个属性，用来描述组件的每一个属性，提供给配置平台的属性那一栏。
2.组件联动使用的是事件发布订阅的方式实现的，没有考量到配置化平台接入的复杂性。
设计前期，一定要定好方案，做好技术评审，不然后期埋坑很苦逼。。

4.配置化平台组件库组件的设计

理想状态下，组件库的一些公有组件，既要支持配置化平台使用，也可以当作基础组件直接在业务系统使用，这个时候需求注意，组件里总会有一些默认行为是只在配置化平台才会执行的

像这个select组件，在配置平台是需要执行这个代码，让别的组件可以获知select组件自身的改变，上面有说，会维护一个全局数据源，来监听所有组件的变化。这也是在前期开发组件时，需要注意的地方。

总结

以上是我这边做配置化平台的思路和遇到问题的解决方案，有哪里漏掉的，或者有什么问题欢迎指出，一起讨论