作者：yeyan1996

https://juejin.im/post/5c76843af265da2ddd4a6dd0

寫在前面

馬上到了金三銀四的時間，很多公司開啟了今年第一輪招聘的熱潮，雖說今年是互聯網的寒冬，但是只要對技術始終抱有熱情以及有過硬的實力，即使是寒冬也不會阻撓你前進的步伐。在面試的時候，往往在二面，三面的時面試官會結合你的簡歷問一些關于你簡歷上項目的問題，而以下這個問題在很多時候都會被問到

在這個項目中你有遇到什么技術難點，你是怎么解決的？

其實這個問題旨在了解你在遇到問題的時候的解決方法，畢竟現在前端技術領域廣，各種框架和組件庫層出不窮，而業務需求上有時紛繁復雜，觀察一個程序員在面對未知問題時是如何處理的，這個過程相對于只出一些面試題來考面試者更能了解面試者實際解決問題的能力

而很多人會說我的項目不大，并沒有什么難點，或者說并不算難點，只能說是一些坑，只要google一下就能解決，實在不行請教我同事，這些問題并沒有困擾我很久。其實我也遇到過相同的情況，和面試官說如何通過搜索引擎解決這些坑的吧不太好，讓面試官認為你只是一個API Caller，但是又沒有什么值得一談的項目難點

我的建議是，如果沒有什么可以深聊的技術難點，不妨在日常開發過程中，試著封裝幾個常用的組件，同時嘗試分析項目的性能瓶頸，尋找一些優化的方案，同樣也能讓面試官對你有一個整體的了解

在這篇文章中，我會分享在我目前公司的項目里，是如何在滿足業務需求的基礎上，讓整個系統煥然一新的過程

技術棧是Vue + Element的單頁面應用

起源

在我剛入職的那會，編碼能力不怎么好，加上之前離職的前端技術棧是React，接手這個Vue項目的時候，代碼高度的耦合，而那個時候因為能力有限，也只是在他的基礎上繼續開發，好在接手的時候開發進度也只是剛剛開始，因此在幾個月后的某一天，我做了一個決定：準備把整個項目重寫

得益于整個后臺管理系統都是我獨立開發的，項目的不足點我都深有體會，并且修改的時候能夠更加的自由，恰好在那段時間看了花褲衩的vue-element-admin，我決定新開一個工程把之前的代碼全部重寫

項目結構

之前我有打算基于Webpack4自己寫個腳手架用來打包文件，但是那段時間剛好Vue-cli3剛剛發布正式版并且也是基于Webpack4封裝的，于是想了一下還決定使用新的Vue-cli3腳手架搭建，最后我將項目分為以下層級

├─api?????????????????????????????????//api接口
├─assets??????????????????????????????//項目運行時使用到的圖片和靜態資源
├─components??????????????????????????//組件
│??├─BaseEllipsis?????????????????????//業務組件?(Base開頭都是全局組件)
│??├─BasePagination???????????????????//分頁器組件???
│??├─BaseIcon?????????????????????????//svg圖標組件
│??├─BaseToggle???????????????????????//業務組件
│??├─BaseTable????????????????????????//表格組件
│??├─FormPanel????????????????????????//業務組件(Form開頭是圍繞表單相關的小組件)
│??├─TableOptions?????????????????????//業務組件(Table開頭是圍繞表格相關的小組件)
│??├─TheBreadcrumb????????????????????//面包屑組件(The開頭是每個頁面組件只會引入一次的無狀態組件)
|??├─TheSidebar???????????????????????//側邊欄組件
│??├─TransitionSildeDown??????????????//業務組件(Transition開頭是動畫組件)
│??└─index.js?????????????????????????//全局組件自動注冊的腳本
│??
├─directives??????????????????????????//自定義指令
├─element?????????????????????????????//elementui
├─errorLog????????????????????????????//錯誤捕獲
├─filters?????????????????????????????//全局過濾器
├─icons???????????????????????????????//svg圖標存放文件夾
├─interface???????????????????????????//TypeScript接口
├─mixins??????????????????????????????//局部混入
├─router??????????????????????????????//vue-router
│??├─modules??????????????????????
│??└─index.js???????????
├─store????????????????????????????????//vuex
│??├─modules??????????????????????
│??└─index.js??????????????????????
├─style????????????????????????????????//全局樣式/局部頁面可復用的樣式
├─util????????????????????????????????//公共的模塊(axios,cookie封裝,工具函數)
├─vendor??????????????????????????????//類庫文件
└─views???????????????????????????????//頁面組件(所有給用戶顯示的頁面)

一個良好的項目分層在業務迭代的時候能夠快速找到對應的模塊進行修改，而不是在茫茫的代碼海中找到其中的某一行代碼

性能優化

