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