資訊專欄INFORMATION COLUMN
摘要：當(dāng)年的加載在沒有前端工程化之前，基本上是我們是代碼一把梭，把所需要的庫和自己的代碼堆砌在一起，然后自上往下的引用就可以了。而且對于前后端的技術(shù)要求較高，所以對于項(xiàng)目未必是最有效的方案。
當(dāng)年的 js 加載
在沒有 前端工程化之前，基本上是我們是代碼一把梭，把所需要的庫和自己的代碼堆砌在一起，然后自上往下的引用就可以了。
那個(gè)時(shí)代我們沒有公用的cdn，也沒有什么特別好的方法來優(yōu)化加載js的速度。最多用以下幾個(gè)方案。
可以在代碼某些需要js的時(shí)候去使用 loadjs 來動(dòng)態(tài)加載 js 庫。這樣就不會(huì)出現(xiàn)開始時(shí)候加載大量js文件。
再大點(diǎn)的項(xiàng)目可能用一下 Nginx ngx_http_concat_module 模塊來合并多個(gè)文件在一個(gè)響應(yīng)報(bào)文中。也就是再加載多個(gè)小型 js 文件時(shí)候合并為一個(gè) js 文件。
BigPipe 技術(shù)也是可以對頁面分塊來進(jìn)行優(yōu)化的，但是因?yàn)榕c本文關(guān)系不大，方案也沒有通用化和規(guī)范化，加上本人其實(shí)沒有深入了解所不進(jìn)行深入介紹，如果先了解可以參考 新版賣家中心 Bigpipe 實(shí)踐（一） 以及 新版賣家中心 Bigpipe 實(shí)踐（二）。
當(dāng)然那個(gè)時(shí)期的代碼也沒有像現(xiàn)在的前端的代碼量和復(fù)雜度那么高。
Webpack 之后的js加載與其說 Webpack 是一個(gè)模塊打包器，倒不如說 Webpack 是一份前端規(guī)范。
需要庫沒有被大量使用情況對于我們代碼中所需要的代碼庫沒有大量使用，比如說某種組件庫我們僅僅只使用了 2、3個(gè)組件的情況下。我們更多需要按需加載功能。
比方說在 MATERIAL-UI 我們可以用
import TextField from "@material-ui/core/TextField"; import Popper from "@material-ui/core/Popper"; import Paper from "@material-ui/core/Paper"; import MenuItem from "@material-ui/core/MenuItem"; import Chip from "@material-ui/core/Chip";
代替
import {
TextField,
Popper,
Paper,
MenuItem,
Chip
} from "@material-ui"
這樣就實(shí)現(xiàn)了按需加載，而不是動(dòng)輒需要整個(gè)組件庫。但是這樣的代碼中這樣代碼并不好書寫。我們就需要一個(gè)幫助我們轉(zhuǎn)換代碼的庫。這可以參考 Babel 插件手冊 以及 簡單實(shí)現(xiàn)項(xiàng)目代碼按需加載 來實(shí)現(xiàn)我們的需求。
需要庫大量被使用情況如果我們的庫被當(dāng)前的項(xiàng)目大量使用了，按需加載其實(shí)就未必是最好的方法了，如果我們的服務(wù)器不是特別好的情況下我們可以使用 Webpack 的 externals 配置來優(yōu)化項(xiàng)目的js。就簡單的對 externals 配置簡單說明一下。externals其實(shí)是在全局中的得到庫文件。
// 頁面中使用 cdn，這樣的話，我們就會(huì)在 window 中得到 jQuery
// 也就是 global.JQuery 瀏覽器中 global === window
// 在項(xiàng)目中導(dǎo)入 jquery 使用
import $ from "jquery";
// 配置中 左邊是 配置的 jquery 告訴 Webpack 不需要導(dǎo)入
// 配置中 右邊是 配置的 JQuery 告訴 Webpack 記載 jquery 時(shí)候使用 global.JQuery
externals: {
jquery: "jQuery"
}
但是使用 externals 曾遇到這樣的情況。我在使用 material-ui 組件庫時(shí)候發(fā)現(xiàn)該庫在全局導(dǎo)出的代碼是 material-ui。
也就是:
externals: {
"@material-ui/core": "material-ui"
}
此時(shí)會(huì)發(fā)生導(dǎo)入錯(cuò)誤，錯(cuò)誤原因?yàn)? window.material-ui。
本來我是想要引入material-ui，卻 - 符號變?yōu)榱藴p號。
本來想要利用用 ["material-ui"] 來替換，卻發(fā)現(xiàn)行不通: windows.["material-ui"]
解決方法:
externals: {
"@material-ui/core": "window["material-ui"]"
}
因?yàn)?window 對象有自己引用自己，所以 window === window.window.window。所以代碼為 window.window["material-ui"]。可以參考 MDN Window.window
上文中的性能優(yōu)化方案依然可用 loadjs 動(dòng)態(tài)加載在當(dāng)前所需要 js 文件不需要大量使用同時(shí)需要的 js 文件是不需要開始時(shí)加載(如 React, React-Router 一類)的時(shí)候我們依然可以使用loadjs來加載(比如說 圖標(biāo)庫一類，只在某一些頁面使用)。
合并多個(gè)小型 js對于在 HTTP2 中合并多個(gè) 小js文件未必好。因?yàn)樵?HTTP2 中，HTTP 請求是廉價(jià)的，合并便不再顯得有優(yōu)勢。
BigPipe 方案當(dāng)然了,BigPipe 方案不是針對單頁面應(yīng)用程序。而且對于前后端的技術(shù)要求較高，所以對于項(xiàng)目未必是最有效的方案。
其他現(xiàn)如今也可以使用一些其他的方法。例如 Service Worker,Wasm 等一系列方案。不知道還有什么其他方法，也可以介紹給我。
參考文檔新版賣家中心 Bigpipe 實(shí)踐（一）
新版賣家中心 Bigpipe 實(shí)踐（二）
Babel 插件手冊
簡單實(shí)現(xiàn)項(xiàng)目代碼按需加載
MDN Window.window
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/104059.html
摘要：持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是大公司可能更偏向一些基礎(chǔ)或者原理布局一些經(jīng)典算法方面。現(xiàn)將我在面試過程遇到的問題總結(jié)下。目前先傳題目答案整理好之后再發(fā)布出來。 持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是：大公司可能更偏向一些JS基礎(chǔ)或者原理、html布局、一些經(jīng)典算法方面。小公司的面試更加側(cè)重對經(jīng)驗(yàn)和細(xì)節(jié)...
摘要：持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是大公司可能更偏向一些基礎(chǔ)或者原理布局一些經(jīng)典算法方面。現(xiàn)將我在面試過程遇到的問題總結(jié)下。目前先傳題目答案整理好之后再發(fā)布出來。 持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是：大公司可能更偏向一些JS基礎(chǔ)或者原理、html布局、一些經(jīng)典算法方面。小公司的面試更加側(cè)重對經(jīng)驗(yàn)和細(xì)節(jié)...
摘要：持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是大公司可能更偏向一些基礎(chǔ)或者原理布局一些經(jīng)典算法方面。現(xiàn)將我在面試過程遇到的問題總結(jié)下。目前先傳題目答案整理好之后再發(fā)布出來。 持續(xù)心累的找工作階段算是結(jié)束了，不同公司對面試的知識(shí)側(cè)重點(diǎn)不同，整體的感受就是：大公司可能更偏向一些JS基礎(chǔ)或者原理、html布局、一些經(jīng)典算法方面。小公司的面試更加側(cè)重對經(jīng)驗(yàn)和細(xì)節(jié)...
摘要：針對上面看到的問題，現(xiàn)在也有一些團(tuán)隊(duì)在嘗試前后端之間加一個(gè)中間層比如淘寶的。淘寶有很多類似的文章，這里不贅述。淘寶團(tuán)隊(duì)做了兩套接口文檔的維護(hù)工具，以及，不知道有沒有對外開放，兩個(gè)東西都是基于的一個(gè)嘗試，各有優(yōu)劣。 原文出處： 小胡子哥的博客（@Barret李靖） 前后端分工協(xié)作是一個(gè)老生常談的大話題，很多公司都在嘗試用工程化的方式去提升前后端之間交流的效率，降低溝通成本，并且也開發(fā)了...
閱讀 2406·2021-11-18 10:02
閱讀 1922·2021-10-13 09:40
閱讀 2999·2021-09-07 10:07
閱讀 2106·2021-09-04 16:48
閱讀 1005·2019-08-30 13:18
閱讀 2452·2019-08-29 14:03
閱讀 2922·2019-08-29 12:54
閱讀 3155·2019-08-26 11:41
