前言

在工作中，经常会遇到，接口的数据格式与页面布局/交互不匹配的情况，需要前端进行处理。心想：“数据处理与业务无关，单独抽离一个模块来写吧。” 于是，转换层就此诞生。

part1

当我设计模块时，
第一步会明确模块的职责。
转换层——顾名思义，把接口数据格式转换成页面所需要格式。

第二步制定与其他模块对接规则。
因为它是从页面模块抽离出来的，所以只有页面模块才能引用它。
而且逻辑单一（把输入数据处理后输出），所以它只能引用工具模块。

第三步划分子模块。
模块主要是处理数据的问题，所以根据数据类型的维度划分子模块。

第一版设计大功告成

// 消息通知信息的转换方法
// transform/notice.js
export default{
    show(data) {
        ....
        return ret;
    }
}

// 面板页使用
// page/dashboard
import noticeModel from 'model/notice.js'; //发送消息通知请求类
import noticeTransform  from 'transform/notice.js';
//转换成页面所需要接口格式
const data = await noticeModel.show().then(res => noticeTransform.show(res));

缺陷！！！
第一版设计中，我们很难看出某个转换方法，被那一个或几个页面使用。
随着项目复杂度不断增大，以后接手的小伙伴根本就不敢改/删转换层里的代码。

part2

在第一版设计中，遇到转换方法与使用页面对应不明确的问题。
思考后，决定调整划分子模块方式，改为根据页面维度划分。

第二版成品

// 面板页里的消息通知信息转换方法
// transform/dashboard.js
export default{
    noticeShow(data) {
        ....
        return ret;
    }
}

// 面板页使用
// page/dashboard
import noticeModel from 'model/notice.js'; 
import dashboardTransform  from 'transform/dashboard.js';

const data = await noticeModel.show().then(res => dashboardTransform.noticeShow(res));

缺陷 Again！！！
虽然能清晰识别页面具有那些转换方法，
但是，如果A与B、C...页面，需要对相同的数据转成相同格式。
这样的模块划分，对相似代码抽离是不友好的。

part3

在第二版设计中，遇到相似的代码难以复用的问题。
在第三版设计，也是从调整划分子模块方式下手，改回数据类型的维度划分，
同时，规范方法命名。
暴露给页面模块方法名= model名 + 'for' + 页面名称，
私有方法名= '_' + model名 + 格式语义。

第三版成品

// A、B页面 要把消息通知信息转换一句提示
// transform/notice.js
const transform = {
    _showOneTip(data) {
        ....
        return ret;
    },
    showForA(data){
        return this._showOneTip(data);
    },
    showForB(data){
        return this._showOneTip(data);
    }
}

export default transform;

总结

项目会不断迭代优化，其实代码也需要不断迭代优化的过程。
在过程中不断思考，尽可能把项目设计的更具有结构性。
当然，每次更新项目底层设计，工作量是不少，所以也要多感谢团队支持。

难点

同一个数据，有可能不同页面有不同格式。
如何把模块之间的联系更加明确。
如何复用具有相同逻辑代码。

细节

转换方法不能修改传入数据。

江湖救急

笔者有两年多前端开发经验（地点北京），比较擅长vue与性能优化。
希望能进入具有Geek精神团队，一起折腾，一起做有意思事情。