參加FEDAY 2016是一種怎樣的感受？

01-06

其他的不做評價。

個人尤其覺得來自facebook的黃士旗講的React tips很有啟發，邏輯清晰，一步一步深入，感覺自己React的姿勢得到了顯著提高。

根據現場記錄自己總結一下：

SectionA：Container Component

首先講什麼是Container Component：FooContainer裡面有一個Foo，container包含Foo所需有的所有資料， Foo有什麼動作全部丟給container，由container做處理。
然後引出問題：為什麼要使用Container Component，把Foo的事情直接交給Foo自己做不好嗎？因為FooContainer：

管理數據/狀態
沒有UI邏輯
不可復用
需要大量測試

接下來拿一個經典的TodoApp來舉栗子：Container拿到服務端返回的todolist時，需要做waiting / timeout / retry / filter by * 等處理。而一個Todo裡面只負責渲染，做一個dumb組件。
接下來引出Container Component的缺點：當組件之間要復用資料，要進行交流時就很麻煩。
PS：以前我就是一直Foo的邏輯全塞在Foo里（那可真蠢_(:з」∠)_

SectionB：Flux Store Reduce Store

鑒於Container Component的這些缺點，於是出現了Flux Store，它：

優：單向數據流管理做得非常好。
缺：做了很多沒有必要的操作（冗餘代碼）。

為了解決Flux Store的缺點，又有了Reduce Store，它：

與Flux不同之處：傳todos過來進行操作，然後再返回回去。
函數式style。
便於使用flux的人進行遷移。

SectionC: Functional * （這一節講了一些Tips）

避免在Component內部的_renderXXX方法（我又干過這種事_(:з」∠)_還不止一次hhhh）：這樣在裡面能訪問到this，會帶來很多debug上的困擾。建議使用這種：
function renderTodo(props) { return &{props.title}& }
純函數式的方法，通過傳入相應的props來做這個事情，與上下文隔絕開。

Decorator/HOC：例如現在你已經寫好了基本的Todo，這時有需求來了【要一個完成的checkbox和一個delete按鈕】。這個時候如果直接把這些功能直接寫在Todo這個Componenet里，會帶來耦合低可復用性。比較好的做法是：使用Decorator的思想，包裝出一個&和一個&組件，會帶來較好的復用性（這個思想很棒有木有）。

map/filter/reduce：這裡與react其實無關，講的是js里array一些方法的正確姿勢。他還推薦了一個讓他受益良多的東西，地址見這裡GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft"s Reactive Extensions Library for Javascript.
PS：突然覺得學習FP會打開新世界的大門，炒雞有興趣.(?°?°?)！

作者在線下交流還說：我以前很喜歡MVC，用得很順，為什麼要用Flux這一套呢？後來我來到fb用多了就明白了，它可以提高回溯問題的效率，而不會有一處改變多處出問題的尷尬。

還沒有對照PPT復盤，完全是照著筆記寫的，如果不對歡迎指正(?????)

PPS：整場FEDAY不停的在提React。

PPPS：當問到fb某位工程師如何看待angular2的，他如是說：我是facebook的工程師，我們用很多react，但是我認識一些google的工程師，他們不用angular2 ( ?° ?? ?°)。全場爆笑hhhhhhhh

最大的感受就兩點

1. 別讓說母語英文的人強行說中文。。。

2. 別設置翻譯節奏打斷得太惡劣了。

Holger說的東西挺清晰的，根本不需要翻譯啊。

最多就大會讓外國嘉賓把ppt寫詳細一點，這樣就完全可以了。

參加深js的時候，也是沒有翻譯的，大家都交流得挺好的啊。不是說一定要全程聽懂，但是打斷節奏和浪費時間明顯是更加惡劣的。

再退一萬步說。。。一點點都聽不懂的那一群，也就兩場聽不懂，但ppt總能懂吧。倒逼著他們多學點英文也很好啊，下一次就能聽懂了。

