JavaScript 函數式編程到底是個啥
隨著大前端時代的到來，在產品開發過程中，前端所占業務比重越來越大、交互越來越重。傳統的老夫拿起JQuery就是一把梭應付當下重交互頁面已經十分乏力。于是乎有了Angular，React，Vue這些現代框架。
但隨之而來的還有大量的新知識新名詞，如MVC，MVVM，Flux這些設計模式就弄得很多同學傻傻分不清。這時候又見到別人討論什么函數式編程，更是一臉懵逼了。
我們大多聽過面向對象編程，面向過程編程，那啥又是函數式編程呢？在我們前端開發中又有哪些應用場景？我抱著這個疑惑，初步的學習了下。 （此文僅是學習，無甚干貨）。
函數式編程
定義
函數式編程（Functional Programming，后面簡稱FP），維基百科的定義是：
是一種編程范型，它將電腦運算視為數學上的函數計算，并且避免使用程序狀態以及易變對象。函數編程語言最重要的基礎是λ演算（lambda calculus）。而且λ演算的函數可以接受函數當作輸入（引數）和輸出（傳出值）。比起命令式編程，函數式編程更加強調程序執行的結果而非執行的過程，倡導利用若干簡單的執行單元讓計算結果不斷漸進，逐層推導復雜的運算，而不是設計一個復雜的執行過程。
我來嘗試理解下這個定義，好像就是說，在敲代碼的時候，我要把過程邏輯寫成函數，定義好輸入參數，只關心它的輸出結果。而且可以把函數作為輸入輸出。感覺好像平常寫js時，就是這樣的嘛！
特性
網上FP的定義與特性琳瑯滿目。各種百科、博客、一些老師的網站上都有大同小異的介紹。為了方便閱讀，我列下幾個好像比較重要的特性，并附上我的第一眼理解。
-
函數是一等公民。就是說函數可以跟其他變量一樣，可以作為其他函數的輸入輸出。喔，回調函數就是典型應用。
-
不可變量。就是說，不能用var跟let咯。按這要求，我似乎有點難寫代碼。
-
純函數。就是沒有副作用的函數。這個好理解，就是不修改函數外部的變量。
-
引用透明。這個也好理解，就是說同樣的輸入，必定是同樣的輸出。函數內部不依賴外部狀態，如一些全局變量。
-
惰性計算。大意就是：一個表達式綁定的變量，不是聲明的時候就計算出來，而是真正用到它的時候才去計算。
還有一些衍生的特性，如柯里化與組合，三言兩語說不清，就不闡述了，有興趣的同學可以自己再了解了解。
FP在JavaScript中的應用
React就是典型的FP。它不同于Vue這樣的MVVM框架，它僅僅是個View層。
ReactView = render(data) 它只關心你的輸入，最終給你返回相應視圖。所以你休想在react組件中去修改父組件的狀態，更沒有與dom的雙向綁定。
這個是框架上的應用，那么在我們平常書寫JavaScript時有哪些應用呢？換句話說，平常書寫js時候，遇到什么情況，我們采用FP會更好。
從最常見的入手吧，如典型的操作數組：
// 從users中篩選出年齡大于15歲的人的名字
const users = [
{
age: 10,
name: '張三',
}, {
age: 20,
name: '李四'
}, {
age: 30,
name: '王五'
}
];
// 過程式
const names = [];
for (let i = 0; i < users.length; i++) {
if (users[i].age > 15) {
names.push(users[i].name);
}
}
// 函數式
const names = users.filter(u => u.age > 15).map(u => u.name);
嗯，代碼精簡了很多，但是貌似帶來了更大的開銷。如果是非常大的數據，非常多的篩選工作，那就會循環多次。
這里得想到剛剛的惰性計算。按照惰性求值的要求，應該是要最后返回結果時，才真正去篩選年紀并得到姓名數組。
然而JavaScript的數組并不支持惰性求值。這時候我們得上一些工具庫，如 Lodash 。可以看下它文檔中的例子： _.chain 。
好像也沒好到哪里去啊，不就是把多行代碼變一行嘛？說的那么玄乎，還多了性能開銷，然后又跟我說得上個工具庫。。。
說的好像很有道理，但是for循環是有個弊端的，它產生了變量i，而這個變量又是不可控的，如果業務邏輯一復雜，誰知道它循環到什么時候i有沒有發生變化，然后導致循環出問題呢？
我們再看一個與DOM交互的場景：
假如頁面有一個按鈕 button ，我們需要求出用戶點擊了幾次，但是一秒鐘內重復點擊的不算。傳統方法會這么寫。
var count = 0;
var rate = 1000;
var lastClick = Date.now() - rate;
var button = document.querySelector('button');
button.addEventListener('click', () => {
if (Date.now() - lastClick >= rate) {
console.log(`Clicked ${++count} times`);
lastClick = Date.now();
}
});
妥，完全沒問題。但是發現多了很多狀態，count，rate，lastClick，還得對比來對比去。那如果用FP會是怎么樣的呢？
抱歉。。。沒法寫。。。除非很強大的編程能力，自己封裝好方法去處理。所以在這里，我們可以上個工具--- Rx.js ，上述的例子就是rxjs中引用的，我們看它是如何優雅地處理的。
var button = document.querySelector('button');
Rx.Observable.fromEvent(button, 'click')
.throttleTime(1000) // 每隔1000毫秒才能觸發事件
.scan(count => count + 1, 0) // 求值，默認值是0
.subscribe(count => console.log(`Clicked ${count} times`)); // 訂閱結果、輸出值
巧奪天工！再也不用去管理狀態了，不需要聲明一堆變量，修改來修改去，判斷來判斷去，簡直完美。
平常我們有很多需要更新dom的異步操作，如搜索行為：用戶連續輸入查詢值，如果停頓半秒就執行搜索，如果搜索了多次，發起了多次請求，那只返回最終輸入的那次搜索結果。
閉上眼想想，你之前是怎么實現的。反正我都是設置開始時間，結束時間，上次時間，等等變量。繁瑣，而且不可控。
當我們以FP的思想去實現時，就會想方設法的減少變量，來優雅程序。最常見的方法就是用下別人的工具庫來實現它。當然有些簡單的場景也可以自己實現，最主要的還是要有這個意識。
其實我們平常已經寫了一些FP了，只是我們沒意識到，或者沒怎么寫好。就好比閉包，很多人都不了解閉包的概念，但實際上已經寫了很多閉包代碼。其實閉包本身也是函數式編程的一個應用。
鑒于我自己理解也不深，沒法多闡述FP的應用，大家如果有興趣，可以多了解了解。
FP在JavaScript中的優劣勢
總結一下FP的優劣，以便于我們在實際開發中，能更好的抉擇是否采用FP。
優勢
-
更好的管理狀態。因為它的宗旨是無狀態，或者說更少的狀態。而平常DOM的開發中，因為DOM的視覺呈現依托于狀態變化，所以不可避免的產生了非常多的狀態，而且不同組件可能還相互依賴。以FP來編程，能最大化的減少這些未知、優化代碼、減少出錯情況。
-
更簡單的復用。極端的FP代碼應該是每一行代碼都是一個函數，當然我們不需要這么極端。我們盡量的把過程邏輯以更純的函數來實現，固定輸入->固定輸出，沒有其他外部變量影響，并且無副作用。這樣代碼復用時，完全不需要考慮它的內部實現和外部影響。
-
更優雅的組合。往大的說，網頁是由各個組件組成的。往小的說，一個函數也可能是由多個小函數組成的。參考上面第二點，更強的復用性，帶來更強大的組合性。
-
隱性好處。減少代碼量，提高維護性。
劣勢
-
JavaScript不能算是嚴格意義上的函數式語言，很多函數式編程的特性并沒有。比如上文說的數組的惰性鏈求值。為了實現它就得上工具庫，或者自己封裝實現，提高了代碼編寫成本。
-
跟過程式相比，它并沒有提高性能。有些地方，如果強制用FP去寫，由于沒有中間變量，還可能會降低性能。
-
代碼不易讀。這個因人而異，因碼而已。特別熟悉FP的人可能會覺得這段代碼一目了然。而不熟悉的人，遇到寫的晦澀的代碼，看著一堆堆lambda演算跟匿名函數 () => () => () 瞬間就懵逼了。看懂代碼，得腦子里先演算半小時。
-
學習成本高。一方面繼承于上一點。另一方面，很多前端coder，就是因為相對不喜歡一些底層的抽象的編程語言，才來踏入前端坑，你現在又讓他們一頭扎入FP，顯得手足無措。
總結
個人覺得，FP還是好的。對于開發而言，確確實實能優化我們的代碼，熟悉之后，也能提高編程效率。對于編程本身而言，也能拓展我們的思維，不局限在過程式的編程代碼。
在編寫JS中，可以盡量的運用FP的思維，如不可變量、純函數、惰性求值。但也不必教條式的遵循函數式編程，一定要怎樣怎樣。比如我們看下知乎大V某溫的一個回答： 傳送門 。
唉，做個頁面仔不容易啊。但是不想當大牛的頁面仔不是好頁面仔！
參考
來自：https://segmentfault.com/a/1190000009864459