用 Yarn 你還能做這 5 件事 [譯]

在 JavaScript 領(lǐng)域中有幾個(gè)包管理器: npm，bower，component，和 volo。到本文為止，最受歡迎的包管理器是 npm。npm 客戶端提供了對(duì) npm 注冊(cè)庫(kù)中成千上萬(wàn)代碼的訪問(wèn)。Facebook 推出了一款名叫 Yarn 的包管理器，聲稱比現(xiàn)有的 npm 客戶端更快，更可靠，更安全。

Yarn 是 一個(gè)由 Facebook 創(chuàng)建的新 JavaScript 包管理器。為開發(fā)者使用 JavaScript 開發(fā) app 時(shí)提供了快速，高可用，并且安全的依賴管理。下面有可以用 Yarn 做的五件事情：

• 1. 離線工作
• 2. 從多個(gè)注冊(cè)表安裝
• 3. 快速獲取安裝包
• 4. 自動(dòng)鎖定安裝包版本
• 5. 在不同的機(jī)器上以同樣的方式安裝依賴

前端自動(dòng)化測(cè)試探索

測(cè)試是完善的研發(fā)體系中不可或缺的一環(huán)。前端同樣需要測(cè)試，你的css改動(dòng)可能導(dǎo)致頁(yè)面錯(cuò)位、js改動(dòng)可能導(dǎo)致功能不正常。由于前端偏向GUI軟件的特殊性，盡管測(cè)試領(lǐng)域工具層出不窮，在前端的自動(dòng)化測(cè)試上面卻實(shí)施并不廣泛，很多人依舊以手工測(cè)試為主。本文試圖探討前端自動(dòng)化測(cè)試領(lǐng)域的工具和實(shí)踐。

為什么需要自動(dòng)化測(cè)試？一個(gè)項(xiàng)目最終會(huì)經(jīng)過(guò)快速迭代走向以維護(hù)為主的狀態(tài)，在合理的時(shí)機(jī)以合理的方式引入自動(dòng)化測(cè)試能有效減少人工維護(hù)成本。自動(dòng)化測(cè)試的收益可以簡(jiǎn)單總結(jié)為：自動(dòng)化的收益 = 迭代次數(shù) * 全手動(dòng)執(zhí)行成本 - 首次自動(dòng)化成本 - 維護(hù)次數(shù) * 維護(hù)成本。對(duì)于自動(dòng)化測(cè)試來(lái)說(shuō)，相對(duì)于發(fā)現(xiàn)未知的問(wèn)題，更傾向于避免可能的問(wèn)題。

首先本文不會(huì)探討單元測(cè)試方向，因?yàn)閱螠y(cè)已經(jīng)有完善的工具體系。但前端開發(fā)中，除了一些框架和庫(kù)，愿意去寫單測(cè)的少之又少。另外單測(cè)維護(hù)成本較高，而且也沒(méi)法滿足前端測(cè)試的所有需求。前端自動(dòng)化測(cè)試可以在幾個(gè)方向進(jìn)行嘗試：

• 界面回歸測(cè)試 測(cè)試界面是否正常，這是前端測(cè)試最基礎(chǔ)的環(huán)節(jié)
• 功能測(cè)試 測(cè)試功能操作是否正常，由于涉及交互，這部分測(cè)試比界面測(cè)試會(huì)更復(fù)雜
• 性能測(cè)試 頁(yè)面性能越來(lái)越受到關(guān)注，并且性能需要在開發(fā)過(guò)程中持續(xù)關(guān)注，否則很容易隨著業(yè)務(wù)迭代而下降。
• 頁(yè)面特征檢測(cè) 有些動(dòng)態(tài)區(qū)域無(wú)法通過(guò)界面對(duì)比進(jìn)行測(cè)試、也沒(méi)有功能上的異常，但可能不符合需求。例如性能測(cè)試中移動(dòng)端大圖素材檢測(cè)就是一種特征檢測(cè)，另外常見(jiàn)的還有頁(yè)面區(qū)塊靜態(tài)資源是否符合預(yù)期等等。

用github來(lái)展示你的前端頁(yè)面吧

