前言

对于前端中台的一些事

越来越多的公司都有前端中台，说起中台，这个最早是从阿里在2015年提出的“大中台，小前台”策略中延长进去的。

一般来说公司随着业务一直发现，业务线一直减少，会呈现各个业务线尽管业务不同，然而外围底层架构（我的项目搭建的相干脚手架，我的项目目录，编译，部署）和公共组件（地区抉择，日期，弹层，表单校验等）都是统一的状况。如果各个业务线在实现业务的同时还要本人搭建我的项目，开发各类组件，必然会导致反复开发、反复建设，效率低，产研资源节约，进而影响产品上线工夫。

在竞争如此强烈的时代，为了疾速迭代产品，为了公司能疾速的倒退，就须要一个两头平台去帮各业务线实现底层的相干搭建，公共框架组件的封装。

在这个大背景下，作为中台的一名前端，职责就是开发保护供整个公司前端应用的一些公共组件（插件），也总结了相干教训。

注释

思路与逻辑

  1. 在组件开发之前，须要依据需要思考组件须要实现的性能，这些性能须要裸露进来。
  2. 设计组件，秉着“最简略的调用，最灵便的扩大”准则，也就是使用者能够传入起码的配置参数实现组件调用展现，也能够通过配置进行灵便的定制化。例如开发一个公共弹层组件，业务端既能够只传入文本进行简略调用展现，也能够扩大配置，实现一个更加定制，更加简单的弹层。 例如antd的Modal组件。
  3. 咱们所开发的组件个别都会公布npm包，不便调用和保护。各个公司都有本人的npm, npm包的个别目录如下，当然如果简略的组件可能只有index.js，目录依据理论设置就好。
  4. 默认状况调用的入口就是index.js, 少数组件是一个类，个别咱们在

举例

  • 应用类的形式实现一个原生js的简略订阅公布插件：
class EventListner{    constructor(){        // 单例模式保障此类只创立一次        if (EventListner['EventListnerInstance']) {        return EventListner['EventListnerInstance']        }        EventListner['EventListnerInstance'] = this;        this.subscribeList = {} // 订阅事件名称    }    //订阅    on(evt, fn){        if (typeof fn === 'function') {            this.subscribeList[evt] = this.subscribeList[evt] || []            this.subscribeList[evt].push(fn)            // unique为比照同一监听事件的回调是否一样，一样则排除            this.subscribeList[evt] = unique(this.subscribeList[evt], (item1, item2) => item1.toString() === item2.toString())        }    }    // 公布    publish(...args) {        const fns = this.subscribeList[args[0]]        if (fns !== undefined) {            const _args = args[1] || ''            for (const fn in fns) {                if (Object.prototype.hasOwnProperty.call(fns, fn)) {                    fns[fn](_args)                }            }        }    }    // 解绑事件    off(ev, fn) {        if (typeof ev !== 'string') {            return        }        if (this.subscribeList.hasOwnProperty(ev)) {            this.subscribeList[ev] = []        }        fn && fn()    }}export default new EventListner();
  • 既反对组件形式能够传入子组件，又须要反对办法间接调用, 相似antd的Modal组件。
import React, { Component } from 'react'import PropTypes from 'prop-types'import ReactDOM from 'react-dom'// 实现组件形式调用class Dialog extends Component {    componentDidMount() {        this.appendDialog()    }    componentDidUpdate() {        this.appendDialog()    }    appendDialog() {        // 须要依据传入的props解决渲染的相干逻辑        ...    }    render() {        return null    }}// 将各配置进行类型查看Dialog.propTypes = {    title:'', // 题目    content:'', // 内容    ...}// 实现办法间接调用// 各种success, error，warning等都会走的逻辑，提出一个办法来function confirm(props) {    let _confirm    if(!document.querySelector('dialog-container')){        _confirm = document.createElement('div')        _confirm.id = 'dialog-container'        document.body.appendChild(_confirm)    }    ReactDOM.render(        // 此处渲染一个弹层        <DialogContent {...props} />,        _confirm,    )}// 此处只举例其中一种弹层success，其余error,confirm都相似只有图标，按扭等不同Dialog.success = function(props) {    const config = {        footer: false,        width: 280,        position: 'center',        visible: true,        closeBtn: false,        ...props,    },    return confirm(config)}export default Dialog
  • 继承，并改写父类一些办法的sdk。

这通常是在某个底层sdk须要再包一层嵌套业务的逻辑时应用。比如说公司须要一个直播的服务，须要中台的前后端配合提供，前端负责封装sdk, 后端负责提供接口和服务，这时依照咱们之前的思路是能够实现，然而随着业务的扩大，当一个新兴的业务线也须要一个直播服务，然而他们想要本人去搭建后端服务，前端底层逻辑与API接口是统一的。这时候咱们之前所写的融入了一些业务逻辑的sdk就不能满足了。这种状况咱们须要将底层逻辑与业务相干逻辑拆分为两个类，基类只提供根本的办法与调用要足够污浊，继承的子类去实现通用业务逻辑解决。这样当业务逻辑层无奈满足时，能够自行封装子类去实现。

class Base{    getSigniture(){       this.getVideoSigniture()    }    play(){    }    pause(){    }    ...}class Child1 extends Base{    getVideoSigniture(){        // 此处自行实现该子类须要的逻辑        ...    }}

罕用到的一些设计模式

1, 单例模式。
当咱们创立的sdk或插件在应用中可能会被屡次实例化时，须要在咱们的sdk或插件的构造函数中解决，屡次实例化返回指向同一个对象的指针。

2, 公布订阅。
此类设计模式在im的sdk中经常用到，因为链接、接管音讯等都是异步的，用户须要去监听链接胜利、断开，承受音讯等事件

总结

其实业务前端在平时工作中同样会须要封装一些供本人业务端应用的公共组件或插件，不便多个我的项目同时应用，也不便前期保护。
以上均为工作中的一些总结，还有很多须要改良和学习的中央，欢送大家提出问题与倡议。