在我重寫整個系統之前，每次打包都會花費好幾分鐘的時間，并且打包后的項目超過了17M

然而在我優化系統之后，打包后的體積只有2M，縮小了8倍

這里我從以下4個方面分享一下我在項目中是如何改善系統的性能，讓系統"步履如飛"的

• 網絡請求相關

• 構建相關

• 靜態資源優化

• 編碼相關

網絡請求相關

這部分旨在實現需求的前提下盡量減少http請求的開銷，或者減少響應時間

CDN

將第三方的類庫放到CDN上，能夠大幅度減少生產環境中的項目體積，另外CDN能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上

另外因為CDN和服務器的域名一般不是同一個，可以緩解同一域名并發http請求的數量限制,有效分流以及減少多余的cookie的發送(CDN上面的靜態資源請求時不需要攜帶任何cookie)

通俗的來說就是使用CDN會一定程度上提升項目中的靜態文件的傳輸速度，在vue-cli3中可以通過externals配置項，將第三方的類庫的引用地址從本地指向你提供的CDN地址

externals只適用于ES Module的默認導入

這里通過環境變量來判斷生產環境才啟用CDN，除了需要開啟CDN外，你還需要在index.html注入CDN的域名，所以我這里通過html-webpack-plugin根據cdn域名動態的注入script標簽，同時需要在index.html中通過模版的語法聲明循環的數組和注入的元素

打包前的index.html:

打包后的index.html:

可以看到通過這個插件可以將cdn域名動態的注入到打包后的index.html中

還有一點要注意的是，externals對象的屬性為你引入包的名字，而屬性值是對應的全局變量名稱(CDN引入的類庫文件會自動掛載到window對象下面，而掛載時的屬性名需要去對應的CDN在源碼中尋找，一般在開頭行都會有聲明,除此之外導入還有困難的還可以看下這篇博客webpack externals 深入理解)

這里還是建議盡量放到公司專用的CDN上，不推薦使用公共的CDN，因為容易掛，生產環境還是以穩定為主吧

合理的緩存策略

將長時間不會改變的第三方類庫或者靜態資源設置為強緩存,將max-age設置為一個非常長的時間,再將訪問路徑加上哈希達到哈希值變了以后保證獲取到最新資源(vue-cli3會自動構建,自己搭建的webpack腳手架需要自行配置contentHash,chunkHash)

CDN上的緩存策略,可以看到max-age的值非常大,這樣下次訪問就只會讀取本地磁盤/內存中緩存的資源:

對于index.html和一些圖片等多媒體資源,可以選擇協商緩存(max-age<=0,Last-Modified,ETag),保證返回服務器最新的資源

一個好的緩存策略,有助于減輕服務器的壓力,并且顯著的提升用戶的體驗

gzip

為你的文件開啟gzip壓縮是一個不錯的選擇，通常開啟gzip壓縮能夠有效的縮小傳輸資源的大小，如果你的項目是用nginx作為web服務器的話，只需在nginx的配置文件中配置相應的gzip選項就可以讓你的靜態資源服務器開啟gzip壓縮

????#開啟和關閉gzip模式
????gzip?on;
????#gizp壓縮起點，文件大于1k才進行壓縮
????gzip_min_length?1k;
????#?gzip?壓縮級別，1-9，數字越大壓縮的越好，也越占用CPU時間
????gzip_comp_level?6;
????#?進行壓縮的文件類型。
????gzip_types?text/plain?application/javascript?application/x-javascript?text/css?application/xml?text/javascript?;
????#nginx對于靜態文件的處理模塊，開啟后會尋找以.gz結尾的文件，直接返回，不會占用cpu進行壓縮，如果找不到則不進行壓縮
????gzip_static?on
????#?是否在http?header中添加Vary:?Accept-Encoding，建議開啟
????gzip_vary?on;
????#?設置gzip壓縮針對的HTTP協議版本
????gzip_http_version?1.1;

但是我們這里要說的是前端輸出gzip文件，利用compression-webpack-plugin讓webpack在打包的時候輸出.gz后綴的壓縮文件

這樣不需要服務器主動壓縮我們就已經可以得到gzip文件，在上面的nginx配置項中可以發現這一行

?#nginx對于靜態文件的處理模塊，開啟后會尋找以.gz結尾的文件，直接返回，不會占用cpu進行壓縮，如果找不到則不進行壓縮
????gzip_static?on

只要把.gz的文件放到服務器上，開始gzip_static就可以讓服務器優先返回.gz文件，在面對高流量時，也能一定程度減輕對服務器的壓力，屬于用空間來換時間(.gz文件會額外占有服務器的空間)

資源嗅探

對于現代瀏覽器來說，可以給link標簽添加preload,prefetch,dns-prefetch屬性

preload