全球架構(gòu)師峰會(huì)

QQ空間前端工程

QQ空間的hybrid頁(yè)面首屏優(yōu)化方案webso，因?yàn)榛顒?dòng)頁(yè)面、運(yùn)營(yíng)頁(yè)面的需要，亦或者客戶端開發(fā)周期長(zhǎng)，需要采用H5的技術(shù)方案，越來(lái)越多的H5頁(yè)面內(nèi)嵌在客戶端里了, 即所謂hybrid形式。

QQ空間如何優(yōu)化hybrid頁(yè)面：把H5頁(yè)面內(nèi)嵌在QQ空間客戶端里面，是一個(gè)開發(fā)重點(diǎn)轉(zhuǎn)型的問(wèn)題，也是面臨的新的優(yōu)化課題。hybrid頁(yè)面主要體現(xiàn)在兩個(gè)客戶端：QQ空間客戶端和手Q客戶端

當(dāng)初面臨的主要體驗(yàn)問(wèn)題是：

• 客戶端的webview啟動(dòng)太慢，尤其是android上
• 頁(yè)面加載有白屏的過(guò)程所以我們的精力也主要集中于來(lái)解決這兩個(gè)問(wèn)題。

中國(guó)第二屆CSS Conf總結(jié)

瀏覽器的渲染性能

• 你所做的頁(yè)面，不但要能被快速加載，還要能流暢運(yùn)行：頁(yè)面的滾動(dòng)要快速響應(yīng)手指的動(dòng)作，動(dòng)畫和交互效果更要如絲般順滑。要想編寫高性能的web站點(diǎn)或應(yīng)用，你需要充分了解瀏覽器是如何處理HTML/JavaScript/CSS的，從而確保你寫的代碼（或引用的第三方代碼）是盡可能高效的。
• 60fps和設(shè)備刷新率:當(dāng)今大多數(shù)設(shè)備的屏幕刷新率都是 60次/秒 。因此，如果在頁(yè)面中有一個(gè)動(dòng)畫或漸變效果，或者用戶正在滑動(dòng)頁(yè)面，那么瀏覽器渲染動(dòng)畫或頁(yè)面的每一幀的速率，也需要跟設(shè)備屏幕的刷新率保持一致。
• 像素渲染流水線:在編寫web頁(yè)面時(shí)，你需要理解你所寫的頁(yè)面代碼是如何被轉(zhuǎn)換成屏幕上顯示的像素的。這個(gè)轉(zhuǎn)換過(guò)程可以歸納為這樣的一個(gè)流水線，包含五個(gè)關(guān)鍵步驟：JavaScript、計(jì)算樣式、布局、繪制、渲染層合并。
• 課程：瀏覽器渲染性能

別再為了this發(fā)愁了------JS中的this機(jī)制

• 誤解一：this引用function本身
• 誤解二：this引用的是function的詞法作用域
• 規(guī)則一：默認(rèn)綁定全局變量，當(dāng)函數(shù)被單獨(dú)定義和調(diào)用的時(shí)候，應(yīng)用的規(guī)則就是綁定全局變量
• 規(guī)則二：隱式綁定，函數(shù)調(diào)用時(shí)擁有一個(gè)上下文對(duì)象，就好像這個(gè)函數(shù)是屬于該對(duì)象的一樣
• 規(guī)則三：顯示綁定，bind()\apply()\call()函數(shù)
• 規(guī)則四：new新對(duì)象綁定，用new來(lái)調(diào)用，那么綁定的將是新創(chuàng)建的對(duì)象

JS 的 new 到底是干什么的？?

少做四件事

• 不用創(chuàng)建臨時(shí)對(duì)象，因?yàn)?new 會(huì)幫你做（你使用「this」就可以訪問(wèn)到臨時(shí)對(duì)象）；
• 不用綁定原型，因?yàn)?new 會(huì)幫你做（new 為了知道原型在哪，所以指定原型的名字為 prototype）；
• 不用 return 臨時(shí)對(duì)象，因?yàn)?new 會(huì)幫你做；
• 不要給原型想名字了，因?yàn)?new 指定名字為 prototype。

