影片：Functional Programming in Javascript By Daniel Steigerwald 

Daniel 是 google 前員工、也是 https://github.com/este/este 這個 React + Redux + immutable.js Starter Kit 的作者，在 Github 上有 1800 顆星。

我認為函數式編程 ( Functional Programming ) 將在明年成為主流。像在 C++11 和 Java 8 中已經開始有 lambda function。我接下來聊我已經用在 Production 的東西。我認為函數式編程已經在前端的世界已經被 React 引入。

什麼是函數式編程？
沒有什麼神秘的東西，到處都是純函式 ( Pure functions everywhere )、不可變的數值 ( Immutable values )、用組成而不用繼承 ( composition over inheritance )、紀錄代替類別 (records over classes)、處理好副作用 ( taming side-effects )。我覺得 functional programming 有點像是人工智慧，聽起來有點酷、有點奇怪，但當你了解了它以後，就只是無聊、很平常的寫程式而已。

為什麼要函數化 ( functional )？ 
因為軟體正在吃掉這個世界，它必須要做到最好。函數式編程已經被證明，比較少臭蟲 ( less bugs)、較不複雜 ( less complexity )、程式碼更可讀 ( more readable code ) 和更好的效能 ( more performance )。

物件導向程式設計 ( OOP ) 有什麼問題？
沒有問題，只是很難、常被誤用，而且有時是難以避免的。整個物件導向程式設計的模式 (paradigm) 是基於「送訊息給物件是唯一跟狀態 ( state ) 互動的方法」，因此狀態就會被分散。於是在分散式系統中狀態的一致的難度是跟世界和平一樣的 XD

Redux 做的事情其實很簡單 ( 主程式才99行 )，就是可客制 Event 的 Event System。這概念在別的領域已經很成熟。但因為 Redux 的目標使用者是 Flux 的使用者，套用了很多原來 Flux 裡的專有名詞，所以對非 Flux 使用者變得很難懂。這邊透過類比大家都知道的名詞，目標讓 Redux 的概念連六歲小孩都能理解。

Flux：

Actions trigger reducer to update states in the store.

Redux 的行為等於事件驅動系統 ( Event-driven System ) / 有限狀態機 ( FSM )：

Events trigger event handler to update states in the machine.

Redux 的行為等於一個網頁伺服器：

When a request came, using route table mapping to get a method to process it。

英聽：
看youtube都開 1.25x 或 1.5x 的速度，聽得很順、完全可以理解。(感謝無字幕的 冰與火之歌 和 廢話很多的 ASP Surfing Championship 對我的訓練 )

簡體中文閱讀：
看了很多對岸的文件和字幕 XD，一下就適應了。快要和繁體一樣快。( 因為看太多小說，我對中文的閱讀速度真的很有自信 )

英文閱讀能力：
唯一的問題就是我的英文閱讀速度，上不去啊。想十年前 ibt 托福閱讀還拿了 29/30，還是不夠。做了這個 英文閱讀能力線上測驗 發現我現在的閱讀速度只有每分鐘 150 個字 ( 退化…? )，大概是美國小學生的能力。成人平均是 300 個字、大學生平均 500 個字、成績好的大學生大概是 800 個字 ( 這應該是一般部落客的水準吧 )、練過速讀大概是 1500 字。測完就知道我瓶頸在哪了。以前看論文或是教科書，完全沒問題啊，因為那時的瓶頸是理解能力。但現在 Javascript 的資訊很多是部落格，廢話跟我一樣多的部落格，英文閱讀能力就變得超重要。

偷吃步的解法：一個是叫 Mac 唸給你聽… 叫 Mac 念得很快，測過快到超過我的英文閱讀速度還是聽得懂。另一個是只看程式碼，但這畢竟只是治標，今天開始尋找治本的方法。

速讀的訓練的方法：
1. 練習眼睛移動：
用規律的速度，拿支筆從每行的開頭，指到每行的結尾。影片剛開始建議的速度是 1.0 秒/行，然後縮減到 0.5 秒 / 行的速度。換算下來大概是每分鐘 800 個字到 1500個字。但對我這個小弱弱，剛開始每三秒一行就好，然後目標練到一秒一行就好。練習的方式是開著節拍器，跟打鼓一樣，設定它每十五分鐘從 20 bpm 加速到 60 bpm，每拍一行開個 16 分音符剛好，每個聲響移動1/4行，慢慢進步。

2.  練習邊緣視覺：
筆不用從開頭指到句尾。從開頭第 N 個字開始，看到結尾前第 N 個字就好，因為邊緣視覺會看見。慢慢練習 讓 N 從 0 變成 3。

今天開始每天練十五分鐘，看到底管不管用、目標每分鐘 800 字。 (快五倍… 這有可能嗎？)
目前能力：每分鐘 150 字 (每五秒一行)
週目標：每分鐘 400 字 (每兩秒一行, 30 bpm)
月目標：每分鐘 800 字

