資訊專欄INFORMATION COLUMN
摘要：于是，轉(zhuǎn)換層就此誕生。轉(zhuǎn)換層顧名思義，把接口數(shù)據(jù)格式轉(zhuǎn)換成頁面所需要格式。第二版設(shè)計在第一版設(shè)計中，遇到轉(zhuǎn)換方法與使用頁面對應(yīng)不明確的問題。在第三版設(shè)計，也是從調(diào)整劃分子模塊方式下手，改回數(shù)據(jù)類型的維度劃分，同時，規(guī)范方法命名。
前言
在工作中，經(jīng)常會遇到，接口的數(shù)據(jù)格式與頁面布局/交互不匹配的情況，需要前端進行處理。 心想：“數(shù)據(jù)處理與業(yè)務(wù)無關(guān)，多帶帶抽離一個模塊來寫吧。” 于是，轉(zhuǎn)換層就此誕生。
第一版設(shè)計當(dāng)我設(shè)計模塊時，
第一步 會明確模塊的職責(zé)。
轉(zhuǎn)換層——顧名思義，把接口數(shù)據(jù)格式 轉(zhuǎn)換 成頁面所需要格式。
第二步 制定與其他模塊對接規(guī)則。
因為它是從頁面模塊抽離出來的，所以只有頁面模塊才能引用它。
而且邏輯單一（把輸入數(shù)據(jù)處理后輸出），所以它只能引用工具模塊。
第三步 劃分子模塊。
模塊主要是處理數(shù)據(jù)的問題，所以根據(jù)數(shù)據(jù)類型的維度劃分子模塊。
第一版設(shè)計大功告成
// 消息通知信息的轉(zhuǎn)換方法
// transform/notice.js
export default{
show(data) {
....
return ret;
}
}
// 面板頁使用 // page/dashboard import noticeModel from "model/notice.js"; //發(fā)送消息通知請求類 import noticeTransform from "transform/notice.js"; //轉(zhuǎn)換成頁面所需要接口格式 const data = await noticeModel.show().then(res => noticeTransform.show(res));
缺陷?。。?/strong>
第一版設(shè)計中，我們很難看出某個轉(zhuǎn)換方法，被那一個或幾個頁面使用。
隨著項目復(fù)雜度不斷增大，以后接手的小伙伴根本就不敢改/刪轉(zhuǎn)換層里的代碼。
在第一版設(shè)計中，遇到轉(zhuǎn)換方法與使用頁面對應(yīng)不明確的問題。
思考后，決定調(diào)整劃分子模塊方式，改為根據(jù)頁面維度劃分。
第二版成品
// 面板頁里的消息通知信息轉(zhuǎn)換方法
// 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?。?！
雖然能清晰識別頁面具有那些轉(zhuǎn)換方法，
但是，如果A與B、C...頁面，需要對相同的數(shù)據(jù)轉(zhuǎn)成相同格式。
這樣的模塊劃分，對相似代碼抽離是不友好的。
在第二版設(shè)計中，遇到相似的代碼難以復(fù)用的問題。
在第三版設(shè)計，也是從調(diào)整劃分子模塊方式下手，改回數(shù)據(jù)類型的維度劃分，
同時，規(guī)范方法命名。
給頁面模塊使用方法名= model名 + "for" + 頁面名稱，
私有方法名= "_" + model名 + 格式語義。
第三版成品
// A、B頁面 要把消息通知信息轉(zhuǎn)換一句提示
// transform/notice.js
const transform = {
_showOneTip(data) {
....
return ret;
},
showForA(data){
return this._showOneTip(data);
},
showForB(data){
return this._showOneTip(data);
}
}
export default transform;
總結(jié)
業(yè)務(wù)會不斷迭代優(yōu)化，其實代碼也需要不斷迭代優(yōu)化的過程。
在過程中不斷思考，盡可能把項目設(shè)計的更具有結(jié)構(gòu)性。
當(dāng)然，每次更新項目底層設(shè)計，工作量是不少，所以也要多感謝團隊支持。
同一個數(shù)據(jù)，有可能不同頁面有不同格式。
如何把模塊之間的聯(lián)系更加明確。
如何復(fù)用具有相同邏輯代碼。
細節(jié)轉(zhuǎn)換方法不能修改傳入數(shù)據(jù)。
江湖救急
筆者有兩年多前端開發(fā)經(jīng)驗（地點北京），比較擅長vue與性能優(yōu)化。
希望能進入具有Geek精神團隊，一起折騰，一起做有意思事情。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/54104.html
摘要：于是，轉(zhuǎn)換層就此誕生。轉(zhuǎn)換層顧名思義，把接口數(shù)據(jù)格式轉(zhuǎn)換成頁面所需要格式。第二版設(shè)計在第一版設(shè)計中，遇到轉(zhuǎn)換方法與使用頁面對應(yīng)不明確的問題。在第三版設(shè)計，也是從調(diào)整劃分子模塊方式下手，改回數(shù)據(jù)類型的維度劃分，同時，規(guī)范方法命名。 前言 在工作中，經(jīng)常會遇到，接口的數(shù)據(jù)格式與頁面布局/交互不匹配的情況，需要前端進行處理。 心想：數(shù)據(jù)處理與業(yè)務(wù)無關(guān)，單獨抽離一個模塊來寫吧。 于是，轉(zhuǎn)換層就...
摘要：經(jīng)調(diào)研發(fā)現(xiàn)，是個簡單高效且性能高的動畫方案。換言之，設(shè)計師用把動畫效果做出來，再用導(dǎo)出相應(yīng)地文件給到前端，前端使用庫就可以實現(xiàn)動畫效果。 項目背景 在海外項目中，為了優(yōu)化用戶體驗加入了幾處微交互動畫，實現(xiàn)方式是設(shè)計輸出合成的雪碧圖，前端通過序列幀實現(xiàn)動畫效果：?showImg(https://segmentfault.com/img/bVbp6jB);序列幀：showImg(https...
摘要：由于控件與業(yè)務(wù)邏輯之間的緊耦合，相應(yīng)帶來的問題就是變更的代價增大，以及難以編寫針對性的單元測試。這些東西的組合提供了到譯者注視圖模型后面統(tǒng)一簡稱之間的連接方式。的單元測試可以完全模擬在上用的那些功能。 原文：https://github.com/kuitos/kui...全部文章：https://github.com/kuitos/kui... [譯注] MVVM 模式 原文：The ...
摘要：表形容詞，意為的具有的。指的是一組架構(gòu)約束條件和原則。協(xié)議要優(yōu)于協(xié)議。的操作方法在中有各自的語義，理解它們的語義至為重要。返回結(jié)果對于不同操作方法和操作對象集合或個體，服務(wù)器返回的結(jié)果應(yīng)該符合以下規(guī)范。附錄該文主要參考理解架構(gòu)設(shè)計指南 前言 近十年，前端高速發(fā)展，整個互聯(lián)網(wǎng)應(yīng)用經(jīng)歷了從輕客戶端到重客戶端的變化，隨著前端規(guī)模越來越大，交互越來越復(fù)雜，前后端分離的設(shè)計開始流行。 移動互聯(lián)網(wǎng)...
閱讀 3713·2021-11-11 16:55
閱讀 1655·2021-10-08 10:04
閱讀 3591·2021-09-27 13:36
閱讀 2785·2019-08-30 15:53
閱讀 1870·2019-08-30 11:17
閱讀 1272·2019-08-29 16:55
閱讀 2111·2019-08-29 13:57
閱讀 2526·2019-08-29 13:13
