淺談函數式編程和 React

函數是有定義介面的運算單元。

介面有用的地方是抽象化，你只需要知道輸入什麼(Input)、會得到什麼輸出(Output)，你不用知道它細節是怎麼做到的。其實有個超能力在背後，也沒關係。當然這是在沒有碰到 bug 和有良好文件、不需要修改它的前提之下。

再強調一次，你只需要理解輸入(input)會對應到什麼輸出(output)就夠了。


問題來了，怎樣的輸入和輸出的對應「介面」會容易讓人理解？
1. 有意義的函數名稱

2. 多寫沒有副作用的純函數
    1. 有可預測性：
       每次輸入得到相同的輸出、函數內部不存狀態    
    2. 沒有副作用：
       運算過程中不會改到外界的變數，像是不改傳進來的參數、不改可以存取的全域變數。    
    3. 顯式(Explict)：
       函數和外界溝通的管道只有，傳進來的參數和回傳值。

3. 簡化參數、對資料結構的 Information Architecture 做良好設計

4. 用函數來定義函數
    1. 柯里化(Currying)：
       透過不同給參數來產生新的函數
    2. 合成(Compose)：
       透過 pipeline 串接函數的input和output、隱藏參數，產生新的函數。


函數式編程為什麼強大、有彈性？
1. 把每個函數切得很小，容易更新、維護、平行處理、多人共同開發、被理解

2. 透過合成(Compose)把小函數變成大函數，比用繼承有彈性的多

3. 對集合實做 Functor 介面，讓一般函數都可以對集合操作。(array, matrix, tensor)

4. 把純和不純的函數分開來管理，容易找到問題點。


函數式編程為什麼難寫？
因為函數式編程想要把程式變簡單。但大家都知道「變複雜是簡單的、變簡單是複雜的」。所以這種方式寫程式需要設計、思考，你會是一個程式「設計師」。但如果你現在的專案寫完之後沒人會看、不會再改、不用維護、規模不大，也許函數式編程並不能幫到這個專案多少。


寫 React 就是實踐函數式編程
1. 透過自定義元件，定義畫 View 的抽象化函數樹

2. 透過 JSX 語法把小函數組合成大的函數 (等同於 compose)

3. 鼓勵大家寫 dumb 元件、也就是純函數

4. 用唯讀的 props，限制大家不能改傳進來的參數、減少副作用

5. 透過導入 flux，把純和不純的函數分開來管理
    1. 純的 (對資料只做讀的動作)：每個元件中的 render function
    2. 不純的 (對資料做讀和寫的動作)：
       flux中對 action 的 callback、redux 中的 reducer、父元件傳給子元件的 callback
    3. glue code：元件中其他的 javascript



從函數式編程的角度看 React 的問題？
1. 沒有什麼高階的集合操作方法：
    1. 把 lodash.js 集合操作拉進來用？
    2. 用 lenses 的方式來穿透深長不露的 states?

2. 沒有簡單的 currying 語法
    1. 像是傳不同參數給 html5 input 元件，生出各式各樣對數字的、email、submit、text的自定義元件。最簡單寫法應該是 
    2. export function NumberInput(props) { 角括弧input type=“number” {…props} /> }
    3. PS: function 一定要有名字不然 debug 會很慘。

3. 雖然集中管理了不純的函數，但還是很難寫：現在透過修改 store 中的 state 來控制元件，這邊 action 觸發的都是不純的函數，如果元件架構一深，還是會很難改。有解嗎？這邊還沒找到什麼 coding guideline…
    1. 多個 container smart 元件
    2. flux 的多個 store
    3. redux 的階層式 reducers
 
-----------
延伸閱讀：
deku: functional alternative to react 
how to use classes and sleep at night (in a functional way)

React UI 心得文之一

這週在忙著刻一個大元件，中間有包兩三個中元件、然後中元件下面又會有小元件。要記得React 是負責 UI 的啊，千萬個不該在小元件裡面存 state。存了改了兩天還是會有問題，小元件如果存了狀態，常會有那大元件重 render 的時候，設 property 卻無法更新小元件，因為小元件的 state 不一樣了。兩天之後把大中小元件全部改成 dumb component 真的快樂的不得了，程式碼變少了、邏輯也清楚了。


刻 React 元件的方法：

1. 盡量刻 Dumb Component，把它當成 function 去想要提供什麼參數
2. parent component 要對 child componet 命名和設 handler(childId, value)
3. 事件發生時就呼叫 parent 傳來的 handler，說你是哪個 child和發生了什麼

就這樣遞迴做下去，最上層的 App component 就可以知道，哪第三個child component 的第四個 child component 發生了什麼事，然後做一些處理。

客制化 React 元件外觀的方法：

1. 幫元件的各種 property 類別放置對應的className
2. 用 webpack 的 css loader 幫元件建立 local 的 css scope，然後用一個 scss 檔去管理一個元件，這樣一切都會輕鬆的多。( 參考 React Toolbox )