注意：英文不好，小記也帶有自己理解，部分內容可能包含嚴重的個人想法，不會按原話翻譯，隨機寫得也亂，建議等幾天找錄播或 PPT 得到源文理解。

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

作者網站是：http://www.stepanp.com/

先簡單說個同構（通用）應用的概念：前端伺服器端功能雙向映射

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

現在，用 backbone 來構建單頁不刷新頁面，javascript 負責了路由、校驗、視圖等功能，成為了主角（目錄結構仿照 rails）

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

模板可以在 rails 中寫，也可以在 javascript 中寫，但很快就會失控，你如何判斷這個功能模板應該在哪端寫，類似功能的模板你怎麼復用？

如果前後端都是 JS 的話，是不是就解決了這個問題？前後端共享路由、驗證、視圖邏輯

那麼問題又來了，後端並沒有 DOM，怎麼用前端的寫法來呈現 DOM 結構？

寫一個虛擬 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 有哪些新特性呢？

1.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 的箭頭函數來用，很多時候一行代碼就能處理完，能讓我們的代碼更加簡潔、可讀。

講師最後推薦了一個鏈接給大家看看：https://github.com/ReactiveX/learnrx

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

# 下一代Web技術運用

這個主題沒聽全，期待其他同學補充，略。

# 一個前端的自我修養

開場拿出 react/angular/week 調侃：你不會敢說你會前端？

前端在於難學，而是大家不知道怎麼學。如何成為像 hax 一樣的前端？

20% 知識：JS、DOM、Device API、CSS、DOM、HTML、HTTP、jQuery、React ...

80% 能力：編程能力、架構能力、工程能力

編程能力：解決問題的能力（基礎）

架構能力：一定規模後帶來架構問題

工程問題：關於人的問題，怎麼讓一個團隊里的人怎麼協作好

怎麼提升知識與能力？

## 知識的學習

你寫代碼的初心是什麼，你期望把程序寫過來的感覺是什麼？

建立並弄清楚自己的知識體系。

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

舉例怎麼建立自己的知識體系。

尋找線索
1. 比如學 JS, 控制台輸入 for (var k in window) 看看有哪些屬性，你了解這些東西么，查閱書籍能找到么？
2. 比如學 python，你了解全局有哪些東西么？
3. 看附錄
4. 查源碼
5. 反射
建立聯繫
1. childNodes/parentNode nextSibling/previousSibling 等有哪些關聯，你理解么？顧名思義，舉一反三，串起來學習。
2. 美感
3. 完備性（比如 jQuery 有 append 就有 prepend）
4. 操作同組數據（setTimeout/setInterval/clearTimeout/clearInterval）
歸類
1. 畫思維導圖，例如你知道 zepto 有哪些 API 可以用么，能分類整理完整為一棵樹么？
  1. ajax
  2. collection
  3. dom
  4. util
2. 見到前端爭議的時候，你如何追本溯源找到知識？比如你知道閉包的解釋，誰說的對么？
  1. 查 wiki 看歷史，誰定義了閉包這個概念：P J Landin
  2. 查 Google 論文, P J 在一個期刊上發了篇文章，看看原文怎麼定義閉包的
  3. 閉包兩部分：
    1. 環境部分 environment
    2. 控制（表達式）部分 control part
  4. 通過辯證地最本溯源得到正確的判斷，不斷獲得自信和社區聲譽，這對於新人來說非常重要（擺脫新手拍死前浪）
3. 追本溯源
  1. 論文
  2. 郵件列表
  3. 代碼提交記錄（commits/issues）
挑戰
1. 推翻舊知識，建立新知識，這是一個循環的過程，不斷完善知識體系

## 能力的培養

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

推薦一本教材：《C++程序設計語言》（為什麼是教材不叫書？因為沒有習題）

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

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

靠自然的提升不太可能，需要刻意的大量的訓練。

