FEDay 參會小記

clipboard.png
活動地址:http://fequan.com/2016/javascript

注意:英文很差,小記也帶有本身理解,部份內容可能包含嚴重的我的想法,不會按原話翻譯,隨機寫得也亂,建議等幾天找錄播或 PPT 獲得源文理解。前端

使用React、Redux和Node.js構建通用應用

做者網站是:http://www.stepanp.com/vue

先簡單說個同構(通用)應用的概念:前端服務器端功能雙向映射java

過去,rails 中 路由、校驗、視圖都在 rails 中完成,js 只是用於作一些動畫python

如今,用 backbone 來構建單頁不刷新頁面,javascript 負責了路由、校驗、視圖等功能,成爲了主角(目錄結構仿照 rails)react

介紹了 todomvc 看看同一種 todo 功能,用不一樣的類庫來實現會是怎麼寫的jquery

模板能夠在 rails 中寫,也能夠在 javascript 中寫,但很快就會失控,你如何判斷這個功能模板應該在哪端寫,相似功能的模板你怎麼複用?webpack

若是先後端都是 JS 的話,是否是就解決了這個問題?先後端共享路由、驗證、視圖邏輯git

那麼問題又來了,後端並無 DOM,怎麼用前端的寫法來呈現 DOM 結構?github

寫一個虛擬 DOM !先後端代碼共享,React 應運而生。

優勢:

  • 共享代碼(代碼習慣一致,咱們再也不須要在先後端切換語言)

  • 提高性能(計算邏輯放在後端執行,作到直出效果)

  • 利於 SEO(後端吐出靜態 HTML,必然帶來了 SEO 效果)

那麼,咱們用什麼技術棧來作這些事情呢?

  • React(視圖模板共享)

  • Webpack + babel + family(構建工具)

  • ReactRouter (路由)

  • Redux(存儲)

React 有了虛擬 DOM ,因此咱們能夠在服務器端很舒服地寫 DOM 組件邏輯
接下來介紹 react 基礎語法,幾段代碼示例,略。
須要注意的是,服務器端能夠寫虛擬 DOM 的邏輯,但事件綁定是須要到了瀏覽器端才能真正綁定的,能夠理解爲服務器端只爲咱們生成了模板,到了瀏覽器服端後不須要從新計算虛擬 DOM 的結構,用服務器端算好的 DOM 結構直接渲染,並直接添加事件綁定後便可。

構建工具用 webpack打包 + babel 轉換 ES6/7 天然是目前最好的選擇啦。

路由用 ReactRouter,聲明式路由
瀏覽器端使用 ReactRouter 的browser history 功能,服務器端則使用 match 功能(考慮瀏覽器端禁用 JS 後,頁面還可否渲染出來)。

存儲用 redux,一個請求到來建立一個組件的同時,建立一個 store(即時建立,方便銷燬避免內存泄露)

把舊數據緩存到 window.__DATA__,初始化時考慮使用緩存數據,感受這個作法比較傳統,初始化組件時在數據返回前先使用這份舊數據

拉取數據,單頁應用必然是使用 ajax 異步去拉數據,這裏講師推薦了 isomorphic-fetch 模塊來作 ajax 請求,講師說這是同構應用中拉取數據的關鍵,我沒明白什麼意思,回頭翻 PPT。。。

最後做者展望了下 JS 的將來,大一統不一樣的終端(iOS/Android等),但願能用 JS 來作不一樣端上視圖、驗證、路由等功能。呼籲咱們去作這種事情,但我以爲不大可能。。。

微信Web APP開發最佳實踐

介紹 JS-SDK,說的東西在微信開發文檔中都有寫,我就懶得打了,略。

手機機型統計圖,做者貼了張微信安卓客戶端機型前十的分佈圖,基本都是低端機,那叫一個慘,這個等 PPT 出來直接看吧。

介紹 X5,優勢的爲的是抹平不一樣 Android 版本不一樣 Webview 的坑,缺點是帶來本身的 X5 坑(有點多)。

