资讯专栏INFORMATION COLUMN

前端设计——数据转换层

zhigoo / 2122人阅读

摘要:于是,转换层就此诞生。转换层顾名思义,把接口数据格式转换成页面所需要格式。第二版设计在第一版设计中,遇到转换方法与使用页面对应不明确的问题。在第三版设计,也是从调整划分子模块方式下手,改回数据类型的维度划分,同时,规范方法命名。

前言

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

第一版设计

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

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

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

第一版设计大功告成
// 消息通知信息的转换方法
// 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));

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

第二版设计

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

第二版成品
// 面板页里的消息通知信息转换方法
// 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...页面,需要对相同的数据转成相同格式。
这样的模块划分,对相似代码抽离是不友好的。

第三版设计

在第二版设计中,遇到相似的代码难以复用的问题。
在第三版设计,也是从调整划分子模块方式下手,改回数据类型的维度划分
同时,规范方法命名。
给页面模块使用方法名= 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精神团队,一起折腾,一起做有意思事情。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/105136.html

相关文章

  • 前端设计——数据转换

    摘要:于是,转换层就此诞生。转换层顾名思义,把接口数据格式转换成页面所需要格式。第二版设计在第一版设计中,遇到转换方法与使用页面对应不明确的问题。在第三版设计,也是从调整划分子模块方式下手,改回数据类型的维度划分,同时,规范方法命名。 前言 在工作中,经常会遇到,接口的数据格式与页面布局/交互不匹配的情况,需要前端进行处理。 心想:数据处理与业务无关,单独抽离一个模块来写吧。 于是,转换层就...

    lei___ 评论0 收藏0
  • Lottie-前端实现AE动效

    摘要:经调研发现,是个简单高效且性能高的动画方案。换言之,设计师用把动画效果做出来,再用导出相应地文件给到前端,前端使用库就可以实现动画效果。 项目背景 在海外项目中,为了优化用户体验加入了几处微交互动画,实现方式是设计输出合成的雪碧图,前端通过序列帧实现动画效果:showImg(https://segmentfault.com/img/bVbp6jB);序列帧:showImg(https...

    supernavy 评论0 收藏0
  • [译注] MVVM 模式

    摘要:由于控件与业务逻辑之间的紧耦合,相应带来的问题就是变更的代价增大,以及难以编写针对性的单元测试。这些东西的组合提供了到译者注视图模型后面统一简称之间的连接方式。的单元测试可以完全模拟在上用的那些功能。 原文:https://github.com/kuitos/kui...全部文章:https://github.com/kuitos/kui... [译注] MVVM 模式 原文:The ...

    banana_pi 评论0 收藏0
  • 理解 RESTful

    摘要:表形容词,意为的具有的。指的是一组架构约束条件和原则。协议要优于协议。的操作方法在中有各自的语义,理解它们的语义至为重要。返回结果对于不同操作方法和操作对象集合或个体,服务器返回的结果应该符合以下规范。附录该文主要参考理解架构设计指南 前言 近十年,前端高速发展,整个互联网应用经历了从轻客户端到重客户端的变化,随着前端规模越来越大,交互越来越复杂,前后端分离的设计开始流行。 移动互联网...

    MkkHou 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<