主動性
1. 被動的 996 不會有成長
2. 每天主動再加幾個小時學習才會有幫助
習慣養成
1. 保持在學習區、痛苦區工作（擺脫舒適區）
系統訓練
1. 一萬個小時理論太難，那從二十個小時開始呢？

# HTTP/2時代的Web性能

作者是 @foobartel (新浪微博和推特) Home | foobartel Ltd.

開場白：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. 檢查客戶端支持，http://caniuse.com 查兼容程度

隔壁有個類似的話題：參加第二屆前端開發者年度大會是個什麼樣的體驗？ - 前端開發

慣例謝邀哈.

大會演講內容方面有回答已經非常詳盡,我就不寫了.

React方面的2個主題,同構之前有了解過一些,但是我個人不太感興趣.

React tips演講不錯,雖然裡面的東西我個人都實踐過了.

其它主題也很精彩,不過我個人研究的都不多.為什麼呢?

套用 @winter 的話,也是FEDAY 2016我個人的最大收穫:

好前端才分對錯
成年人只分利弊

看來我已經是成年人啦.

另外電影院看代碼效果杠杠的,倒數第三排哦.

又有新衣服穿了

聽說 @winter 在本次大會後成功脫單了

前戲

2016/3/21 補上參會的完整記錄，這個問題從一開始我就是準備「自問自答」的，希望可以通過這種形式把大會的乾貨分享給更多人。

0x00 出發/到達

我跟同事周周是周六凌晨1點才到的廣州，住的地方在小區裡面，路過樓下的時候看到一家還在營業的啤酒吧，很有Feel，但是此時的精神狀態直接把我們送到了房間里，洗完澡之後就碎覺了，準備次日集中精神好好聽講。

0x01 初到會場

次日，我們穿個馬路就來到了本次feday大會的現場。然後是標準的簽到，拿「大禮包「，參會證等流程，經常參加大會的同學應該很熟悉了，由於我之前參加過d2，覺得阿里報告廳的屏幕已經很震撼了，沒想到，第一次在電影院參加技術大會真的有種趕老羅發布會的感覺：

此次的嘉賓陣容：

好了，進入正題，以下內容既是記錄，又是自己的看法和總結，然後形式均為我認為的精華內容整理，完整的內容我覺得沒必要贅述，因為大會官網會放出完整的視頻。

0x02 Stepan From Facebook - 用Node.js+React.js打造通用應用

來參加feday前看到本次大會的主題，當我看到同構話題的時候比較興奮，因為之前負責的我廠一個全站消息中心改造項目，我和搭檔有實踐同構並為之落地，而且該項目已經上線，所以還是比較清楚同構的作用以及使用場景，而且在廠內也做了相關分享，所以想看看大會上能不能碰撞出一點不一樣的火花：

Stepan的演講精華我覺得可以精簡整理為如下幾點：

原來用RoR(其實這裡泛指後端)做的事情現在都可以用Javascript做，好處是可以前後端復用代碼，符合同構的基本條件，然後他通過一個目錄結構對比演示指出了同構應用中需要解決的三個事情：渲染/路由/數據（我是這麼理解的，因為我認為這確實是同構落地的關鍵）

對於渲染，他先列舉了一個非常簡單的例子，我認為他要表達的意思是：渲染的本質其實就是模版+數據，例如: function template(data){ return "&${data}&"; }，這個函數可以在server端直接將數據扔給res.send，也可以用在client端用來生成真實的dom；但我們的應用往往是複雜的，React(Facebook的工程師肯定是要來安利React的)的renderToString方法可以幫助我們完成Server-Side Rendering，因為React的vdom不需要依賴瀏覽器側的環境，這是React支持服務端渲染的唯一一個方法，好多同學已經知道了，講到這裡，作為一名Facebook工程師，他成功地為本次大會率先安利了一把React

