導讀：最近入職了一家互聯網公司，主要是做物聯網及互聯網解決方案方向，我上來就接手了這個專案，是一個可視化管理地圖，主要用于某國企物業的安全預警的職能，說來也比較倒霉，剛來這公司，公司做這個專案的前端和后端都跑路了，然后讓我一個月給他整改完，說是重構吧，還不是，說不是重構吧，頁面全讓我改造了，變得更加有科技感，炫酷，性能提升了一部分，相當于頁面重寫，后端基本不用改什么東西，主要提供資料即可，新增的介面添加能展示資料即可，
前言
來這個公司的原因是因為我覺得這個公司屬于偏初創公司，有一定的規模，有一定的挑戰性，比大廠作業更加忙碌一些，我以前在一家國內互聯網外包巨頭行業作業，感覺比較閑，就是 965 那種模式，有可能是早點走，晚點到的那種狀態，作業地點還不穩定，如果不跟專案的話，基本都是外派到保險公司（人保，人壽，國壽財及泰康等駐場開發），一兩個月更新一點小功能就好，可以遠程，可以駐場開發，中午休息兩個半小時也比較舒服，福利待遇一般，工資一般，后來去了這家新公司，嘗試去做一些有挑戰性的事情，這段時間一直加班，晚上 8 點管飯，10 點之后打車報銷，沒有加班費，可以調休，然后一個人接手了這個專案，后來又來了一個哥們（java 工程師）添加一些介面及資料，
前端用到的一些技術點
做這個專案主要用到的是 vue+echarts+百度地圖+高德地圖+PDF.js+elementUI+vue-seamless-scroll 等，
為什么選 vue,不選 React 或者 Angular?
React 和 Vue 有許多相似之處，它們都有：
使用 Virtual DOM提供了回應式 (Reactive) 和組件化 (Composable) 的視圖組件，將注意力集中保持在核心庫，而將其他功能如路由和全域狀態管理交給相關的庫，
由于有著眾多的相似處，我們會用更多的時間在這一塊進行比較，這里我們不只保證技術內容的準確性，同時也兼顧了平衡的考量，我們需要承認 React 比 Vue 更好的地方，比如更豐富的生態系統，
React 和 Vue 都是非常快的，所以速度并不是在它們之中做選擇的決定性因素，
在 React 應用中，當某個組件的狀態發生變化時，它會以該組件為根，重新渲染整個組件子樹，
如要避免不必要的子組件的重渲染，你需要在所有可能的地方使用 PureComponent，或是手動實作 shouldComponentUpdate 方法，同時你可能會需要使用不可變的資料結構來使得你的組件更容易被優化，
然而，使用 PureComponent 和 shouldComponentUpdate 時，需要保證該組件的整個子樹的渲染輸出都是由該組件的 props 所決定的，如果不符合這個情況，那么此類優化就會導致難以察覺的渲染結果不一致，這使得 React 中的組件優化伴隨著相當的心智負擔，
在 Vue 應用中，組件的依賴是在渲染程序中自動追蹤的，所以系統能精確知曉哪個組件確實需要被重渲染，你可以理解為每一個組件都已經自動獲得了 shouldComponentUpdate，并且沒有上述的子樹問題限制，
Vue 的這個特點使得開發者不再需要考慮此類優化，從而能夠更好地專注于應用本身，
在 React 中，一切都是 JavaScript，不僅僅是 HTML 可以用 JSX 來表達，現在的潮流也越來越多地將 CSS 也納入到 JavaScript 中來處理，這類方案有其優點，但也存在一些不是每個開發者都能接受的取舍，
Vue 的整體思想是擁抱經典的 Web 技術，并在其上進行擴展，
在 React 中，所有的組件的渲染功能都依靠 JSX，JSX 是使用 XML 語法撰寫 JavaScript 的一種語法糖，
使用 JSX 的渲染函式有下面這些優勢：
你可以使用完整的編程語言 JavaScript 功能來構建你的視圖頁面，比如你可以使用臨時變數、JS 自帶的流程控制、以及直接參考當前 JS 作用域中的值等等，開發工具對 JSX 的支持相比于現有可用的其他 Vue 模板還是比較先進的 (比如，linting、型別檢查、編輯器的自動完成)，
事實上 Vue 也提供了渲染函式，甚至支持 JSX，然而，我們默認推薦的還是模板，任何合乎規范的 HTML 都是合法的 Vue 模板，這也帶來了一些特有的優勢：
對于很多習慣了 HTML 的開發者來說，模板比起 JSX 讀寫起來更自然，這里當然有主觀偏好的成分，但如果這種區別會導致開發效率的提升，那么它就有客觀的價值存在，基于 HTML 的模板使得將已有的應用逐步遷移到 Vue 更為容易，這也使得設計師和新人開發者更容易理解和參與到專案中，你甚至可以使用其他模板前處理器，比如 Pug 來書寫 Vue 的模板，
有些開發者認為模板意味著需要學習額外的 DSL (Domain-Specific Language 領域特定語言) 才能進行開發——我們認為這種區別是比較膚淺的，首先，JSX 并不是沒有學習成本的——它是基于 JS 之上的一套額外語法，同時，正如同熟悉 JS 的人學習 JSX 會很容易一樣，熟悉 HTML 的人學習 Vue 的模板語法也是很容易的，最后，DSL 的存在使得我們可以讓開發者用更少的代碼做更多的事，比如 v-on 的各種修飾符，在 JSX 中實作對應的功能會需要多得多的代碼，
更抽象一點來看，我們可以把組件區分為兩類：一類是偏視圖表現的 (presentational)，一類則是偏邏輯的 (logical)，我們推薦在前者中使用模板，在后者中使用 JSX 或渲染函式，這兩類組件的比例會根據應用型別的不同有所變化，但整體來說我們發現表現類的組件遠遠多于邏輯類組件，
Angular 事實上必須用 TypeScript 來開發，因為它的檔案和學習資源幾乎全部是面向 TS 的，TS 有很多好處——靜態型別檢查在大規模的應用中非常有用，同時對于 Java 和 C# 背景的開發者也是非常提升開發效率的，
然而，并不是所有人都想用 TS——在中小型規模的專案中，引入 TS 可能并不會帶來太多明顯的優勢，在這些情況下，用 Vue 會是更好的選擇，因為在不用 TS 的情況下使用 Angular 會很有挑戰性，
最后，雖然 Vue 和 TS 的整合可能不如 Angular 那么深入，VUE 也提供了官方的型別宣告和組件裝飾器，并且知道有大量用戶在生產環境中使用 Vue + TS 的組合，VUE 也和微軟的 TS / VSCode 團隊進行著積極的合作，目標是為 Vue + TS 用戶提供更好的型別檢查和 IDE 開發體驗，
使用 vue 腳手架可以快速的進行開發，上手也很快，雖然我接觸的技術堆疊也比較多，但是很難達到精通的級別，無疑，這是一個很好的選擇，
使用 Echarts 的目的
使用這個 Echarts 主要是在大屏上做一些柱狀圖及餅狀圖，把資料以圖表的形式進行展示，這個 echars 使用起來比較簡單，一般找個簡單的模板進行套用即可，
Echarts 的官網：http://echarts.apache.org/zh/index.html
這個是百度的一個產品，最近專案被范訓，有時候經常打不開，可以換個網路或者瀏覽器，實在不行可以使用 w3c 的 echarts 教程，屬性也比較全，比菜鳥教程好很多，
這個如何使用我就不說了，想了解的可以參考官網教程：https://echarts.apache.org/zh/tutorial.html#5%20%E5%88%86%E9%92%9F%E4%B8%8A%E6%89%8B%20ECharts
使用百度地圖的目的
這個專案原先是用的百度的衛星地圖，衛星地圖看起來比較模糊，不過功能都好使，
<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="viewport" content="initial-scale=1.0, user-scalable=no" /> <style type="text/css"> body, html,#allmap {width: 100%;height: 100%;overflow: hidden;margin:0;font-family:"微軟雅黑";}</style> <script type="text/javascript" src="//api.map.baidu.com/api?type=webgl&v=1.0&ak=您的密鑰"></script> <title>地球模式</title></head><body> <div id="allmap"></div></body></html><script type="text/javascript"> // GL版命名空間為BMapGL var map = new BMapGL.Map("allmap"); // 創建Map實體 map.centerAndZoom(new BMapGL.Point(118.5, 27.5), 5); // 初始化地圖,設定中心點坐標和地圖級別 map.enableScrollWheelZoom(true); //開啟滑鼠滾輪縮放 map.setMapType(BMAP_EARTH_MAP); // 設定地圖型別為地球模式</script>
后來在資料看板又加了一個靈魂地圖，使用的是高德地圖，
可能有人問，用一個地圖不就行了？用兩個不會引起性能方面的問題？說實話，確實會降低性能，不過客戶要求好看，就只能魚和熊不可兼得，
百度地圖 API:https://lbsyun.baidu.com/index.php?title=jspopularGL
如果使用下鉆功能，進行地理位置定位，在中國地圖上進行打點，確定經緯度，使用其他地圖都能取值，經緯度需要注意一下，別搞反了，
使用 vue-seamless-scroll 滾動插件的目的
這個可以使表格的資料自動滾動，看起來更酷，資料量比較多自動滾動，資料量比較少不讓他滾動，滑鼠懸浮資料暫停，
官方 gitHub：https://github.com/chenxuan0000/vue-seamless-scroll
檔案：https://chenxuan0000.github.io/vue-seamless-scroll/guide/
主要配置項：
computed: { classOption() { return { step: 0.5, // 數值越大速度滾動越快 limitMoveNum: 1, // 開始無縫滾動的資料量 this.dataList.length hoverStop: true, // 是否開啟滑鼠懸停stop direction: 1, // 0向下 1向上 2向左 3向右 openWatch: true, // 開啟資料實時監控重繪dom singleHeight: 0, // 單步運動停止的高度(默認值0是無縫不停止的滾動) direction => 0/1 singleWidth: 0, // 單步運動停止的寬度(默認值0是無縫不停止的滾動) direction => 2/3 waitTime: 1000, // 單步運動停止的時間(默認值1000ms) // isSingleRemUnit:true, //singleHeight and singleWidth是否開啟rem度量 false/true limitMoveNum:5,//開啟無縫滾動的高度,原始碼設定為表格資料量小于5就不讓她滾動， }; } }
使用 vue-seamless-scroll 自動滾動插件復制出來的資料點擊事件無效的解決辦法
問題分析：
當第一個 ul 中的資料滾動完時（真實資料）,第二個 ul 部分的 click 事件不起作用（復制出來的資料），無法實作一些點擊這行，彈窗詳情資訊業務需要功能，
我需要這些資料添加一些點擊事件，彈出二級頁面及區域切換效果，
解決辦法：
采用事件委托的方式：
事件委托又叫事件代理，就是利用事件冒泡，只指定一個事件處理程式，就可以管理某一型別的所有事件，
一般來說，DOM需要有事件處理程式，我們都會直接給它設定事件處理程式就好了，但是如果有很多DOM需要添加處理事件，比如，一個ul下有很多個li，需要給每個li都添加相同的點擊事件，這時候我們通常會用for回圈的方法，遍歷所有元素，然后給他們添加點擊事件，雖然看似內心毫無波瀾很合理的做法，背后實則存在著巨大的性能弊端，
在JS中，添加到頁面上的事件處理程式數量將直接關系到頁面的整體運行性能，因為需要不斷的與DOM節點進行互動，所以訪問DOM的次數越多，引起瀏覽器重繪與重排的次數也就越多，就會延長整個頁面的互動就緒時間，這就是為什么性能優化的主要思路就是從減少DOM操作的角度去入手的原因，
這種情況，如果用時間委托，就會將所有的操作都放到JS程式里面，與DOM的操作就只需要互動一次，這樣就能大大的減少與DOM的互動次數；并且，每一個函式都是一個物件，是物件就會占用記憶體，物件越多，記憶體占用率就越大，性能自然就會越差，如果使用事件委托，我們就可以只對它的父級這一個物件進行操作，這樣我們就值需要一個記憶體空間就夠了，大量節省了記憶體空間，提高整體頁面的性能了，
給外層 div 加點擊事件，通過 event.target 獲取到點擊的 dom 元素
給點擊的列的元素系結 屬性，這里我系結了 id 和自定義屬性 data-obj 物件，直接把改列的 item 添加進去，不用一個一個單獨系結，
點擊方法，把原來的點擊方法取消，直接在這個底部呼叫，
寫了一個比較通用的方法其它幾個頁面按照這個方法也很好用，不用一個個系結，那個類 row 純屬做了一個標志位，便于回圈之后的判斷，如果不清楚，直接 console.log,便于定位每個變數，
瀏覽器在線 PDF 預覽取消下載按鈕
需要在線 PDF 下載的功能，剛開始用的是第三方的 PDF.JS，按照網上的方法操作，排查，發現沒有作用，經過和后端小伙伴溝通，原來這個地址是瀏覽器 PDF 預覽，
瀏覽器 PDF 取消辦法：在需要 URL 地址后邊加上代碼
'#toolbar=0'
加了代碼：
或者
修改完看下效果：
上面的整行黑條都沒了
順便說一下
PDF.JS 取消下載的辦法：
viewer.html 添加隱藏樣式，
viewer.js 注釋如下代碼，版本不一樣，行數一般不一樣，建議用編譯器 ctrl+f 進行檢索 download，
還有一處，這個版本不一樣，代碼不一樣，一樣注釋掉方法
總結
這個專案做的東西很多都是第一次接觸，學到的東西還是挺多的，每天都加班到很晚才回家，主要原因是缺人，我自己再做，還有一個原因是我對這方便的技術不熟悉，導致作業效率有點低，再者就是甲方安排的需求多變，不斷的加需求，這邊都沒人寫需求檔案，前端做了大量的回圈及寫了大量的假資料進行展示，導致整個系統性能稍微低下一點，已經采取了如下優化：
用了線上的服務器進行演示，發現甲方測驗服務器和正式服務器配置都不是一個檔次，好在我前后端都會搞，今天的內容就分享到這里，簡單分享一下部分內容，謝謝大家，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/286404.html
標籤：其他