這裏我體會比較深了,微信緩存清理比較蛋疼,客戶端作的強緩存,對於普通用戶來說節省流量,對於咱們開發來說就繁瑣了,微信設置中清緩存不必定有效。能夠考慮 URL 中加時間戳的辦法(記得 HTML 也要加,不然都不去拉 HTML 了)

黑科技://triggerWebViewCacheCleanup 來清緩存!

佈局方面,flex 只是部分支持,建議用 autoprefixer 等工具來補,只支持相似 -webkit-box 這種老寫法,只能怪 X5 用的 webkit 內核版本太老了。

動畫效果,僞元素不能使用動畫效果,這個我也深有體會,建議用實體標籤來模擬。

視頻播放,controlrs 是不能隱藏的(除非你有白名單),ontimeupdate 事件能夠觸發,但 currentTime 是不許確的,autoplay 是不能使用的,這個是 iOS 廣泛的問題,不經用戶交互是沒法自動播放媒體的,那監聽 WXJSBridgeReady 事件再播放就行了(用戶有交互)。

cookie 和 localStorage 失效的問題,聽到後我都驚呆了。。。緣由不明。這是不可靠的存儲,不要太過於依賴。建議是 cookie 和 localStorage 都存一份。

UIWebView 有個 bug: 手勢右滑和點返回按鈕關閉 Webview 是行爲不一致的,建議用 hash 來作歷史記錄管理。

介紹 WeUI, 微信風格的 UI,與客戶端體驗一致,這個本身去微信 github 上看 demo 吧,略。

WeUI 有 jquery/react/vue 版本,這點很贊。

微信調試一件套,網頁受權、JS-SDK 模擬、集成 Chrome DevTools、代理、weinre 遠程調試。這些在微信開發者中心有介紹,略。

X5 升級,改用了 Blink 內核,到如今 3 月 19 號未知,灰了大約 70%,計劃到月底全量。

X5-Blink 有哪些新特性呢?

  • Chrome inspect

  • 標準的緩存策略

  • 完整支持 flex

  • canvas 支持 CSS 設置背景色了

  • filter: blur 模糊能夠用了

  • 優化了動畫卡頓問題

  • 僞元素支持動畫了

  • 尼瑪,PPT 太快,我剛肚子餓了還幾點沒記錄到,別打我

升級後,不少坑自動沒了,但我以爲確定也會帶來更多坑。XXX 年微信開發經驗的人,終於又成爲了零年開發經驗的人,從新走上了踩坑之路。

React tips

Container Component

父子組件之間的數據傳遞、渲染、錯誤捕獲,接入外部的 Store

先來看看 UI Component 須要什麼

  • 有數據/狀態(data/state)

  • UI 邏輯

  • 可重用

  • 須要測試

React 組件在 ComponentDidMount 時發起 ajax 數據,設置 setState 後,更新組件數據,從新渲染。

錯誤捕獲的作法是,將 error 傳進 state 中 this.setState({error: null}); 判斷有 error 顯示 Error 組件
處理 loading 的作法也是,將 loading 傳進去 this.setState({isLoaded: false}); 判斷有 isLoaded 顯示菊花

對於 UI Component 來講,它不在須要關心數據哪裏來的,只關心將 Container Component 傳遞下來的數據,進行渲染(無狀態)。

我對講師將的 Container Component 的理解是:Container Component 專門負責管理數據,而後將數據傳遞給子組件,也就是 UI Component(單向數據流)

多個組件須要複用統一份數據,因此咱們須要有一個地方來存儲通用數據,這就是 Store.

經過拿到一個 action ,改變了一個 store, 再將數據傳遞回去,這是一個簡單的函數行爲,而 flux 的實現就過於冗餘,因此有了 redux。

Flux ReduceStore

其實就是監聽到一個 action 將傳過來的 state 進行合併,而後把新的 state 傳遞回去。

Functional *