對于SPA應用來說,當瀏覽器解析完script腳本才會生成DOM節點,如果你的項目中沒有使用服務端渲染的話且需要加載一個比較耗時的首屏圖片時,可以考慮將這個首屏圖片放在preload標簽中讓瀏覽器預先請求并加載執行,這樣當script腳本執行完畢后就會瞬間加載圖片(否則需要等腳本執行完畢后再向后臺請求圖片)

另外使用preload預加載首屏需要的css樣式也是一個不錯的選擇,類似的庫有critical

沒有使用preload

使用preload

通過Waterfall可以看到這個webp圖片需要等到腳本加載完之后才回去請求,如果這個圖片比較大就會浪費不必要的時間

在工程中，利用一些preload的webpack插件可以很方便的給打包后的index.html注入預加載的資源標簽，有興趣的朋友可以試著搜索一下相關的插件

prefetch

prefetch可以讓瀏覽器提前加載下個頁面可能會需要的資源,vue-cli3默認會給所有懶加載的路由添加prefetch屬性，這樣可以在你訪問使用到懶加載的路由頁面時能夠獲得更快的加載速度

preload和prefetch的區別在于，preload的資源會和頁面需要的靜態資源并行加載，而prefetch則會等到瀏覽器加載完必要的資源后，在空閑時間加載被標記為prefetch的資源

dns-prefetch

dns-prefetch可以讓瀏覽器提前對域名進行解析，減少DNS查找的開銷,如果你的靜態資源和后端接口不是同一個服務器的話，可以將考慮你后端的域名放入link標簽加入dns-prefetch屬性

京東首頁也使用到了dns-prefetch技術

http2

http2從2015年問世以來已經走過了4個年頭，如今在國內也有超過50%的覆蓋率，得益于http2的分幀傳輸，它能夠極大的減少http(s)請求開銷

http2和http1.1的性能差異對比

如果系統首屏同一時間需要加載的靜態資源非常多，但是瀏覽器對同一域名的tcp連接數量是有限制的(chrome為6個)超過規定數量的tcp連接，則必須要等到之前的請求收到響應后才能繼續發送，而http2則可以在一個tcp連接中并發多個請求沒有限制，在一些網絡較差的環境開啟http2性能提升尤為明顯

這里極力推薦在支持https協議的服務器中使用http2協議,可以通過web服務器Nginx配置，或是直接讓服務器支持http2

nginx開啟http2非常簡單,在nginx.conf中只需在原來監聽的端口后面加上http2就可以了,前提是你的nginx版本不能低于1.95，并且已經開啟了https

listen?443?ssl?http2;

在network中通過protocol可以查看到當前的資源是通過哪個版本的http協議傳輸的

h2代表http2

構建相關

構建方面通過合理的配置構建工具，達到減少生產環境的代碼的體積，減少打包時間，縮短頁面加載時間

路由懶加載

傳統的路由組件是通過import靜態的打包到項目中，這樣做的缺點是因為所有的頁面組件都打包在同一個腳本文件中，導致生產環境下首屏因為加載的代碼量太多會有明顯的卡頓(白屏)

通過import()使得ES6的模塊有了動態加載的能力，讓url匹配到相應的路徑時，會動態加載頁面組件，這樣首屏的代碼量會大幅減少，webpack會把動態加載的頁面組件分離成單獨的一個chunk.js文件

當然懶加載也有缺點，就是會額外的增加一個http請求，如果項目非常小的話可以考慮不使用路由懶加載

預渲染

由于瀏覽器在渲染出頁面之前，需要先加載和解析相應的html,css和js文件，為此會有一段白屏的時間，如何盡可能的減少白屏對用戶的影響，目前我選擇的是在html模版中，注入一個loading動畫，這里我拿D2-Admin中的loading動畫舉例

