前端写代码组件必须要封装的很好吗？

 

作为一名前端同学，主要工作就是数据的展示和处理用户的可视化交互

我们经常听说：“写代码要有良好的封装，要高内聚，低耦合”。那怎样才算良好的封装，我们为什么要封装呢？其实封装有这样几个好处：

封装好的代码，内部变量不会污染外部。可以作为一个模块给外部调用。外部调用者不需要知道实现的细节，只需要按照约定的规范使用就行了。对扩展开放，对修改关闭，即开闭原则。外部不能修改模块，既保证了模块内部的正确性，又可以留出扩展接口，使用灵活。

怎么封装代码呢？

JS生态已经有很多模块了，有些模块封装得非常好，我们使用起来很方便，比如jQuery，Vue等。如果我们仔细去看这些模块的源码，我们会发现他们的封装都是有规律可循的。这些规律总结起来就是设计模式，用于代码封装的设计模式主要有工厂模式，创建者模式，单例模式，原型模式四种。

前端同学在工作中一定少不了要和后端打交道，而API接口就是前端和后端之间的桥梁，后端同学按照约定好的接口格式返回前端所需要的数据，前端同学通过HTTP请求获取数据并呈现在用户面前。

如何做好封装和管理呢？我主要从以下几点展开：

HTTP库的选用

目前流行的HTTP库有很多，从最开始的原生XHR，到JQ ajax，再到现在fetch API，Axios，Superagent，其实选用哪一个库都可以，他们都有自己的优势，就看你是想更加方便地无脑式操作还是想从更底层地去调用和封装出你想要的效果，重点是你得清楚了解你选用的库所提供的API，尽其所用。

适配层的封装

为什么需要适配层？适配层的意义在于，提高代码的通用性和鲁棒性。

也就是说，哪天突然你真的觉得你所选用的HTTP库实在无法满足你的业务需求了，你可以将底层的HTTP库直接换掉也不会对你的项目造成太大的影响。这就是适配层发挥的作用。

业务层的封装

有了适配层的封装，我们可以更专注于业务上的逻辑处理，为了提高代码的复用性，我们可以根据业务需求，在适配层的基础上再加一层业务层。

接口数据规范化

所谓的接口数据规范化，其实就是对请求数据和响应数据的格式进行严格的约束。

我们经常会和后端同学共同约定出一份接口文档，规定哪个接口对应哪些字段，每个字段对应哪些数据类型，哪些字段是必填项，哪些字段为空时是不传还是返回null或者{}，诸如此类的，我们最多就只能根据约定形成一份接口文档，大家按照文档严格执行即可。但是现实永远不会如我们想象中完美，我们总会有bug的时候。所以理想化的方案就是，我们为每个接口定义出一个schema，请求数据和响应数据都严格按照这个schema，假如出现问题就进行错误捕捉，这样至少可以让我们在出bug的时候不会一脸懵逼。

最后说几点，以上都是本人在职坐标学习和实际工作项目开发中的一些小领悟和看法，不一定准确欢迎补充。