React Native搭建簡(jiǎn)單的項(xiàng)目框架
React Native 是Facebook于2015年4月開源的跨平臺(tái)移動(dòng)應(yīng)用開發(fā)框架, 短短的一兩年的發(fā)展就已經(jīng)有很多家公司支持并采用此框架來(lái)搭建公司的移動(dòng)端的應(yīng)用,
React Native使你能夠在Javascript和React的基礎(chǔ)上獲得完全一致的開發(fā)體驗(yàn)断序，構(gòu)建世界一流的原生APP屈呕。
雖然可能沒(méi)有說(shuō)的那么厲害,但是我們不可否認(rèn),它在統(tǒng)一移動(dòng)端開發(fā)和前端上開發(fā)做了很大貢獻(xiàn).React Native雖然使用的是javaScript語(yǔ)言搭建頁(yè)面和邏輯等 但是其編譯之后則會(huì)轉(zhuǎn)化為安卓或者蘋果的原生語(yǔ)言,從而即達(dá)到了一種語(yǔ)言 多端使用 同時(shí)也基本有了原生的流暢體驗(yàn),因?yàn)槠湓阡秩痉矫嬉呀?jīng)不是在web瀏覽器上面,而是真正的做到了渲染原生的圖層或者控件這些, 當(dāng)然 因?yàn)檎Z(yǔ)言的轉(zhuǎn)化, 其肯定在內(nèi)存上或者在性能上是不可能100%和原生做到完全一致的體驗(yàn)的,同時(shí),因?yàn)榭缯Z(yǔ)言的性質(zhì),也并不是所有功能都僅僅使用javaScript就可以完成了,部分時(shí)候我們還是需要原生框架的支持
但是這一起并不能掩蓋這門移動(dòng)開發(fā)框架的優(yōu)秀.
大廠的支持,健壯的交流社區(qū),足夠多的開源和開發(fā)者的支持,使得其發(fā)展的很是迅速.
很多公司局部采用甚至是全部采用此框架來(lái)構(gòu)建自己公司的移動(dòng)應(yīng)用.
那么到底是前端人員學(xué)習(xí)此框架簡(jiǎn)單呢?還是移動(dòng)端人員學(xué)習(xí)此框架簡(jiǎn)單呢?
如果你搜索網(wǎng)上的評(píng)論 可能很多人都會(huì)說(shuō)是前端人員轉(zhuǎn)入簡(jiǎn)單,因?yàn)檎Z(yǔ)言學(xué)習(xí)成本為0,直接參照網(wǎng)上或者官方的教程即可簡(jiǎn)單搭建,迅速上手.
我本人是前端也做,移動(dòng)端也做,且都有不少的開發(fā)經(jīng)驗(yàn),
我的觀點(diǎn)卻和他們不同.
首先,不可否認(rèn)對(duì)于前端開發(fā)人員來(lái)說(shuō),直接能夠上手絕對(duì)是最簡(jiǎn)單的,但是很多人卻沒(méi)有考慮,移動(dòng)端的各種系統(tǒng)的復(fù)雜性,移動(dòng)端開發(fā)的各種限制,各種規(guī)范...這些對(duì)于前端人員來(lái)說(shuō)是缺少的,前端人員很容易的搭建好界面, 但是對(duì)于很多復(fù)雜的移動(dòng)開發(fā)需求,比如某些硬件類,如藍(lán)牙,wifi等 比如某些復(fù)雜的框架類,如地圖,如支付,如內(nèi)購(gòu)等等這些.此外還有安卓和iOS的差異性導(dǎo)致的某些限制.前端在多線程上面的丟失... 這些都會(huì)是一個(gè)一個(gè)坑等著去填.前端人員能夠迅速的完成界面需求,不可否認(rèn),但是當(dāng)涉及多框架部分或者原生必須支持的時(shí)候,就無(wú)能為力了,他們?nèi)W(xué)習(xí)iOS?去學(xué)習(xí)安卓?顯然這個(gè)時(shí)候更難學(xué)習(xí),
簡(jiǎn)單的舉一個(gè)我在開發(fā)中的例子,我與我的朋友都有做過(guò)RN的項(xiàng)目 不同的是他只有前端經(jīng)驗(yàn). 于是我們?cè)谧鲰?xiàng)目的時(shí)候 我則會(huì)考慮多的是性能的優(yōu)化 ,比如圖片的緩存和異步加載這些.而我的朋友則不會(huì),于是我們同樣寫的一個(gè)列表, 我能夠做到盡可能的性能優(yōu)化,他則會(huì)在加載幾百或者上千行就會(huì)卡頓的不行
再?gòu)囊苿?dòng)端角度來(lái)說(shuō), 移動(dòng)端的開發(fā)人員或多或少的都是有做過(guò)簡(jiǎn)單的web開發(fā),有的甚至都是學(xué)習(xí)過(guò)前端語(yǔ)言的 html css javaScript 對(duì)于任何一個(gè)開發(fā)人員都不陌生 ,可能不會(huì)熟練的寫,但是絕對(duì)是能夠閱讀的(當(dāng)然這里只是簡(jiǎn)單的來(lái)說(shuō),并不是說(shuō)都精通那些前端框架什么的)
什么vue 什么react 什么angular這些前端框架或許本質(zhì)很復(fù)雜 但是如果開發(fā)的方向不是web而是app則不一樣.React Native作為用來(lái)開發(fā)移動(dòng)端的框架,其已經(jīng)抽象出來(lái)和簡(jiǎn)化了很多多余的不需要的部分, 對(duì)于移動(dòng)端開發(fā)人員來(lái)說(shuō) , 只需要學(xué)習(xí)一周或者兩周的時(shí)間便可以上手React Native的開發(fā),而不會(huì)明顯的不適應(yīng)前端語(yǔ)言,同時(shí)作為移動(dòng)端的開發(fā)人員,也有了前端所沒(méi)有的開發(fā)優(yōu)勢(shì),此時(shí)反而更快的加入開發(fā)的隊(duì)伍中
說(shuō)了這么多,都是我個(gè)人對(duì)于React Native的認(rèn)知,僅作為參考意見,持有不通觀點(diǎn)也不必要反駁.各持己見而已.
說(shuō)這么多其實(shí)都已經(jīng)離題很遠(yuǎn)了.
一句話拉回來(lái),無(wú)論是前端還是移動(dòng)端,想要開始React Native如何搭建簡(jiǎn)單的項(xiàng)目框架呢?
我們可能會(huì)從官網(wǎng)上或者中文網(wǎng)上學(xué)習(xí)如何初始化一個(gè)項(xiàng)目
react-native init AwesomeProject
cd AwesomeProject
react-native run-[ios | android]
我們能夠得到只有一個(gè)歡迎頁(yè)面的APP
那么我們?nèi)绾我宰羁斓乃俣却罱ㄓ泄羌艿腁PP?
這里我簡(jiǎn)單的介紹我們需要的兩個(gè)庫(kù)
一個(gè)管理界面跳轉(zhuǎn)和層級(jí)(React Navigation)
https://reactnavigation.org/
一個(gè)管理數(shù)據(jù)傳遞和更新(Redux)
http://www.redux.org.cn/
這里當(dāng)然只是推薦這兩個(gè)庫(kù),并不是說(shuō)必須要求這兩個(gè)庫(kù),
我在這里也只是借這兩個(gè)庫(kù)來(lái)完成我們需要的界面邏輯和數(shù)據(jù)和行為的綁定
首先一個(gè)標(biāo)準(zhǔn)的APP肯定是有很多界面之間的跳轉(zhuǎn)的,而為這些跳轉(zhuǎn)邏輯的route
這部分對(duì)于前端來(lái)說(shuō)就類似于以前的window.location.herf='xxx'.在移動(dòng)端就類似于navigation的push xxx.
因?yàn)橐话愕腶pp都是按照既定的跳轉(zhuǎn)邏輯 最熟悉熟悉的 概要->列表->詳情
那么我們就需要使用react-navigation來(lái)完成這樣的路由邏輯
我們可能會(huì)分別寫出Home.js 和Detail.js來(lái)表示兩個(gè)頁(yè)面
于是我們采用React Navigation的StackNavigator完成導(dǎo)航路由的構(gòu)建
于是我們就完成了一個(gè)簡(jiǎn)單的首頁(yè)和詳情模塊之間的跳轉(zhuǎn)邏輯
當(dāng)然我們可能還有其他的模塊, 比如個(gè)人信息模塊
同理的創(chuàng)建好個(gè)人信息模塊所需要的頁(yè)面之后我們按照相同的方式添加,我們可以完成第二個(gè)模塊的搭建,但是一般的APP首頁(yè)肯定是多個(gè)tab選項(xiàng)卡可以切換不同模塊的方式
此時(shí)我們就用到了新的TabNavigator組件
如此一個(gè)簡(jiǎn)單的界面邏輯的跳轉(zhuǎn)就完成了,我們只需要在響應(yīng)的添加子模塊的內(nèi)容和各個(gè)界面的關(guān)系即可
頁(yè)面跳轉(zhuǎn)部分已經(jīng)完成,那么接下來(lái)就是數(shù)據(jù)管理部分
當(dāng)然此部分我們可以也可以直接跳過(guò),我們可以采用react自帶state和props來(lái)完成
如果不理解或者不熟悉 我們可以參考
http://www.runoob.com/react/react-props.html
至于我為什么又推薦redux來(lái)管理數(shù)據(jù)呢?
Redux 是 JavaScript 狀態(tài)容器鸠按，提供可預(yù)測(cè)化的狀態(tài)管理,
可以讓你構(gòu)建一致化的應(yīng)用，運(yùn)行于不同的環(huán)境（客戶端侥祭、服務(wù)器、原生應(yīng)用）尊勿，并且易于測(cè)試.
這是官描 不用管.但是redux是有一個(gè)好處的,就是數(shù)據(jù)和行為與界面分離,原先我們寫一個(gè)界面可能會(huì)有很多的業(yè)務(wù)邏輯在其中,使得界面的構(gòu)造很臃腫,類似于我們mvc中的c的部分,包含的內(nèi)容不僅有界面的展示 也有很多邏輯部分,比如界面的刷新邏輯,數(shù)據(jù)的處理邏輯.
我們因此需要分離出action和對(duì)應(yīng)的數(shù)據(jù)處理部分,所以我推薦redux ,當(dāng)然如果是小的應(yīng)用或者簡(jiǎn)單的應(yīng)用就沒(méi)有必要了,本身邏輯不復(fù)雜,沒(méi)有必要舍近求遠(yuǎn).
redux的使用,這里的話算是一個(gè)難點(diǎn)
redux的理念是所有的數(shù)據(jù)狀態(tài)都統(tǒng)一交給一個(gè)store來(lái)管理,同時(shí)當(dāng)state變化的時(shí)候也是有其告知給界面,界面重新渲染數(shù)據(jù),而不是每一個(gè)界面自己管理數(shù)據(jù)
如此的好處是,我們可能會(huì)省掉很多的界面?zhèn)髦?回調(diào),通知,監(jiān)聽等等復(fù)雜的數(shù)據(jù)綁定
首先store中有一個(gè)唯一的state作為全局的數(shù)據(jù)源 同時(shí)其有一個(gè)dispatch分發(fā)方法,負(fù)責(zé)將我們定義的action和一些動(dòng)態(tài)數(shù)據(jù)傳輸發(fā)送到reducer中,reducer則根據(jù)原先的state和action來(lái)判斷是否需要更新新的state,重新返回給store, 當(dāng)state發(fā)生變化的時(shí)候,store則會(huì)告知界面去重新渲染,
如此完成一個(gè)循環(huán),這樣所有的界面邏輯就按成了.
行為和數(shù)據(jù)處理從界面分離出去之后,原來(lái)的界面變的就好像是之前的列表中的item,僅僅起到的就是一個(gè)類似展示的作用.這樣的好處,即使是界面的樣式或者行為變更了,只需要修改響應(yīng)的部分,而不需要在原來(lái)的某一個(gè)界面中改來(lái)改去,
至于redux的教程,建議學(xué)習(xí)官方
http://www.redux.org.cn/
至此,一個(gè)簡(jiǎn)單應(yīng)用的兩個(gè)大的部分就組合完畢,我們可以輕松的完成界面的搭建和跳轉(zhuǎn),我們也可以優(yōu)雅的處理所有的行為和數(shù)據(jù)更新的邏輯
這里我提供一份demo 是提取自一個(gè)已有項(xiàng)目的
我僅僅抽取出來(lái)這兩部分,作為一個(gè)應(yīng)用的基礎(chǔ)腳手架來(lái)給你們參考
https://github.com/spicyShrimp/react-navigation-redux
當(dāng)然,如果你想要學(xué)習(xí)一個(gè)完整的應(yīng)用或者學(xué)習(xí)一點(diǎn)更復(fù)雜的部分,
我最近的一個(gè)仿寫項(xiàng)目足夠滿足你
https://github.com/spicyShrimp/Misses
也感謝大家的支持,當(dāng)然移動(dòng)端或者前端的問(wèn)題都可以找我...