做了什么

http://warjiang.github.io/devcat/2016/05/12/JS%E4%B8%ADnew%E5%88%B0%E5%BA%95%E5%8F%91%E7%94%9F%E4%BA%86%E4%BB%80%E4%B9%88/?utm_source=tuicool&utm_medium=referral

• var o = new Object();
• o. __proto__ = A.prototype;//這里還記得之那個(gè)function里面的默認(rèn)的屬性么?
• A.call(o)//由于這里this是指向o,可以把什么this.name/getName綁定到o上.
• 把這個(gè)o返回給a;//完成var a = new A()的過(guò)程.

2017前端性能優(yōu)化清單?

https://www.w3ctech.com/topic/1945

一個(gè)項(xiàng)目的性能是非常重要的，除了要在技術(shù)層面上注意，更要在項(xiàng)目的設(shè)計(jì)之初就開始考慮，這樣才可以使性能的各種隱形需求完美的整合到項(xiàng)目中，隨著項(xiàng)目一起推進(jìn)。性能最好具有可量化、可監(jiān)測(cè)以及可改動(dòng)的特性。網(wǎng)絡(luò)越來(lái)越復(fù)雜，對(duì)網(wǎng)絡(luò)的監(jiān)控也變得越來(lái)越難，因?yàn)楸O(jiān)測(cè)的過(guò)程會(huì)受到包括設(shè)備、瀏覽器、協(xié)議、網(wǎng)絡(luò)類型以及其他技術(shù)（CDN，ISP，緩存，代理服務(wù)器，防火墻，負(fù)載均衡器和服務(wù)器對(duì)性能的影響都很大）的很大影響。?

JavaScript嚴(yán)格模式?

ECMAScript 5的嚴(yán)格模式是JavaScript中的一種限制性更強(qiáng)的變種方式。嚴(yán)格模式不是一個(gè)子集：它在語(yǔ)義上與正常代碼有著明顯的差異。不支持嚴(yán)格模式的瀏覽器與支持嚴(yán)格模式的瀏覽器行為上也不一樣， 所以不要在未經(jīng)嚴(yán)格模式特性測(cè)試情況下使用嚴(yán)格模式。嚴(yán)格模式可以與非嚴(yán)格模式共存，所以腳本可以逐漸的選擇性加入嚴(yán)格模式。

嚴(yán)格模式在語(yǔ)義上與正常的JavaScript有一些不同。 首先，嚴(yán)格模式會(huì)將JavaScript陷阱直接變成明顯的錯(cuò)誤。其次，嚴(yán)格模式修正了一些引擎難以優(yōu)化的錯(cuò)誤：同樣的代碼有些時(shí)候嚴(yán)格模式會(huì)比非嚴(yán)格模式下更快。 第三，嚴(yán)格模式禁用了一些有可能在未來(lái)版本中定義的語(yǔ)法。
如果你想讓你的JavaScript代碼在嚴(yán)格模式下運(yùn)行，可以參考轉(zhuǎn)換成嚴(yán)格模式。
有時(shí)，你會(huì)看到符合規(guī)范的、非嚴(yán)格模式被稱為"懶散模式"，這不是官方術(shù)語(yǔ)，但你應(yīng)該注意到它.

JavaScript常用代碼總結(jié)

分享了一些常用JavaScript代碼，有：1.手機(jī)類型判斷、2.字符串長(zhǎng)度、3.獲取url中的參數(shù)、4.js 綁定事件、5.當(dāng)前瀏覽器JS的版本、6.全選/全不選、7.移除事件、8.回車提交、9.ajax提交等。

localStorage，您坑了嗎？

客戶端localStorage被寫滿時(shí)，導(dǎo)致功能無(wú)法正常使用，只能自己挖的坑自己填了。在填坑之前，我們先考慮了使用緩存需要注意的問(wèn)題：