好像會有個 browser extension 來訓練這種事吧，我找找…

wow… 估了一下，我國中看一本金庸大概五小時、大概每分鐘 900 個字。是我現在英文閱讀能力的六倍 T.T

BIG WORD ALERT!!!
———
研究了Redux.js之後，對State Machine有了更深的領悟。

上個月解了一百多題 LeetCode，深深覺得程式解問題很重要的一點就是，想出一個「資料的表達的方式」讓問題運算過程中的所有「狀態」能夠清楚的表達，之後只要叫電腦從 Initial State 算到 Final State，題目就解完了。這個「資料表達的方式」也許是 stack、也許是 Array 再加上兩個 Pointer、也許是 2D Array表達地圖狀態、或複雜一點的像是 八皇后(N-queens) 問題用四個 array 來表達row, column, 兩個斜線方向有沒有皇后。只要想完「怎麼用資料來清楚表達所有狀態？」這個題目就解一半了，如果是 backtracking / 窮舉的問題的話，那你就已經解完了。

不過，這個跟 Redux 有什麼關係呢？Redux做為Flux概念的實現，設計中 Store 是唯一的資料儲存中心，它把所有「元件狀態的資料」集中放在一起。讓開發者很容易用抽離 UI 的角度思考，一開始就把應用程式中「0. 怎麼用資料來清楚表達所有邏輯狀態？」這個問題給想清楚。這個問題解完了之後，剩下的只有兩件事：

 1. 收到使用者 Action 或伺服器的更新，要從哪個 state 換到 哪個 state：應用程式的運作邏輯，這部分 Redux 用 Reducer 做掉了。在 Reducer 中你要清楚定義狀態機中的 Transition 也就是 ( previousState, Action ) => newState 這件事

 2. 在每個state的時候，應用程式 / 元件要畫成什麼樣子：React 想解的問題

0 和 1 兩個步驟常常會平行設計、互相影響，這部分會定義你的產品功能面。
2 的步驟就是視覺化、資料傳達的部分。

—
總結，從State Machine的角度來開發只要做下面三件事：
1. 想好怎麼表達 state。 ( Redux Store )
2. 想好有哪些事件，事件會讓 state 間怎麼切換。 ( Redux Reducer )
3. 如何把狀態傳達給使用者。 ( React )
從此開發就有了 SOP。

PS: 「資料的表達方式」包含了「資料結構」和裡面結構中資料代表的意義。

看了下面兩個文章，終於知道 React 和 Flux 在做什麼了。
1. ReactJS For Stupid People
2. Flux For Stupid People

以下開始和主題不很相關的廢話，可以直接跳到最後一段「好啦，說了一大堆廢話。」

前兩天一直迷惑，到底這套新的 UI 開發流程和我過去接觸過的 framework 們有什麼不同？以前用過 Java AWT, JAVA SWING, ZK Markup Language, JQuery UI, iOS UI Kit, Android, QT Component, OpenGL, xxxRendering Engine … 列出來才發現，真的是有的沒的一大堆。

在螢幕上生出畫面大概可以分成三群：
1. 網頁開發
2. 桌上 / 手機的原生應用程式
3. 遊戲 / 動畫

3. 寫遊戲和動畫的流程最簡單，大二用組語刻了魔法氣泡遊戲 / 大三參加趨勢比賽徒手硬幹JAVA Swing ( 真的超慢的 T.T ) / 研究所用 3DS Max 和 Blender 做動畫 / 工作上用 OpenGL 做了動態路徑規劃的資料展示。這一類大概每次就是重畫，隨時檢查物件狀態一直重畫。看一下 FPS 有到 Real-Time 就好。

4. 開發原生應用程式的流程就是用原生的物件，不管太元件長什麼樣子，反正就是設計互動，註冊事件，最多就小改一下背景、顏色之類的。反正最差就是比較醜，功能都沒問題啊。話說 MFC 到底是什麼鬼東西啊… 記得花了兩三天從來沒搞懂過。

5. 網頁開發不像開發原生應用程式，有功能性較大完整的原生元件。只有一堆小到不行的 HTML 元件。然後問題就來了… 網頁上一塊塊重複的物件，像是 部落格、購物網站、討論區上面一個個的模組要怎麼搞。

