dva使用記錄（三）
遊戲的熱情總歸是要褪去的，最後維持玩家的不過各種遊戲機制或者日常。難得始終如一！
前情回顧：使用記錄的末尾以createStore結束追述到store產生的起點，並敘述了一下redux暴露出來供使用者調用的幾個api，以及這幾個api所起到的作用。
思考：關於redux的使用最初的體會亦如眾多博文中所提到的函數式，不過隨著逐步的了解，從redux又產生出函數式和內存使用的一點概念。去除功能，redux使用了函數的方式在內存中創建了一個空間，好像磁碟分區。並且在這個空間中創建了一個指針並且指向一個對象。不管store在react組件中怎麼傳，但是這個指針始終是指向store的。redux這個大型的閉包實現例子對於解釋閉包對內存的操作是非常的生動的，從初出達內聽到的閉包是為了防止變數污染，到年前超哥提到指針。我們所說的防止變數污染也就是防止指針混亂的操作罷了，深克隆所要解決的也不過是指針的問題。
想一想從上次更新到現在已經過去一個月了，與自己所說的一周一更的偏差稍微有些大了。不過也實屬正常，畢竟就算是對女友也未必會保持每天都以相同的態度對待，哈哈哈。
言歸正傳這一篇主要是接著上一篇的內容寫，說一下createStore的三個參數，雖說三個參數但各自的產生以及如何與store融合確實有很多內容的。下圖是自述redux文檔對於三個參數的解釋，供參考使用
reducer
對於reducer我想如果把redux比作一個電路系統，reducer就是電路系統里的控制器一個開關。store是這個電路系統的結果展示部分燈泡，dispatch是開關的按鈕。這個部分可以是一個函數也可以是一個通過combineReducers函數水合後的函數，單一的函數還比較容易。combineReducers的水合方式還是值得敘說的。下面上圖，附帶的有createStore函數的圖。
這部分代碼比較長分了兩張圖來看，前面的部分我們可以先忽略看第二張圖。這個水合的函數最後返回的還是一個函數並且也是接收一個state和action的函數，這個reducer是一樣的，區別在於這個函數存在一個遍歷，是遍歷去執行每一個reducer。圖二的代碼如果熟悉api以及reducer其實還是很好懂的。那麼肯定會有疑問既然是遍歷那麼怎麼做到通知單個數據樹改變的。這裡就要結合createStore函數的代碼部分理解，並且從這兩個代碼里可以看到一個細節問題，這個會在reducer結束說明一下，也不是什麼大問題注意規範就好。
dispatch通知部分從使用和代碼來看是通過action去通知的，眾所周知一個action里是有一個type和state的，reducer是通過type去判斷更新state的。那上面水合函數的遍歷就好理解了，水合之後返回的函數其實就是dispatch代碼里的currentReducer,遍歷時將action挨個傳入每個reducer只要符合其中一個reducer控制器的判斷就更新這個reducer的state。所以這裡存在一個問題如果存在兩個相同的type值，那樣一次dispatch會同時更改兩個reducer的state，所以我們在dispatch分發時type一定是要不重複的。
initialstate
初始state或恢復state的作用，可述點不是很多所以這裡略過。
enhancer
個人感覺這部分的函數式風格是最重的，在這三個參數的理解上也是最繞的。解釋上很直接的告訴使用者這個是一個增強store介面的函數可以是多個，但是真正看到代碼就會覺得還是有一些繞的，起碼對於目前的我算是很繞的了。我想首先從這個參數的使用來入手或許會好些。
這張圖很直觀的表明將createStore傳入第三參數後返回的是一個函數並且接收reducer和preloadeState。關於增強函數的使用一般是需要放入到compose里融合的，所以compose是產出這個函數的地方。
這段代碼的最底部是融合的關鍵，reduce這個api數組中的累加方法，用於處理前一個元素和後一個元素的，不是很明白可以看一下MDN中關於這個的介紹。
這個部分我看了部分代碼之後有了一點自己的看法不知道對與不對，太過於繞了還是寫出來清晰點。可能會存在錯誤的地方，見諒。
以上是個人關於增強器概念的理解，這部分的的確確是函數式的一個很好體現，每個函數都自稱一個邏輯，而不同函數之間又可以組合形成函數管道。當然這要求函數十分純凈且具有擴展性。然而遺憾的是純凈並不能代表適用性的廣泛。看源碼確實是一種學習處理問題方式的一個便捷方式，這幾次對於源碼的學習對於我自己於函數式的一些理解有了些許加深，同時又在其他方面起到了一點推動的作用。
好像剩下的只有saga部分了！
TAG:小小放映室 |