国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

前端設計——數據轉換層

lei___ / 1885人閱讀

摘要:于是,轉換層就此誕生。轉換層顧名思義,把接口數據格式轉換成頁面所需要格式。第二版設計在第一版設計中,遇到轉換方法與使用頁面對應不明確的問題。在第三版設計,也是從調整劃分子模塊方式下手,改回數據類型的維度劃分,同時,規范方法命名。

前言

在工作中,經常會遇到,接口的數據格式與頁面布局/交互不匹配的情況,需要前端進行處理。 心想:“數據處理與業務無關,多帶帶抽離一個模塊來寫吧。” 于是,轉換層就此誕生。

第一版設計

當我設計模塊時,
第一步 會明確模塊的職責。
轉換層——顧名思義,把接口數據格式 轉換 成頁面所需要格式。

第二步 制定與其他模塊對接規則。
因為它是從頁面模塊抽離出來的,所以只有頁面模塊才能引用它。
而且邏輯單一(把輸入數據處理后輸出),所以它只能引用工具模塊。

第三步 劃分子模塊。
模塊主要是處理數據的問題,所以根據數據類型的維度劃分子模塊。

第一版設計大功告成
// 消息通知信息的轉換方法
// 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精神團隊,一起折騰,一起做有意思事情。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/54104.html

相關文章

  • 前端設計——數據轉換

    摘要:于是,轉換層就此誕生。轉換層顧名思義,把接口數據格式轉換成頁面所需要格式。第二版設計在第一版設計中,遇到轉換方法與使用頁面對應不明確的問題。在第三版設計,也是從調整劃分子模塊方式下手,改回數據類型的維度劃分,同時,規范方法命名。 前言 在工作中,經常會遇到,接口的數據格式與頁面布局/交互不匹配的情況,需要前端進行處理。 心想:數據處理與業務無關,單獨抽離一個模塊來寫吧。 于是,轉換層就...

    zhigoo 評論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元查看
<