html>
<html>
??<head>
????<meta?charset="utf-8">
????<meta?http-equiv="X-UA-Compatible"?content="IE=edge">
????<meta?name="viewport"?content="width=device-width,initial-scale=1.0">
????<link?rel="icon"?href="icon.ico">
????<title><%=?VUE_APP_TITLE?%>title>
????<style>html,?body,?#app?{?height:?100%;?margin:?0px;?padding:?0px;?}.d2-home?{?background-color:?#303133;?height:?100%;?display:?flex;?flex-direction:?column;?}.d2-home__main?{?user-select:?none;?width:?100%;?flex-grow:?1;?display:?flex;?justify-content:?center;?align-items:?center;?flex-direction:?column;?}.d2-home__footer?{?width:?100%;?flex-grow:?0;?text-align:?center;?padding:?1em?0;?}.d2-home__footer?>?a?{?font-size:?12px;?color:?#ABABAB;?text-decoration:?none;?}.d2-home__loading?{?height:?32px;?width:?32px;?margin-bottom:?20px;?}.d2-home__title?{?color:?#FFF;?font-size:?14px;?margin-bottom:?10px;?}.d2-home__sub-title?{?color:?#ABABAB;?font-size:?12px;?}style>
??head>
??<body>
????<noscript>
??????<strong>
????????很抱歉，如果沒有 JavaScript 支持，D2Admin 將不能正常工作。請啟用瀏覽器的 JavaScript 然后繼續。
??????strong>
????noscript>
????<div?id="app">
??????<div?class="d2-home">
????????<div?class="d2-home__main">
??????????<imgclass="d2-home__loading"src="./image/loading/loading-spin.svg"alt="loading">
??????????<div?class="d2-home__title">
????????????正在加載資源
??????????div>
??????????<div?class="d2-home__sub-title">
????????????初次加載資源可能需要較多時間?請耐心等待
??????????div>
????????div>
????????<div?class="d2-home__footer">
??????????<ahref="https://github.com/d2-projects/d2-admin"target="_blank">
????????????https://github.com/d2-projects/d2-admin
??????????a>
????????div>
??????div>
????div>
??body>
html>

在打包完成后，在這個index.html下方還會注入頁面的腳本，當用戶訪問你的項目時，腳本還沒有執行，但是可以顯示loading動畫，因為它是直接注入在html中的，等到腳本執行完畢后，Vue會新生成一個app的節點然后將舊的同名節點刪除，這樣可以有效的過渡白屏的時間

loading動畫只是一個讓用戶感知到你程序正在啟動的效果，只是一個靜態頁面沒有任何的功能

另外預渲染還可以使用服務端渲染(SSR)，通過后端輸出一個首頁的模版，或者使用骨架屏的方案，這里本人沒有深入的了解過，有興趣的朋友可以去實踐一下

升級到最新的webpack版本

webpack4相對于webpack3來說在打包優化方面性能提升還是比較明顯的，如果覺得自己配置腳手架比較復雜的話，可以使用vue-cli3來構建你的項目，同樣是基于webpack4搭建的

DllPlugin

當沒有一個穩定的CDN時，使用DllPlugin這個webpack插件同樣可以將類庫從業務代碼中分離出去，其原理是預先將類庫文件打包，隨后創建一個關聯表，在業務代碼依賴第三方類庫時，會直接去關聯表中獲取已經打包好的類庫文件。這樣做的好處在于因為業務代碼會常常需要打包上線，而第三方類庫基本不會改變，所以每次打包可以跳過這些類庫文件，減少不必要的重復打包

DllPlugin是一個webpack內置的插件，無需安裝，但是要讓打包后的index.html注入這些打包后第三方類庫，需要額外安裝add-asset-html-webpack-plugin插件

當你需要在index.html中注入多個類庫時，需要實例化多次add-asset-html-webpack-plugin，這里我們可以利用nodejs的fs模塊，遍歷DllPlugin打包后的目錄，根據類庫的數量決定需要生成多少個實例，非常的靈活，具體的配置項可以查看我底部的鏈接

合理使用第三方庫

如果項目中有一些日期操作的需求，不妨將目光從moment轉移到day，相對于笨重的moment，它只有2kb，day和moment的api完全一樣，并且中文文檔也比較友好

另外對于lodash這類的庫如果只需要部分功能，則只要引入其中一部分，這樣webpack在treeshaking后在生產環境也只會引入這一部分的代碼

對于UI庫(element-ui)打包后的體積也會非常大，盡量使用按需加載，官方文檔上也有詳細教程

element-ui的壓縮后的體積竟然是Vue的十倍

常用的路徑創建文件別名

給常用的模塊路徑創建一個別名是一個不錯的選擇，可以減少模塊查找時耗費的時間，項目越大收益也就越明顯

vue-cli3中的配置和使用方法(webpack鏈式調用文檔)

使用可視化工具分析打包后的模塊體積

我通過webpack-bundle-analyzer這個插件在每次打包后能夠更加直觀的分析打包后模塊的體積，再對其中比較大的模塊進行優化

這是我在優化前的各模塊體積:

因為業務需求,要求前端導出pdf和excel文件,我這里引入了xlsx和pdf.js這2個包,但是打包后通過可視化工具發現光著2個文件就占了一半的項目體積,另外elementui和moment也非常的大

這是優化后通過可視化工具觀察到的各模塊體積,通過將這些類庫放到CDN上或者使用dllPlugin將類庫和業務文件分離,可以看到沒有明顯特別大的模塊了

靜態資源優化

這部分旨在減少請求一些圖片資源所造成的影響

圖片懶加載