對於路由，他基本上直接安利了React-Router，然後貼出了跟React-Router官方文檔幾乎一樣的代碼，所以，折騰過的同學基本可以略過這個環節，但其實很多同學應該知道，路由共享是同構的重要部分，其實這裡的坑還是蠻多的，其中還包括React-Router自身的bug，我在項目里的做法是將這塊邏輯以中間件的形式進行處理。

對於數據，不管你有沒有用flux，都要解決初始化數據的問題，因為兩端共用一份render邏輯，在後端直出的時候，需要將後端得到的數據同步給前端，否則，前端二次render，會得到不正確的渲染輸出，這個相信玩過React後端直出的應該也知道，解決方案幾乎都是一致的，說到底就是通過window.__STORE__ = {}，將數據帶給前端。你會發現其他封裝好的第三方同構庫ISO等最終用的都是這個邏輯：

window.__STORE__ = {}

關於組件拉取數據，他安利了isomorphic-fetch，這樣前後端可以共享一份拉取數據的邏輯，對於組件數據在server端的初始化，他的處理方式是，server.js：

async function fetchAllData(props) { return Promise.all( props .components .filter(x =&> x.fetchData) // 探測組件是否有fetchData方法 .(x =&> x.fetchData(props)) ); }
，這裡的props可以傳入React-Router中match方法返回的上下文，由於我們的業務只直出了部分組件數據，所以這裡的做法有所不同，我的做法是將ISO邏輯置入中間件，當中間件匹配到路由後，將利用yield next轉交給下一個中間件先拉取數據，然後將數據放入locals中，等到執行到ISO中間件時，中間件將locals中的數據拿出，初始化給React-Router匹配到的組件上下文，最後renderToString

React＋Node.js打造通用應用的折騰過程中其實只要解決這關鍵的三點，差不多就可以打造出一個同構應用了，但是他還沒有提到的還有：

因為前後端共用一份代碼，如果client.js中包含require("fastclick")之類的只在瀏覽器才會依賴的組件引入代碼時，我們需要做好環境判斷，當然，這非常簡單，但是不得不考慮
如果前端項目中的jsx用的是es6 modules，但是server端用的是require，則需要考慮統一
同構項目的工程化問題
......

最後，我在星巴克逛Stepan博客的時候發現他的博客就是同構的，很有趣，大家可以體驗一下：

Stepan"s Blog http://www.stepanp.com/

0x02 江劍峰微信開發過程中的最佳實踐

劍鋒幽默風趣的講演風格顯然非常接地氣，這個話題從一開始就吸引住了全場的開發者，因為有太多開發者曾經被微信坑過，這個分享我直奔乾貨總結了：

JS-SDK簽名過程中提交的URL參數中不得帶"#"及後面部分的內容，會導致簽名報錯
非同步獲取簽名的時候，要設置正確的Content-Type
清緩存黑科技：//triggerWebViewCacheCleanup
flex部分支持
微信真的沒有動過你的localStorage/Cookie，可能原因是進程被殺等

等等，快後退，我要裝逼了：

到3月份底，微信x5將全面升級為blink內核，並全網灰度發放完畢，也就說，我們即將可以大膽寫flex了，並再也不擔心緩存問題了，動畫卡頓問題也會得到改善，大家趕緊驗證去吧。

0x03 黃士旗－ React Tips

士旗也是來自Facebook的工程師，講的也是React，總結下來就是：士旗在教大家如何正確使用React：

容器組件的存在是為了讓它可以專註於數據處理，然後讓渲染組件專心負責渲染，只需要管扔進來的是什麼數據然後渲染就可以了，這樣處理後，我們會發現component的代碼將變得非常複雜，當我們要管理的state太多之後，所以就有了flux store，但是flux的實現中有不必要的實現，對於應用來說，一個action，一個state就可以返回一個新的state，這完全就是pure function就可以搞定的事情，於是有了redux store

將組件拆分，用更好的pure function來返回你需要渲染的這些組件，這樣可以利用decorator/HOC來達到組件復用，還可以減少組件中大量的_XXX私有方法，讓應用程序變得更加可控，debug變得更容易，其實這塊還是能夠產生很多共鳴的，相信各廠都在實踐一些營銷頁面快速產出的技術方案，React應該是比較合適的技術選型，可以利用decorator達到組件的高度復用

善用FP，RxJS。士旗在這裡安利了一把learnRX項目（GitHub - ReactiveX/learnrx: A series of interactive exercises for learning Microsoft"s Reactive Extensions Library for Javascript.），FP跟RxJS本質上是兩個東西，只是RxJS中有用到FP的思想，編程思維的轉變我認為是需要訓練和下功夫的，因為習慣思維非常可怕，我有看過RxJS，這種「一切皆Stream」的咒語一開始令人非常困惑，但豁然開朗後簡直彷彿像是看到另外一個世界，這方面，士旗主要強調，我們要善用Array的map/reduce/filter，FP可以讓代碼變的簡潔，FP的「語義化「方法名可以幫助提升代碼可讀性。

0x04 陳子舜－下一代web技術可以運用的點

子舜的話題中講到了很多務實的，騰訊正在實踐的一些技術：

包括離線化，包括對前端性能的不斷優化
之前在阿里d2聽過騰訊工程師分享過Node.js加速Qzone的一些細節，離線化這塊有領略過騰訊對於追求產品極致用戶體驗的那種態度，我廠也正在慢慢實踐，並且落地了一些初步工作，我們意識到無線端的離線化意義重大。
然後他講了ServiceWorker，http2，這裡可以到時候看大會放出的視頻
子舜這裡還提到了運營商劫持的問題，然後安利了HTTPDNS

中間有一次圓桌，HAX主持，主要是一些撕逼，沒有啥實質內容，而且我對於有同學問出：［你們怎麼看待RN的出現擾亂了原生開發和web開發之間的那種和諧］這種問題感到納悶。

0x05 winter - 如何成為更好的前端

第一次見到winter大神本尊，我佩服和尊敬這樣的前輩，但是我會保持風度和拒絕浮躁，winter的分享雖然不是技術內容分享，但他分享了他在學習前端過程中的一些他認為的好方法，我覺得現場好多前端工程師應該是可以跟他產生共鳴的：

比如，我們都干過console.dir(window)這種事情吧，然後看到陌生的api，趕緊去學習一下，給自己充充電
追求真理的態度，建立自己的知識體系，用權威推翻自己認為的甚至是社區認為的那些權威，比如他提到閉包，通過Google學術找到出處論文（追本溯源），然後推翻自己之前的那些認知
他認為要成為專業的前端工程師，20%靠的是知識，另外80%靠的是編碼能力，工程能力，架構能力，後者可能需要的就是工作經驗，然後不斷練習，然後winter感慨，他自己成長最快的那幾年都是在學校里，到了工作之後就很少有這樣的機會快速成長，即使工作多年，但是發現自己的進步緩慢

0x06 Holger Bartel - http/2時代的web性能

因為之前讀過幾篇關於http/2的博文，對http/2還是有所了解的，這個話題我沒有聽完，後來有事情就先走了，聽了前面3/4場，這部分大家可以閱讀相關博客彌補，我可以安利幾篇：

HTTP2.0的奇妙日常

前端開發與 HTTP/2 的羈絆——安利篇

0x07 結束篇

說個題外話，QCON貌似也臨近了，據我了解，今年qcon對前端話題的範圍基本也是限制在下一代web技術，再回過頭來看本次的FEDAY，我覺得從嘉賓到議題還是符合時代氣息的。希望下次越辦越好，很開心的是在回來的前一天晚上，在樓下的那個啤酒吧里遇到了stepan，holger，士旗，裕波等人，跟stepan和holger面對面交流了相關主題，真可謂不虛此行，滿足之餘，在知乎上，博客上同步以上所有內容給大家，謝謝。

會議大綱就不整理了，說說我的個人體驗吧。

1. 必須吐槽翻譯問題，翻譯直接導致兩個英文講師的分享被打成一段一段，很不流暢。我相信講師心裡也這麼想。

2. React 兩個主題講的清晰，但是也是互聯網上能獲取到的信息，分享的乾貨其實不多。

3. 舜子的性能優化主題全是乾貨，而且綜合效果很好，賣力頂，大家可以多關注。

4. 性能和 HTTP2 的話題有一部分是重合的。

5. 圓桌回憶的幾個話題撕逼居多，個人覺得價值不大。

6. 首次影院舉辦，不多不說現場效果還是很棒的，沒見過那麼大的代碼！不過由於舉辦方經驗問題，中間出了好多小意外浪費時間，估計是沒有綵排過的。

7. 總體來說，值回票價，但是沒有達到預期，下回還是會支持的，希望越辦越好！

@winter 一如想像中的萌～

又可以多擼幾份代碼來驗證了～

以下內容，全靠記憶。

0x00

今天過來幾乎是為了支持林毅和波波的，比較作為廣州地頭蛇，怎麼也得買票支持下。剩下的就是某群群友面基八卦求紅包。

0x01 React

今天有兩個來自 Facebook 的講師來分享他們關於 React 的經驗，一個是來自 Facebook 廣告部門的 Shihchi Huang（黃士旗，台灣人），另一個是來自 Facebook Messenger 的 Stepan。

此處並沒有按照出場順序排序

Shihchi 的 Speak 的主題是 React Tips，主要內容是 Facebook 內部在 React 的實際應用上的實踐經驗分享：依然是有著 Model-View 味道的視圖與數據的隔離模式，在 React 中他們稱之為 Container Component 和 UI Component，一個用於 handle data/events（need tests），一個用於 render UI（not need tests）。Shihchi 現場說了一句話我印象比較深刻，大意是：想像一下，我們可以直接拿別人寫好的 Container Component 來套我們的 UI Component，一旦設計有變我們直接就改 UI Component 就好了。但這種設想能夠成立的前提條件是，Container Component 所能提供的數據結構或格式都是確定的。這便意味著，一旦數據源（Data Source）或者 Container Component 提供數據的方式有變，下面的 UI Component 就得跟著變，如果 Container Component 下面的 UI Components Tree 很深，那就，科科。這跟以前並沒有什麼區別。

Shihchi 在 Speak 中提到了 HOC（Higher-order Component），相當於以一種裝飾器（Decorator）的方式，將一些 UI 「套路」封裝成 HOC。以 TodoApp 作為例子，將每一個 Todo 元素分為兩類（或者更多），可以理解為狀態（如可被完成的未完成 Todo、可被刪除的已完成 Todo），而這些類別的 UI 和功能都是可以被重用的，而它們之間的差別就在於內容（title）。那麼就可以用一個以函數作為載體的裝飾器，將內容部份的 JSX 傳入這個裝飾器中，裝飾器便返回帶有外部 UI 或功能的新的 JSX（已包含傳入的 JSX）。如果你還是不懂，那就可以理解為語法上沒那麼繁瑣的組件繼承……

而另外一位來自 Facebook 的講師 Stepan 的主題是「Universal Application」。說實話，實際上，額……我愣是沒聽出這個 Speak 的意義在哪裡。

這種讓前端框架在後端處理業務，然後後端的 Router 只需要負責 handle 一個通用的 GET 請求的模式，React 不是第一個，也不會是最後一個，已經被玩兒爛了的概念；
從前需要用 Rails + JavaScript 才能完成一個 Application 的開發，現在只要 JavaScript 就夠了！以前需要 Objective-C，需要 Swift，需要 Java 才能完成 iOS App 和 Android App 的開發，現在也只需要 JavaScript 了！萬稅！科科

（這個概念我在 12 年的 HuJS 上便已經討論過了，但是到現在又有多少家公司真正地使用這種模式開發完整的應用呢？

0x02 WeChat

得知今天微信的同學居然要分享微信的 Web，這當然少不了 JS-SDK、X5 和自黑了。微信公佈了一些他們自己的踩過的、挖過的坑以及一些解決方法，還有現在微信的設備碎片化數據。怎麼說呢，其實我剛好跟 @大漠出去聊八卦了，沒仔細聽，不過微信能正確對待自家産品的問題，並給予解決方案是相當值得讚賞的。

最大的驚喜可能就是 X5 with Blink 了，別問我為什麼，反正做過微信 WebApp 的同學都應該懂聽到這個消息時的心情。

0x03 下一代 Web 技術

來自企鵝的老員工舜子同學，我認為是今天之內最乾貨的一個 Speak。我跟北教也正好坐在一起，可以說是認真地進行了分析並討論（？？）。

Service Worker 是被剛提出不就的一個相當有意思的 Feature，它剛被提出來的時候，大家都幾乎一致認為用於離線緩存是 Best Practice。不過迴歸到 Service Worker 本身，其實我們可以看到更多的可能性，因為它與以往的 Web Worker 不一樣的是，它可以獨立於頁面運行，不受頁面狀態影響。這樣它就具有很大的想像空間了，我們甚至可以將它用在一些我們意想不到的地方：頁面資源的管理（遊戲、應用等）、將一些需要獨立於頁面運行但又不希望浪費服務器資源的程序等等等等。

而舜子給我們講解了騰訊在頁面加載優化上的經驗和思考（如首屏落地的 1s 原則），從以前只是關注於頁面自身的優化，到逐漸向底層進發：瀏覽器、網路、操作系統等等。其中以手機 QQ 為背景，說明了在 Hybrid App 中，我們需要如何利用離線方案，使得 Web 頁面變得儘可能快，就此引入了各種緩存、離線方案，其中便包括 Service Worker。

手機 QQ 的 Web Page 離線方案是通過 Native 部份向服務器請求靜態資源包，然後將利用版本管理、增量更新等特性，合並到前一個版本的靜態資源中，而用戶基本每一次加載，都會直接到本地的離線空間中加載頁面，大大地縮減了網路請求的速度。

——————前分割線——————

在聽這個 Speak 的時候，我就跟北教主坐在一起，我們不約而同地說道：各家在 Hybrid App 優化上的方案，在經過多次迭代後，基本走向了統一。可以說，絕大部份內容更新頻繁的 Hybrid App 的離線方案跟舜子在這裡介紹的，基本沒有什麼差別。

而這時，我不禁地想像到，其實這種方案遲早會推出一套標準的框架或是解決方案。而我認為最需要這種東西的廠家是微信，雖然說不太可能讓每一個用於微信的 WebApp 都有權限可以將資源離線保存在用戶終端中，但是完全可以通過政策管理手段來實現，比如必須要認證的訂閱號、或是必須是服務號才能使用，等等。

——————後分割線——————

舜子後面為我們說明了中國 HTTPS 的現狀（窘狀），這裡我也沒什麼好說的，趕緊 Let"s Encrypt 吧。

﹣﹣﹣﹣

最後一個老外的 HTTP/2 分享沒怎麼聽，因為跟 @winter 搞 JI 去了

在圓桌會議上，真阿當成功躺槍。

這次性能的主題準備得比較淺，需要深入交流的可以知乎上 at 我^_^

2017年的明天就在北京開了

你有去嗎

門票有點貴，買不起

大神分享都很贊，現場居然還有不少美女前端，旁邊的哥們口水快淌了一地。。。

另外吐槽一下FEDay你是有多缺錢？！門票500+也就算了，第一次看到連礦泉水還要賣廣告位。。。

參加的原因一大部分是因為看到有關react的話題

果然又是漲了一波姿勢