前端的一生，離不開三件事，相容，ui與後端介面。
在剛開始工作沒多久的時候，看著後端提供的那串玩意就在想，應該怎麼樣才能優雅的處理這幾串東西。在工作的轉場中，我試圖從別人身上去尋找那份答案，但終究都不是我想要的那份真物。
在學習的路上，接觸了幾種方式
剛剛開始碰到的是游擊戰模式，介面路徑，他在這頭，她又在另外一頭，有時候他在這頭，他還在另外一頭。
this.$fetch('api/commodity')
function login ()
複製**
第二份工作時，在專案結構中看到了乙個api.js，裡面記錄了一些後端介面的路徑,在使用的時候，直接引用這個檔案。
src/api
epxort default
this.$fetch(this.$api.login)
複製**
再後來，寫後台管理時，看到了一整個api目錄，開啟一看，一堆堆結構一樣的函式正在出廠
export function login ()
export function userinfo ()
export function getcommoditydetail (id)
複製**
但是，隨之帶來大量的冗餘，對於程式設計師來說，怎麼能忍。在可讀性不降低的情況下，能少乙個字元，絕不加多乙個字元
乙個個無產階級拿起了鋤頭和鐮刀，創造了各種工廠函式，通過簡單的資料結構批量生產出介面函式，從手動擋進化成自動擋，大大減少了重複勞動力。這裡我推下我的解決方案box-cat。更具體可以看強行震驚！竟然解決了請求介面中的冗餘
import from 'box-cat'
import response from 'src/response' // response可以是axios、flyio.js之類的http請求庫
import data from 'src/data'
const api = createapis(data, response)
const apiproxy = createproxy(data, response)
複製**
工廠帶來的是整個export default匯出，雖然有proxy模式，但是與進廠那段，缺少了export的按需引入，**明確這兩個特點。為了補充這兩個特點，我們總不能將出廠的產品每乙個都手動export出去吧，那不就脫褲子放屁，而且還low。
在**了一些ast的操作後，決定去寫乙個loader去解決這個問題。然後開始跌跌撞撞，手忙腳亂的弄完了人生第乙個loader——box-cat-loader。
建議的目錄結構，如果專案不大，可以直接乙個api/index.js寫完
├── response.js // http請求庫
├── api
| ├── module // 各模組的介面路徑
| ├── index.js // 呼叫box-cat
複製**
複製**
npm i box-cat-loader -d
複製**
// 例子
module.exports = }}
]},}複製**
// 資料匯出只支援export default{}
// 在api的index.js中資料引入可以是:
import data from 'src/api/module'
// 也可以是
import order from 'src/api/module/order'
import commodity from 'src/api/module/commodity'
const data =
複製**
前端內容佔位技術分享
所謂內容佔位技術，意思是說在內容比較多，資料量大的情況下，可以事先將一些標籤替代它們的位置，等到載入完畢的時候再將其隱藏。注意這和以前的懶載入不是乙個意思，兩個不起衝突，懶載入的原理就是事先用乙個較小的loading，等使用者到達這個位置的高度時再去獲取相應的資料。內容佔位技術就是模擬它可能會顯示出...
前端內容佔位技術分享
所謂內容佔位技術，意思是說在內容比較多，資料量大的情況下，可以事先將一些標籤替代它們的位置，等到載入完畢的時候再將其隱藏。注意這和以前的懶載入不是乙個意思，兩個不起衝突，懶載入的原理就是事先用乙個較小的loading，等使用者到達這個位置的高度時再去獲取相應的資料。內容佔位技術就是模擬它可能會顯示出...
第四次技術分享 後端技術
後端深奧，看了書也很難理解，而且學習周期長，qaq，以前學過前端，講簡單的前端知識才有把握，至於後端，只有平時和技術人員交流時才能了解。後台服務之rpc框架 後台的作用就是提供服務，按客戶端的要求，將業務資料回吐給請求者。後端涉及技術棧非常多但其核心技術是rpc 遠端過程呼叫，過程 可看做提供服務的...