如果你的系統是一個偏展示的項目需要給用戶展示大量圖片，是否啟用圖片懶加載可能是你需要考慮的一個點，不在用戶視野中的圖片是沒有必要加載的，圖片懶加載通過讓圖片先加載成一張統一的圖片，再給進入用戶視野的圖片替換真正的圖片地址，可以同一時間減少http請求開銷，避免顯示圖片導致的畫面抖動，提高用戶體驗

下面我提供2種圖片懶加載的思路，這2個方案最終都是用將占位的圖片替換成真正的圖片，然后給img標簽設置一個自定義屬性src存放真正的圖片地址，src存放占位圖片的地址

getBoundingClientRect

DOM元素包含一個getBoundingClientRect方法，執行該方法返回當前DOM節點相關的CSS邊框集合

其中有一個top屬性代表當前DOM節點距離瀏覽器窗口頂部的高度，只需判斷top值是否小于當前瀏覽器窗口的高度(window.innerHeight)，若小于說明已經進入用戶視野，然后替換為真正的圖片即可

另外使用getBoundingClientRect作圖片懶加載需要注意3點

因為需要監聽scroll事件，不停的判斷top的值和瀏覽器高度的關系，請對監聽事件進行函數節流

當屏幕首次渲染時，不會觸發scroll事件，請主動調用一次事件處理程序，否則若用戶不滾動則首屏的圖片會一直使用懶加載的默認圖片

當所有需要懶加載的圖片都被加載完，需要移除事件監聽，避免不必要的內存占用

IntersectionObserver

IntersectionObserver作為一個構造函數，傳入一個回調函數作為參數，生成一個實例observer，這個實例有一個observe方法用來觀察指定元素是否進入了用戶的可視范圍，隨即觸發傳入構造函數中的回調函數

同時給回調函數傳入一個entries的參數，記錄著這個實例觀察的所有元素的一些閾值信息(對象)，其中intersectionRatio屬性表示圖片進入可視范圍的百分比，大于0表示已經有部分進入了用戶視野

此時替換為真實的圖片，并且調用實例的unobserve將這個img元素從這個實例的觀察列表的去除

實例代碼

對懶加載還有迷惑的同學我這里寫了一個DEMO可以參考一下實現的方式源代碼

結論

這2種的區別在于監聽的方式，我個人更推薦使用Intersection Observer，因為通過監聽scroll事件開銷比較大，而讓將這個工作交給另一個線程異步的去監聽開銷會小很多，但是它的缺點是一些老版本的瀏覽器可能支持率不高，好在社區有polyfill的方案

或者可以直接使用第三方的組件庫vue-lazyload

使用svg圖標

相對于用一張圖片來表示圖標，svg擁有更好的圖片質量，體積更小，并且不需要開啟額外的http請求，svg是一個未來的趨勢，阿里的圖標庫iconfont支持導出svg格式的圖標，但是在項目中需要封裝一個支持svg的組件，具體封裝的教程可以參考花褲衩的文章這里就不多贅述了手摸手，帶你優雅的使用 icon,或者可以參考我的github

使用webp圖片

webp圖片最初在2010年發布，目標是減少文件大小，但達到和JPEG格式相同的圖片質量，希望能夠減少圖片檔在網絡上的發送時間。webp圖片無損比png圖片無損的平均體積要小 20%~40%，并且圖片質量用肉眼看幾乎沒什么差別

webp圖片的缺點是兼容性并不是那么的好，在can l use 上查到webp圖片的支持率并不是那么的理想。但是我們仍可以在支持webp圖片的瀏覽器中使用它，而在不支持的瀏覽器提供png圖片

這里需要使用到響應式圖片,HTML提供了picture標簽讓我們可以在不同設備中使用不同的圖片格式

MDN:

HTML元素通過包含零或多個元素和一個 ?元素來為不同的顯示/設備場景提供圖像版本。瀏覽器會選擇最匹配的子元素，如果沒有匹配的，就選擇 ?元素的 src 屬性中的URL。然后，所選圖像呈現在元素占據的空間中。

在工程中我們可以這樣使用

picture標簽包裹2個source標簽,一個提供webp圖片,通過srcset屬性讓瀏覽器從上到下選擇可以支持的圖片格式,如果瀏覽器不支持webp圖片會只使用第二個source,會回退到png圖片,如果瀏覽器不支持picture標簽,會使用底部的img標簽,同樣也會生成一個png圖片

picture標簽的瀏覽器支持率,相對于webp要好很多(注意底部的img標簽無論如何都要有，否則就算支持webp圖片也無法渲染出圖片)

壓縮圖片

對于一些png圖片可能質量會非常的高，但是對于Web平臺來說，用戶可能并不care圖片的畫質問題，但是如果加載圖片導致頁面出現卡頓那就顯得得不償失了，我們可以考慮將一些畫質較高的圖片做壓縮處理，我這里使用tinypng幫我壓縮圖片，同樣能夠保證在肉眼幾乎分辨不出區別的情況下，提供一個體積較小的圖片，如果有其他好的壓縮軟件也可以推薦給我