• 緩存只是為了提升性能，不能認(rèn)為緩存一定可用，數(shù)據(jù)獲取失敗或?qū)懭胧《紤?yīng)該有后續(xù)的代替處理
• 有可能會(huì)存在部分緩存數(shù)據(jù)寫入之后，長(zhǎng)期都未使用過(guò)或者代碼中已不再會(huì)使用該緩存（已失去效用的數(shù)據(jù)占用了空間）
• 緩存的使用都是開發(fā)直觀上的認(rèn)為有需要，但是寫入之后，后續(xù)是否真正有使用到（可能該功能用戶只使用一次之后就不再使用），是否也是非必要占用了緩存的空間
• 數(shù)據(jù)緩存保存在客戶端，需要有一定的機(jī)制來(lái)控制緩存的增長(zhǎng)或者做緩存的清除

從__proto__和prototype來(lái)深入理解JS對(duì)象和原型鏈

Object本身是構(gòu)造函數(shù)，繼承了Function.prototype;Function也是對(duì)象，繼承了Object.prototype。

Object instanceof Function // true Function instanceof Object // true

那么具體到JS，ES規(guī)范是怎么說(shuō)的？Function本身就是函數(shù)，Function.__proto__是標(biāo)準(zhǔn)的內(nèi)置對(duì)象Function.prototype。Function.prototype.__proto__是標(biāo)準(zhǔn)的內(nèi)置對(duì)象Object.prototype。

最后總結(jié)：先有Object.prototype（原型鏈頂端），Function.prototype繼承Object.prototype而產(chǎn)生，最后，Function和Object和其它構(gòu)造函數(shù)繼承Function.prototype而產(chǎn)生。

該死的IEEE-754浮點(diǎn)數(shù)，說(shuō)「約」就「約」，你的底線呢？以JS的名義來(lái)好好查查你

?

77% 的網(wǎng)站使用了至少有 1 個(gè)漏洞的 JavaScript 庫(kù)

在 Alexa 上的 top 5000 網(wǎng)站上跑了測(cè)試，發(fā)現(xiàn)數(shù)字達(dá)到了驚人的 76.6%，76.6% 的網(wǎng)站使用了至少包含 1 個(gè)漏洞的庫(kù)。

需要說(shuō)明的是，沒(méi)有一個(gè)單一的解決方案可以解決這個(gè)問(wèn)題。相反，需要的是將提高安全意識(shí)、使用更好的工具、一套簡(jiǎn)單可維護(hù)的 JavaScript 前端實(shí)現(xiàn)方法等相結(jié)合（前端包管理工具的使用遠(yuǎn)不像后端那樣普遍）。而這也僅僅是個(gè)開始。

但是，正如我們前面所說(shuō)的，對(duì)此依舊滿懷信心。第三方 JavaScript 的安全問(wèn)題是一個(gè)可解決的問(wèn)題，只是比預(yù)想的需要更長(zhǎng)的時(shí)間而已。

Sticky Footer，完美的絕對(duì)底部

form me:

<!DOCTYPE html> <html lang="en"> <head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"><title>Document</title><style type="text/css">html,body{width: 100%;height: 100%;padding: 0;margin: 0;}.wrapper{width: 100%;min-height: 100%; /*必須使用min-height*/}.main{padding-bottom: 50px;}.footer{width: 100%;height: 50px;margin-top: -50px;background: #ccc;}</style> </head> <body><div class="wrapper"><div class="main">main</div></div><div class="footer">footer</div> </body> </html>

頁(yè)面的 HTML 結(jié)構(gòu):

<div class="wrapper"><div class="content"><!-- 頁(yè)面主體內(nèi)容區(qū)域 --></div><div class="footer"><!-- 需要做到 Sticky Footer 效果的頁(yè)腳 --></div> </div>

• 實(shí)現(xiàn)方案一：absolute，通過(guò)絕對(duì)定位處理應(yīng)該是常見(jiàn)的方案，只要使得頁(yè)腳一直定位在主容器預(yù)留占位位置。常用
• 實(shí)現(xiàn)方案二：calc，通過(guò)計(jì)算函數(shù) calc 計(jì)算（視窗高度 - 頁(yè)腳高度）賦予內(nèi)容區(qū)最小高度，不需要任何額外樣式處理，代碼量最少、最簡(jiǎn)單。兼容性
• 實(shí)現(xiàn)方案三：table，通過(guò) table 屬性使得頁(yè)面以表格的形態(tài)呈現(xiàn)。不建議使用
• 實(shí)現(xiàn)方案四：Flexbox，Flexbox 是非常適合實(shí)現(xiàn)這種效果的，使用 Flexbox 實(shí)現(xiàn)不僅不需要任何額外的元素，而且允許頁(yè)腳的高度是可變的。