如果是靜態的網頁，就背後用 php 弄個模組 ( 喔 交作業而已別太嚴格啦 )，Header 一個Template、商品一個 Template、側邊欄一個 Template、導覽列一個 Template，然後就很開心地從資料庫抓一些資料填進去Template就好啦。有什麼事件發生就傳資料到伺服器端，整個重新畫頁面就好。老實說還挺簡單的，怎麼流程聽起來很像ReactJS。但是 2004 年，總是有一些天才們發明了一些讓人很累的東西叫做 Ajax 把 Gmail 推上了時代尖端。Ajax 告訴所有開發者：「喔 什麼!!! 你把使用者輸入送到伺服器再傳回來，然後才更新 UI，太慢了喔 弱~」。然後從這時候開始，網頁設計師就很苦情的開始在客戶端開始亂刻元件，MVC 邏輯的重擔就移交給 HTML、CSS、Javascript。但主流的開法方式是，不管 MVC 也行啦，反正網頁會動看起來有設計感就好。

JQuery Library 在這亂世中應運而生，讓我苦讀 vanilla Javascript 的經典「ppk談Javascript」變得英雄無用武之地，JQuery 的 selector 就像用 matlab 來處理資料的有快感、dot chain rule 讓語法看起來糖分很高、不用打 getElementById 就像 C++11 中用 STL 不用打 Iterator 一樣清爽。可以快速開發出很難維護的網頁。解決了 Javascript 操作 DOM 會讓人想罵髒話的問題。為什麼很難維護，因為沒有元件化，Javascript有很有力量，讓人在網頁裡隨性的的東改西改，但不知道誰改的就很難 Debug，漸漸變得複雜就不能開發大型網頁。

然後 AngularJS 把後端流行的 資料綁定搬到瀏覽器來，用 Javascript 的 Closure 來做封裝、一區區的資料分別藏起來，限制一部分 Javascript 只能操作 一部分的資料和 HTML，充分發揮了各個擊破的演算法 ( Divide and Conquer )，可是問題又來了… 媽的我花了兩天，學不會 AngularJS 啊一直 Typos 很煩，雙向綁定怎麼那麼複雜，讓我寫程式一直 NG NG。所以我沒太多研究，只聽說是雙向資料綁定會引起 DOM Tree 的 Cacading Update，導致效能容易有問題。另外 HTML 裡塞了太多髒髒的東西，容易消化不良。

好啦，說了一大堆廢話，React 和 Flux 到底做了什麼？

React 讓人用 Javascript 和 HTML 刻更高級的元件 ( Virtual DOM )，像是 Angular 元件做的限制 讓一小段 Javascript只負責一小塊的UI / HTML更新，使用各個擊破的演算法，刻完元件之後就像開發原生應用程式時一樣，有了較大的元件，讓人跳脫低級 ( low level ) 的思考，少說一點髒話，透過 JSX 讓人從模組化的角度看 UI。簡單的譬喻就是讓人用組語開發高階語言的語法，之後可以用高階語言寫程式。

React 只 Update 新的 DOM Tree 中和前一次 DOM Tree 差異之處，他們管這叫 一致 (reconciliation) 讓重繪的速度快很多，當重繪夠快，網頁的開發者就可以回到 pre-AJAX時代，回憶2004年之前的寫開發體驗：把資料送回伺服器，然後收到新資料，整個網頁重繪。

只是這回，資料來源的不是 Database，是 Flux 資料集中管理辦法中的各個 Store ( Client-side Database )。Flux的單向資料流理念，強迫你在客戶端有一個像資料庫的資料集中處，Store裡有來自使用者輸入的資料、有來自伺服器端的資料更新。然後這個資料商店把每一家元件訂閱的資料送上門，元件看了看送來的資料商品然後就更新。Store 像是介於 CPU 和 硬碟中間的 Cache / Memory，是資料的 暫存處和Hub，或是你叫它客戶端的暫存資料庫也行 ( 用 Javascript 物件存的 )。

原來：
Browser – Client Side ………………………………….. Server

有了 React + Flux 之後 :
Browser – Client Side – Client Side VM + Server ( React + Flux ) …………………………………… Server

有點像是在 Client Side 包了一層 VM + Server 一樣，會把 JSX 轉譯成JS / HTML、集中把資料放在客戶端資料庫裡 ( Flux 的 Store )。

簡單總結一下：
React + Flux 是大規模動態資料網頁的解法。

React 讓需要大型互動元件的客戶端，可以用自己刻的、封裝良好的元件，並在新元件的高度思考。用了個 Reconciliation 的 Trick使得重繪很快，和 Flux 的資料集中管理辦法，讓開發者只要專注做好一件事「當資料來到元件時，把元件要畫好」。

Flux 目的是提出一個客戶端的資料管理辦法。其中的單向資料流 / 資料環其實隱含了 Two way Data Binding，只是不是綁死，比較像是 Two way Data Notification。Dispatcher 管的是 View Actions -> Store ( Models )。Store 除了存資料外還包含了 Store ( Models ) -> View 的通知。還有人覺得 Dispatcher 很多餘，就寫了一個 reflux.js 把 Dispatcher 拿掉。

延伸閱讀：
聊一聊基於Flux的前端系統