其他刻外觀小心得：

1. 多用 em, rem
2. 用 css 幫背景上色的方式，快速看物件是否對齊
3. 用 Mac 的放大鏡 ( ctrl + 雙指滑動 trackpad )
4. 用 css trick cursor 去引導 behavior
5. 用 font-weight 和 color 的 alpha channel 去做細部微調

學各種 React 相關 Library的方法：一定要從看完官方的 Tutorial/Guide 開始，網路上的介紹文章通常都挑簡單的地方說，十篇有九篇都講一樣的東西，還不如看官方的 Tutorial/Guide 把重要的東西有系統的一次學會。很重要所以特別粗體一下...

使用者經驗部分：

碰到客戶想要重新客製化系統的時候

1. 照他們舊有的行為，模擬跑自己刻的新系統幾次，很快就可以知道缺了什麼、哪裡會生出問題，這樣的方法比在那邊天馬行空的猜測會方便的很多。例子: 新報表系統拿舊系統的許多報表重新打一次。
2. 用心智圖的方式窮舉可能的行為，不然光是用腦袋想一定會漏掉很多細節。

和他人合作的部分

一定要定時 Sync 進度，時常 commit。不要隱匿進度落後、缺失、維護 local state，想說這樣可以加班追回來。因為很多事從他人的角度來看會清楚的很多，也方便別人調整。不要裝弱、裝強，快放棄那沒用的自尊心吧。

Redux = 事件驅動系統 = 伺服器

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.

Action	Event | Signal | Message
Reducer	Event Handler | Finite State Machine 中的 transducer

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

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

Action	Http Request
Store.dispatch(Action)	送 Request 到 Server
Reducer	Router 把 Request 送到對應的 Router Method，更新 Database
Store	Database
UI / React	Http Response

Redux的行為等於巷口那家... 哎 想不出來比較生活的說法。

現在有沒有覺得 Redux 很 Awesome？好像沒有啊... 但我們回到瀏覽器的環境重新看一下，因為 HTML 的元件很小，開發者會組合 HTML元件成為可重複使用的「大元件」。但問題是瀏覽器中的 「事件處理系統」 是針對 HTML 小元件的，沒有給「大元件」的。於是Redux 提供了給開發者可以自行定義事件的「大元件」事件處理系統，因為你可以控制整個事件處理系統，重播和紀錄事件都變成毫不費力的事。現在又感覺到  Redux 很 Awesome了吧!!!

故事到了這邊，一定會想這樣解說，哪個六歲小孩能了解啊，相信這是大家共同的疑惑，不過 「投資一定有風險，基金投資有賺有賠，申購前應詳閱公開說明書」，我會反省的...

---

延伸閱讀：
redux 的專有名詞解釋
Redux Issue 891：Is redux conflating actions with events?
六歲小孩也能懂的 Javascript Closure 說明

React 和 Flux 到底在做什麼?

看了下面兩個文章，終於知道 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 就好。

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

1) 網頁開發不像開發原生應用程式，有功能性較大完整的原生元件。只有一堆小到不行的 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的前端系統

介紹 React.js (2013 by Facebook )

Introduction to React.js by Tom Occhino and Jordan Walke

整個React.js的由來是很多Facebook內部對一個問題的討論。這個問題是 開發Javacript的應用時，它的結構應該是如何？ ( " How should we structure a javascript application? " )。特別是瀏覽器端的 Javascript 應用。前人透過各式各樣的 framework 提出一大堆的解答。這些 framework 通常試著去實踐 MVC, MVVM, MVW 各種概念。這些架構或 framework 共同點就是 M，也就是 Model... 基本就只是一種可觀察的物件 ( observable object )，然後這些可觀察的物件有一些Event API，讓你訂閱物件改變的通知 ( subscribe changes )。

實際上發生的事 是開發者建立了這些雙向資料綁定 ( bi-directional data-binding )，讓你可以訂閱物件改變的通知。當某個東西改變了，你就可以變動 ( mutate ) / 更新你的 View。但這種觀察模式 ( observation pattern ) 實際上鼓勵 UI 的變動 ( mutation )。每次先把元件畫出來，然後當改變發生時，就試著更新之前畫出來的 UI 元件。這邊的關鍵字是變動 ( mutation )。變動 ( mutation ) 是複雜的。大概兩年半前，Facebook試著重寫聊天室。我們試著把事情變簡單，試著把開發者要處理的變異 ( mutation ) 減到最少。讓我來解釋一下那是什麼意思，下面是一個簡單應用的架構：