另外有一個圖片壓縮的 loader ?image-webpack-loader，在用戶肉眼分辨不清的情況下一定程度上壓縮圖片

編碼相關

編碼這方面主要是減少對DOM的訪問，減少瀏覽器的重排/重繪，訪問DOM是非常昂貴的操作，因為會涉及到2個不同的線程交互(JS線程和UI渲染線程)并且DOM本身又是一個非常笨重的對象，這里給出幾個建議

• 如果有需要動態創建DOM的需求，可以創建一個文檔碎片(DocumentFragment)，在文檔碎片中操作因為不是在當前文檔流不會引起重排/重繪，最后再一次性插入DOM節點

• 避免頻繁獲取視圖信息(getBoundingClientRect,clientWidth,offsetWidth),當發生重排/重繪操作時瀏覽器會維護一個隊列，等到超過了最大值或過了指定時間(1000ms/60 = 16.6ms)才會去清空隊列一次性執行操作，這樣可以節省性能，而獲取視圖信息會立刻清空隊列執行重排/重繪

• 高頻的監聽事件使用函數防抖/節流(可以使用lodash庫的throttle函數，但是推薦先搞懂原理)

• 特效可以考慮單獨觸發渲染層(CSS3的transform會觸發渲染層)，動畫可以使用絕對定位脫離文檔流

開發過程中小技巧

使用require.context這個webpack的api可以避免每次引入一個文件都需要顯式的用import導入，它可以掃描你指定的文件，然后全部導入到指定文件，可以用在

• vue-router的路由自動導入

• vuex的模塊自動導入

• svg圖標的自動導入

• 全局組件的自動導入

vuex：

這樣在創建一個新的模塊時,不需要在index.js中用import引入,在modules中再聲明一遍了

全局組件和svg圖標：

避免了每創建一個全局組件都需要引入,在調用一次Vue.component的過程,而當加載到Svg組件會自動掃描icons文件夾,將所有svg圖標導入進來

封裝組件

有人會說，github上那么多好的開源組件，好的開源庫放著不用，為啥自己還要折騰呢？

其實我認為自己動手封裝一個組件還是很有意義的，因為如果是從零開始編寫的組件，你能夠更好的掌握自己組件的所有功能，并且還能根據公司的業務需求定制一些特殊的功能，除此之外，理解一個組件內部的實現機制也有助于提升個人的編碼能力，而不是別人問起來你只知道我用過某個組件，很好用，但是不知道是怎么做到的。所以我還是比較推薦去嘗試編寫幾個常用的組件

因為是后臺管理系統,核心的組件肯定是表單組件和表格組件,公共組件是基于element組件的二次封裝,組件的設計遵循以下的思路

• 高內聚低耦合,盡可能少的暴露組件的api,將功能盡量封裝在組件內部

• 組件內部根據業務需求設置了一些組件默認的配置項,另外再通過不同頁面傳入不同配置項提高組件的通用性

設計組件的目的就是讓組件進一步解耦,將配置項和模板標簽分離,一方面是減少在業務邏輯組件中的代碼量,另一方面就是單獨抽離的配置項使得能夠通過后臺動態傳遞給前端,或者自己建一個配置項的js/ts文件(如果有規范的開發者文檔還可以使用nodejs編寫一個讀取開發者文檔一鍵寫入配置項的腳本,進一步提升開發效率)

表格組件

表格組件設計大致分為以下幾個部分

• 盡量貼近element組件庫的api

• 傳入一個表頭的配置項數組,通過這個配置項動態生成el-table-columns標簽

• 交互復雜的表頭列的解決方式

盡量貼近element組件庫的api

組件中使用了

不能識別此Latex公式: attrs,listeners實現屬性和監聽事件的跨級傳遞，使得在頁面中給自定義組件中的傳入的屬性能夠通過自定義組件內部的轉發直接成為el-table標簽的屬性,達到跨級的屬性傳遞,而不能識別此Latex公式: listeners和attrs類似,能夠監聽el-table組件中觸發的事件,將事件轉發 ? 到頁面中的自定義組件上

自定義組件:

這樣做的目的就是能讓你的自定義組件和el-table組件有相同的用法,傳入的屬性,監聽的事件也是相同的

在頁面中使用自定義組件,可以看到z-table和el-table的用法幾乎是相同的,只需要額外傳入一個columns的屬性:

表頭的配置項設計

繼續給這個表格組件添加表頭標簽,這里我把一些不必要的判斷都去除了,只留下了核心的邏輯,實際在組件內部只需要循環這個配置項動態生成el-table-column標簽就可以了

