title: 亂花漸欲迷人眼,返璞歸真F8(1)
date: 2017-04-05 10:00:23
categories: F8App源碼閱讀
tags: React-native
去年寫了幾篇f8app的代碼閱讀,基本是站在UI組件的角度來的,隨著學習的深入,對其中的代碼有了更深的體會,現在有很多開源的RN項目可以供參考,但是有一些都存在某些問題.細節考慮的不周到,學習的意義打了折扣.F8APP是facebook的親兒子,所以開發者的水平是很高的,前面閱讀的時候覺得怎么寫的很難懂,甚至還有些地方對Redux的實現都感覺不太標準,這兩天回頭看的時候,不得不佩服人家的開發水平.代碼里對于組件的實現,Redux的滲透,多數據源的接入,代碼組織方面都是獨居匠心的.我自從重新閱讀了以后,感覺寫代碼當如此啊.
但是到了現在的這個覺悟并不是一蹴而就的.經過一段時間的學習,學習工具箱里就有一些工具了.
函數式編程的思想,javascript里的函數是一等對象,其實意思是函數和對象在javascript中都是
引用賦值的
,這一點非常的非常的關鍵.這并非危言聳聽,一旦你在讀代碼中有了這個覺悟的話,javascript的功力會大增的.我們隨時可以把一個函數映射到一個變量上,這就是引用賦值,一旦這樣做以后,函數可以使用這個變量在代碼中傳來傳去,靈活性大增.有沒有思考過React/Redux中組件dispatch一個action到底發生了什么?bindActionCreator是怎么實現的?這還沒完,繼續挖掘函數編程是怎么在f8里實現的模式設計的思想:中介者模式,發布訂閱者模式,等等模式,在這面也很好的實現了。要有一點模式設計的知識
React-native跨平臺開發的代碼復用問題,功能,邏輯和表現形式的結合思考。先邏輯后表現。
臨機應變,剛開始看f8app的代碼的時候看不下去,尤其是在對redux有了初步的了解,產生盲目崇拜以后,在React中必須要找到幾個文件夾在才能是根正苗紅的Redux應用.于是在里面找,這里面更本就沒有container文件夾么?怎么辦?其實在container文件中也只是用connect對象注入了組件是組件訂閱了需要的props,具有了dispatch方法.僅此而已.所以在f8app中直接在UI組件中使用了connect對象.這樣對于編碼實際更好操作,更直觀.另外帶來的好處是,組價其實不一定非要用redux來處理,可以使用其他的框架來處理.info這個模塊就沒有采用redux的框架.要從功能上靈活處理。能達到隨機應變要對功能的實現有深刻的認識。
對于state的思考,后面如果要繼續提高RN的編程能力,要不斷的思考state的問題.目前看到的兩個大型程序的state,一個是f8的,一個是cnode的state.
我前面寫過文章把state看成是內存的數據庫,圍繞著state做增刪改查工作,是不是這個意思呢?f8中的state實現是一顆倒立的樹,為什么是樹呢?這是相對于網狀結構來的,state中是沒有之間的連接關系的.數據以節點來組織.看到f8app中combineReducer中的映射的時候,那感覺真爽啊。編程真有意思.回頭看代碼在解釋.parse-server和graghql的問題,
觀察的視點選擇問題,如果會你看過這篇文章,中文翻譯版的話,這篇文章實際是從UI組件的角度來找視點的,對于初學者倆說,這篇文章的確是很好的,但是對于F8app這樣的大型app,從視圖就有點喧賓奪主了.在f8app中state和Actions的復雜程度更高,從組件上面去學習就有點麻煩,尤其是這里面有幾個地方的組件組合真的是太厲害了,看完組件的組合關系就已經沒耐心了.從action和state開始讀似乎是可行的.當然因人而異.我提出這個觀點至少是說明我思考過這個問題.
貪心原理 f8APP中已經包含和了很多組件和中間件了,多學幾遍就可以在其他地方用了.太好了.
時間太晚了,有些地方白天想明白了,現在又忘了.先寫這么多.