強調無狀態的組件(stateless component),一個組件就是一個函數,接受輸入,將渲染結果輸出。
若是一個父組件裏面要產生不少子組件,那你就該將這個組件抽離出來,變成一個函數,給父組件使用。
這裏講師拿 underscore 的 _render 作反例,問題在於 render 嵌套太深,很差調試。
而無狀態組件,只關注輸入,保證輸出。

因此建議是,組件嵌套不要太深,保證同時只有一個組件,接收一個輸入,具備一份輸出。(好繞)

這裏講的比較抽象,須要看了 PPT demo 代碼纔好理解,略(別打我)。

Decorator/HOC 高內聚組件

使用裝飾器,不改變原有組件的前提下,加一下修飾包裝後,返回一個新的組件(被賦予了額外的組件或行爲)
好處就是,UI 層能夠專心作渲染的事情,經過添加額外的裝飾器,來產生不一樣功能的定製化組件,那麼這個 UI 層組件,就作到了可重用。

map/filter/reduce

不少數組操做用 forEach 均可以完成,下面三個也都是數組具有的的方法,只是一些小技巧而已。
用 map 替代 forEach, 簡化數據
用 filter 替代 forEach, 篩選數據
用 reduce 快速產生一個新對象

todos.reduce((todos, todo) => {
     todos[todo.id] = todo;
     return todos;
}, {})

這幾點技巧,加上 ES6 的箭頭函數來用,不少時候一行代碼就能處理完,能讓咱們的代碼更加簡潔、可讀。

講師最後推薦了一個連接給你們看看:GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft's Reactive Extensions Library for Javascript.GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft's Reactive Extensions Library for Javascript.

這個講題給我最大的體會就是,去深刻思考如何真正得作可重用的組件化,同時讓這份代碼更加可讀。

下一代Web技術運用

這個主題沒聽全,期待其餘同窗補充,略。

一個前端的自我修養

開場拿出 react/angular/week 調侃:你不會敢說你會前端?
前端在於難學,而是你們不知道怎麼學。如何成爲像 hax 同樣的前端?

20% 知識:JS、DOM、Device API、CSS、DOM、HTML、HTTP、jQuery、React ...
80% 能力:編程能力、架構能力、工程能力

編程能力:解決問題的能力(基礎)
架構能力:必定規模後帶來架構問題
工程問題:關於人的問題,怎麼讓一個團隊裏的人怎麼協做好

怎麼提高知識與能力?

知識的學習

你寫代碼的初心是什麼,你指望把程序寫過來的感受是什麼?

創建並弄清楚本身的知識體系。

爲了區分好 id 和 name 的區別,winter 借了十本書去查閱這個問題。

舉例怎麼創建本身的知識體系。

  • 尋找線索

    • 好比學 JS, 控制檯輸入 for (var k in window) 看看有哪些屬性,你瞭解這些東西麼,查閱書籍能找到麼?

    • 好比學 python,你瞭解全局有哪些東西麼?

    • 看附錄

    • 查源碼

    • 反射

  • 創建聯繫

    • childNodes/parentNode nextSibling/previousSibling 等有哪些關聯,你理解麼?顧名思義,觸類旁通,串起來學習。

    • 美感

    • 完備性(好比 jQuery 有 append 就有 prepend)

    • 操做同組數據(setTimeout/setInterval/clearTimeout/clearInterval)

  • 歸類

    • 畫思惟導圖,例如你知道 zepto 有哪些 API 能夠用麼,能分類整理完整爲一棵樹麼?

      • ajax

      • collection

      • dom

      • util

    • 見到前端爭議的時候,你如何追本溯源找到知識?好比你知道閉包的解釋,誰說的對麼?

      • 查 wiki 看歷史,誰定義了閉包這個概念:P J Landin

      • 查 Google 論文, P J 在一個期刊上發了篇文章,看看原文怎麼定義閉包的

      • 閉包兩部分:

        • 環境部分 environment

        • 控制(表達式)部分 control part

      • 經過辯證地最本溯源獲得正確的判斷,不斷得到自信和社區聲譽,這對於新人來講很是重要(擺脫新手 拍死前浪)

    • 追本溯源

      • 論文

      • 郵件列表

      • 代碼提交記錄(commits/issues)

  • 挑戰

    • 推翻舊知識,創建新知識,這是一個循環的過程,不斷完善知識體系