JavaScript排序，不只是冒泡

https://segmentfault.com/a/1190000008796659

實(shí)例分析 JavaScript 詞法作用域

作用域是在運(yùn)行時(shí)代碼中的某些特定部分中變量，函數(shù)和對(duì)象的可訪問(wèn)性。換句話說(shuō)，作用域決定了代碼區(qū)塊中變量和其他資源的可見(jiàn)性。

作用域有兩種常見(jiàn)的模型：詞法作用域(在詞法分析階段就確定了，不會(huì)改變。變量的作用域是在定義時(shí)決定而不是執(zhí)行時(shí)決定)和動(dòng)態(tài)作用域(在運(yùn)行時(shí)根據(jù)程序的流程信息來(lái)動(dòng)態(tài)確定的)。

• 如果一個(gè)文檔流中包含多個(gè)script代碼段（用script標(biāo)簽分隔的js代碼或引入的js文件），它們的運(yùn)行順序是：
• JavaScript 解析過(guò)程：
• JavaScript 執(zhí)行過(guò)程：
• 實(shí)例分析：不同作用域中的同名變量；參數(shù)和同名變量

用Async函數(shù)簡(jiǎn)化異步代碼

隨著 ES6 的到來(lái)(現(xiàn)在被稱作 ES2015)，除了引入 Promise 的規(guī)范，不需要請(qǐng)求那些數(shù)不盡的庫(kù)之外，我們還有了生成器。生成器可在函數(shù)內(nèi)部停止執(zhí)行，這意味著可把它們封裝在一個(gè)多用途的函數(shù)中，我們可在代碼移動(dòng)到下一行之前等待異步操作完成。突然你的異步代碼可能就開始看起來(lái)同步了。

這只是第一步。異步函數(shù)因今年加入 ES2017，已進(jìn)行標(biāo)準(zhǔn)化，本地支持也進(jìn)一步優(yōu)化。異步函數(shù)的理念是使用生成器進(jìn)行異步編程，并給出他們自己的語(yǔ)義和語(yǔ)法。因此，你無(wú)須使用庫(kù)來(lái)獲取封裝的實(shí)用函數(shù)，因?yàn)檫@些都會(huì)在后臺(tái)處理。

async/await與Promises ：

• 鏈?zhǔn)讲僮?#xff1a; async 函數(shù)在這個(gè)方面甚至比 Promise 做得還好。使用 async 函數(shù)，只需要像編寫同步代碼那樣調(diào)用 asynchronousOperation
• 并發(fā)操作：Promise 還有另一個(gè)偉大的特性，它們可以同時(shí)進(jìn)行多個(gè)異步操作，等他們?nèi)客瓿芍笤倮^續(xù)進(jìn)行其它事件。ES2015 規(guī)范中提供了 Promise.all()，Promise.all() 也可以當(dāng)作 async 函數(shù)使用。
• 處理拒絕：使用Promise，傳遞給 then，作為其第二個(gè)參數(shù)，或者傳遞給 catch 方法。不使用 Promise API 中的方法，可以通過(guò) try 和 catch 來(lái)處理。
• 中斷 Promise：拒絕原生的 Promise，只需要使用 Promise 構(gòu)建函數(shù)中的 reject 就好，當(dāng)然也可以直接拋出錯(cuò)誤。在 async 函數(shù)中隨時(shí)隨地拋出錯(cuò)誤，它總會(huì)被 Promise 抓住。

?

轉(zhuǎn)載于:https://www.cnblogs.com/Chen-XiaoJun/p/6576692.html

總結(jié)

以上是生活随笔為你收集整理的文章收藏(一)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。