前端設計——數據轉換層

前言

在工做中，常常會遇到，接口的數據格式與頁面佈局/交互不匹配的狀況，須要前端進行處理。 心想：「數據處理與業務無關，單獨抽離一個模塊來寫吧。」 因而，轉換層就此誕生。

初版設計

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

第二步 制定與其餘模塊對接規則。
由於它是從頁面模塊抽離出來的，因此只有頁面模塊才能引用它。
並且邏輯單一（把輸入數據處理後輸出），因此它只能引用工具模塊。

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

初版設計大功告成

// 消息通知信息的轉換方法
// 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精神團隊，一塊兒折騰，一塊兒作有意思事情。