自定義組件:

配置項文件:

這里的核心是在于這個v-bind,當v-bind后面等號里放入的是一個對象時,它會遍歷這個對象的所有屬性,將屬性和值一一做綁定

什么意思呢?這里結合配置項文件來說明,如果傳入上述的配置項,組件的內部實際是這樣子的

拋開key不談，在配置項的每個元素中暴露一個attrs屬性，里面保存了所有el-table-column標簽可以接受的屬性。例子中label，prop，width這3個屬性是在配置項每個元素的attrs屬性中的，通過v-bind="column.attrs"讓這3個屬性和它們的值分別在el-table-column標簽中做了綁定,從而達到了模板和配置項解耦的目的

交互復雜的表頭列的解決方式

對于一些需要特別處理的表頭列的數據，我在組件內部利用插槽和作用域插槽，通過插槽定義表頭列的插入位置，再通過作用域插槽將信息返回給父組件，在父組件中定義如何顯示,使得表格組件非常的靈活能夠應對大部分業務需求

可以看到具名插槽的名字也是通過配置項傳入的,并且作用域插槽將整個表單內部的數據通過scope傳給父組件,在復雜的業務場景,無法通過配置項解決問題的時候,通過插槽和作用域插槽讓父組件去決定如何去處理數據

配置項中添加插槽屬性:

頁面組件:

在頁面組件中,可以和element提供的作用域插槽的使用方式相似,通過scope可以訪問到組件內部的所有數據并且交給頁面組件去做復雜的邏輯處理

其他功能

針對公司的需求，我對組件做了進一步的改造

• 使用render函數使得表頭顯示能夠更加靈活

• 配置項暴露一個函數能夠讓當前列的數據執行這個函數達到預處理的效果

• 配置項中設置一個二維數組，能夠讓數據字段組合，達到數據顯示在不同的行數的效果

• 添加了操作圖標

• 添加了數據(code碼)轉對應中文語義的功能

源代碼

表格組件

表單組件

表單組件相對于表格組件在實現方面要困難一點，因為表單的控件非常多，每個配置項又需要非常靈活,這里我借鑒了之前在知乎看到的一篇博客,文章中雖然沒有把代碼列出來,但是羅列了整體的實現方案,隨后我根據文章中的思路設計了這個表單組件

設計大致分為以下幾個部分

• 表單配置項設計

• 表單驗證

• 表單請求

• 表單控件之間的聯動

• 調用后端接口生成表單控件的選項

表單配置項設計

根據上面的表格組件的封裝思路,還是利用

不能識別此Latex公式:
attrs做根元素屬性的傳遞,用v-bind在配置項中設置組件內部的屬性

表單組件:

配置項文件:

和表格組件不同的是,因為表單組件分為el-form-item標簽和表單控件2部分,這2個部分都需要在配置項中對應配置屬性,在配置項中使用itemAttrs控制el-form-item標簽的屬性,使用attrs控制表單控件的屬性

這里還用到了component標簽,通過配置項的tag標簽動態生成el-input的表單控件,但是可以看到這里我并沒有直接將tag的值設為el-input,那input是如何變成el-input的呢?

這里我又定義了每個組件通用的配置項,使得不需要每次都在組件的attrs中聲明一些重復的屬性,比如placeholder,clearable等

通用配置項文件:

最重要的是我建立了組件配置項和通用配置項之間的關聯,通過組件配置項中的tag屬性找到通用配置項對應的對象,結合上面的例子如果tag的值是input,那就會從通用配置項中找到input屬性對應的對象,并且將真實的tag值指向通用配置項的component,這里就是el-input

而這種關聯又是怎么建立起來的呢,其實還是用了Object.assgin做了對象之間的合并

核心邏輯如下(參數formItem指的是組件配置項formItems中的每個元素):

這里定義了一個computeFormItem的函數，通過傳入配置項數組的每個元素，根據元素的tag值找到通用配置項(basic對象)中相應的值，隨后用了Object.assgin做了合并，關于這個computeFormItem函數我稍后在后面的表單控件之間的聯動中會詳細去講

通用和組件配置項都有了,接下來要實現的是表單組件需要上傳給后端的數據對象

這里我的思路是通過配置項中聲明的字段名(key)動態生成數據對象,這樣可以減少傳入的配置項的數量,在組件內部聲明Model變量保存數據對象

但是這里有2點需要注意

因為組件內部聲明的Model是一個空對象,Vue的響應式系統是監聽不到對象創建了新的屬性,需要使用set來設置，使得能夠強制更新視圖

這里需要通過formItems對Model數據對象賦值，如果放在mounted鉤子中執行的話拿到的是一個空數組，所以我這里使用watch來監聽formItems，并且使用immediate立即執行(用computed聲明一個新數組理論上也可以)