要注意到的一件事是 在這個系統中的所有更新 ( updates ) 都會走一個單一的通道 ( go through a single channel )。它們都朝著單一方向流動，讓我們叫它 單向資料綁定 ( one directional data-binding )。所有輸入到這個系統的更新，不管是來自使用者輸入、即時的server updates或是起始的Loading。這些所有的更新都只透過單向的流動，不管怎樣最後都會流到 View 方格那裏。這一塊是所有前端工程師，我最關心的地方... 對嗎? 我關心使用者經驗、使用者真正看到和接觸的地方。概念上來說，我們發現建造這一塊 / View 最簡單的方式就是避免變異 ( mutation )。基本上是完全避免變異。我們發現，如果每次更新發生我們可以把整個 View 砍掉，整個重繪，那會變得超簡單。因為這樣，你只要寫怎麼把 View 畫出來就好，不用管 View 怎麼更新的程式碼。

但這樣亂搞，可行嗎？

從瀏覽器的角度來看這一定會很慢，記憶體還會不夠之類的。但概念上來說 ( conceptually )，我們還是想要用這個Model。因為每次更新就重繪真的很方便，但前提是要速度可行和還是能給使用者好的經驗。我們提出來的解法就是React.js。

React：一個為了建立使用者介面的Javascript程式庫。

我們想要所有來自 更新就重繪這理念 好的部分，但避免其中壞的副作用 ( bad performance & bad ux )。從此之後你不用管你的應用中從 state a -> state b -> state c，只剩下 零 -> 畫出來。

React 的核心是宣告元件 ( Declarative components )：
在任何時間點都只要描述你的元件長什麼樣子，這不只是一個樣板 ( template )，這不是呼叫一個函式然後回傳一段字串那種事。因為那樣的話，你要整個 DOM 砍掉，然後把新的 HTML 掛上去。元件實際上是可重複使用的 API，封裝了一大堆東西，像是 markup、這東西看起來怎樣、它的功能是什麼、它的行為、CSS、Javascript 和這些東西的結構是什麼，是這些全部的東西。對於使用者元件隱藏了實作的細節，讓我給你一個實例：

輸入元件：提供互動的 auto-complete search box，只要用跟原始 HTML <input> 一樣多的程式碼。然後我應該可以對她註冊事件、設定它的行為 ( behavior ) 有哪些。

No explicit data binding：不像 AngularJS，React 不需要實際上 Wire 你的 View 到你的 Model，你只要說哪一個屬性 ( property ) 你的 Model 想要在你的 View 中使用，然後當 Model 改變時、你的 View 就會被更新。

它是怎麼運作的? ( How does it work? ) 我們這邊說兩件事。
1) 它一開始是如何畫出來的。 ( Initial Render )
2) 更新是如何發生的。

Initial Render：在 React 我們只找一個 render function，這個 render function 完美的地方是它一直能告訴你這元件在任何時間的樣子。你提供的這個 render function 不會回傳一個字串，它回傳的是你的 View 的表現 ( representation ) ，我們做的事是... 既然元件可以由其他元件組成  ( composited by other components )，我們遞迴的呼叫render來建立UI架構。

Two Pass Rendering：
1. 先建立 markup
2. 在最上層用 Event Delegation 附加上事件處理器

因為步驟一，先把元件畫出來，我們可以做 Server-side Rendering。

更新是如何發生的？
我們不稱這個動作為Update，我們叫它 一致 ( reconciliation )。它的目的是保持你的 UI 元件 新鮮、當資料變化時自動更新。每個人應該現在都感到懷疑，如果不懷疑你大概剛剛都在睡覺。但你應該記得剛剛說的 Initial Rendering function，任何時間點它要回傳一個元件的表現 ( representation )。當改變發生時，我們重新呼叫一次 Render，然後比較原來 Render 的結果和改變過後 Render的結果，計算出兩個時間點元件的差別 ( diff )。接著批次計算出最少的變動量，然後一次 把變動更新到 DOM Tree 上面。所以很快。

---
12:20 開始 Show Code Sample 和 JSX 語法
   程式碼還是看影片比較清楚... XD

26分開始大概一小時的Q & A 還蠻精彩的~~~

Be predictable, not correct. by Pete Hunt (from Instagram)

Pete Hunt from Instagram Web Team.

What makes UI hard?

最難的是管理所有使用者的狀態 ( state )，更可怕的是隨時間改變的狀態。然後 Unit Test 不能完全測試 UI 的所有情況 ( 太多例外 )、靜態分析 ( JSLint / JSHint ) 也不行。因為這樣的複雜度，我不曾試著讓 UI 完全正確。我只是試著讓 UI 變得可預測。

Two silver bullet:

1. Composition: 讓簡單的 function 組合成更大的 function。
2. Idempotence: 讓每次同樣的 Input 得到同樣的 Output。不變性 ( Immutability ) 的資料結構讓我免費得到 Idempotence。努力讓 mutable state 的數量越少越少，mutable state只有一個owner。

React.js 讓工程師照著上面的兩個規則。
React 是 宣告式的 ( declarative ) JQuery。

React
 > Data 輸入 => virtual DOM 輸出。
 > 當資料改變的時候，就整個重繪，所以少掉很多 State。

Demo Example (從15- 分)

Demo on jsfiddle.net jsbin.com
一直在看Code