能力的培養

能力培養沒有捷徑,但有投入的技巧。

推薦一本教材:《C++程序設計語言》(爲何是教材不叫書?由於沒有習題)

推薦一本書:《黑客與畫家》

習題很重要。習題很重要。習題很重要。

靠天然的提高不太可能,須要刻意的大量的訓練。

  • 主動性

    • 被動的 996 不會有成長

    • 天天主動再加幾個小時學習纔會有幫助

  • 習慣養成

    • 保持在學習區、痛苦區工做(擺脫溫馨區)

  • 系統訓練

    • 一萬個小時理論太難,那從二十個小時開始呢?

HTTP/2時代的Web性能

做者是 @foobartel (新浪微博和推特) http://foobartel.com/

開場白:Nobody likes to wait.(含義:咱們等待了 HTTP/2 太多年。)

開一個網站只須要 2-3 秒,用戶就會以爲快。超過 4 秒沒打開,50% 的用戶就會選擇離開,超過 8-10 秒,用戶就會離開。

因此在 2-3 秒內打開頁面,用戶基本就不會抱怨。

不要覺得不少用戶都在用 wifi 打開網頁速度很快,咱們要考慮 3G/GPRS 甚至是離線的用戶網絡,因此更快纔是更好。

現有的性能優化技巧:文件合併、精靈圖片、內聯圖片、域名共享

有哪些地方能夠優化?

渲染樹的過程,DOM 佈局與繪製(重繪):

  1. 等待 DOM 和 CSSDOM 構建渲染樹

  2. 渲染樹節點

  3. 計算佈局、定位和尺寸

  4. 繪製

渲染 CSS/JS/HTML,避免或減小各類阻塞問題

每一個請求都帶有開銷,請求順序優化。

最佳渲染路徑:讓內容更快的出如今頁面上(減小白屏時間)

迎接 HTTP/2

HTTP/0.9
HTTP/1.0 1996
HTTP/1.1 1999

帶寬的線性提升並無帶來頁面加載速度的線性提升,這是協議帶來的問題(鏈接數有限,RTT 請求時間固定開銷)

RTT 相比帶寬,對性能的影響更大。

SPDY/HTTP/2

  1. 都支持多路複用

  2. 都支持頭部壓縮

  3. 都支持服務器端推送

  4. HTTP2 支持優先級請求

  5. HTTP2 向後兼容 HTTP/1.1

HTTP/1.1 中不少的優化技巧已經成爲反模式。

HTTP/1.1 中咱們爲了減小體積和請求數,會作不少的合併。
HTTP/2 中同一個域名只會使用同一個 TCP 鏈接多路複用(不須要資源合併、資源內嵌)

  1. 不須要 CDN combo 合併了

  2. 不須要 JS/CSS 內嵌了

  3. 不須要使用雪碧圖了

  4. HTTP/1.1 下不少優化技巧咱們均可以拋棄,由於請求已經很廉價

HTTP/1.1 中咱們爲了打破瀏覽器併發請求次數的顯示,將多個資源分佈在不一樣的域名下。
HTTP/2 中,請求廉價,同域複用鏈接(理論上是無限的),因此咱們要作域名收歸。減小 DNS 解析反而成爲了正確)

HTTP/2 中減小資源請求,域名分發再也不必要,但HTTP/1.1 其餘已有的優化技巧,仍是須要繼續使用,如 DNS 查找、減小重定向、使用 CDN、重用 CDN、開啓壓縮、開啓緩存等。所幸的是,HTTP/2 是向後兼容的。

如何開啓 HTTP/2

  1. 開啓 SSL/TLS

  2. 服務器開啓 支持,如 apache 的 mod_http2 模塊

  3. 檢查客戶端支持,caniuse.com 查兼容程度

相關文章
相關標籤/搜索