表單驗證

表單驗證方面盡量貼合element組件的傳入方式，保持所有在el-form-item標簽中寫的屬性都寫在itemAttrs中，所有在表單控件中寫的屬性都寫在attrs中，所以可以在itemAttrs中編寫表單驗證方面的邏輯

表單請求

表單請求方面，因為在重構時新建了api文件夾，存放的是一個個后端接口的api函數，做到一個頁面對應一個api文件夾中的一個接口文件

每個接口文件中可以導出多個接口的函數

在表單組件中只需要聲明一個api的props讓頁面組件傳入就可以了

隨后給提交按鈕綁定click事件，進行表單驗證最后執行接口函數，傳入Model這個數據對象即可

在接口函數調用成功返回響應數據后，我這里通過觸發after-submit的事件讓頁面組件監聽這個事件，并且把響應數據傳給頁面組件，這樣頁面組件就能拿到響應的數據并且做一些處理了

頁面組件監聽after-submit事件：

表單控件之間的聯動

這一部分我認為也是最難實現的，在日常的業務需求中可能需要某個控件控制另外一個控件顯示與否

核心的思路就是在配置項中定義一個getAttrs的函數，這個函數根據當前Model，也就是數據對象中的某個值動態的生成一個attrs對象，最后將這個attrs對象通過合并到當前配置項的attrs中，另外還定義了一個ifRender函數，可以控制表單控件是否被渲染，最后我們的配置項可能長這樣

接下來表單組件內部要實現如何執行這2個函數，依舊是之前的computeFormItem這個函數，它用來計算出當前表單組件的配置項

和上面的computeFormItem函數不同的是，我這里傳入了第二個參數Model，使得當前的表單組件配置項能夠根據Model動態的變化，在內部執行getAttrs函數傳入這個Model，返回的對象通過Object,assgin合并到當前的配置項中，而對于另一個ifRender函數，也傳入Model，返回一個Boolean值，最后用這個Boolean值在模版中通過v-if控制是否渲染表單控件

這里要分析一下整個表單最核心的部分：computeFormItem函數，它的作用是根據當前Model中的數據變化，動態的生成一個新的配置項，因為我們的表單控件是根據配置項映射而成的，需要改變表單控件只能去修改配置項

根據上面那個圖可以發現，我們并沒有直接使用頁面組件傳來的formItems配置項，而是根據_formItems循環渲染的標簽，而_formItems是基于formItems并且經過computeFormItem生成的配置項，只要Model中的數據改變，這個配置項就需要重新計算生成新的值，所以我選擇把_formItems放在計算屬性中

這樣，只要依賴項(這里是Model和formItems)變了，就會觸發函數重新計算出新的_formItems

下拉框/單選框/復選框

在表單組件中，我使用component標簽動態生成表單控件，但是對于一些有子節點的表單控件通過component實現就有些困難，這里我將含有子節點的組件(下拉框/單選框/復選框)又進行了一層封裝，消除了子節點，讓所有屬性都在component這一層配置

自定義select組件

這樣以來只要在配置項中聲明一個options屬性，通過component標簽將組件轉為自定義的select組件，讓options屬性就會變為select組件的屬性，這樣在自定義的select組件內部可以通過$attrs.options獲取到它(這里注意value,label必須都要顯式的聲明否則會報錯，因為element組件內部會對傳入的屬性驗證)

組件配置項文件：

這里再次利用通用配置項文件，將組件配置項中聲明的select組件的配置項映射到自定義的select組件中

調用后端接口生成表單控件的選項

在真實的業務需求中，部分下拉框，單選框的選項是通過拉取后端的接口生成的。放在表單組件中的話還是需要修改配置項，在頁面組件中修改formItem。找到下拉框/單選框的key，將接口的數據賦值給options屬性

總結

可以看到表單組件還是比較復雜的，其實這個表單組件相對于表格組件來說還是有一定的局限性，后續可能會給它設計插槽的功能。另外真實的業務需求肯定是更加復雜多變的，不管怎么說，一些交互邏輯不是特別復雜的表單這個組件還是能hold住的，本人能力有限，這里也只是給一個思路，希望后續能夠愈發完善

推薦閱讀

三年 Git 使用心得 & 常見問題整理「1.3萬字」「 墻裂推薦」互聯網人必備GIF制作的14種選擇「 Map最佳實踐」什么時候適合使用 Map 而不是 Object

參考資料

vue-element-adminD2 Admin嗨，送你一張Web性能優化地圖vue-cli3 項目從搭建優化到docker部署前端性能優化不完全指北加快Vue項目的開發速度再也不想寫表單了

總結

以上是生活随笔為你收集整理的axios传数组到后台_我是如何让公司后台管理系统焕然一新的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。