React Native搭建簡單的項目框架

React Native搭建簡單的項目框架

React Native 是Facebook于2015年4月開源的跨平臺移動應用開發框架, 短短的一兩年的發展就已經有很多家公司支持并采用此框架來搭建公司的移動端的應用,
React Native使你能夠在Javascript和React的基礎上獲得完全一致的開發體驗,構建世界一流的原生APP。

雖然可能沒有說的那么厲害,但是我們不可否認,它在統一移動端開發和前端上開發做了很大貢獻.React Native雖然使用的是javaScript語言搭建頁面和邏輯等 但是其編譯之后則會轉化為安卓或者蘋果的原生語言,從而即達到了一種語言 多端使用 同時也基本有了原生的流暢體驗,因為其在渲染方面已經不是在web瀏覽器上面,而是真正的做到了渲染原生的圖層或者控件這些, 當然 因為語言的轉化, 其肯定在內存上或者在性能上是不可能100%和原生做到完全一致的體驗的,同時,因為跨語言的性質,也并不是所有功能都僅僅使用javaScript就可以完成了,部分時候我們還是需要原生框架的支持

但是這一起并不能掩蓋這門移動開發框架的優秀.
大廠的支持,健壯的交流社區,足夠多的開源和開發者的支持,使得其發展的很是迅速.
很多公司局部采用甚至是全部采用此框架來構建自己公司的移動應用.
那么到底是前端人員學習此框架簡單呢?還是移動端人員學習此框架簡單呢?

如果你搜索網上的評論 可能很多人都會說是前端人員轉入簡單,因為語言學習成本為0,直接參照網上或者官方的教程即可簡單搭建,迅速上手.
我本人是前端也做,移動端也做,且都有不少的開發經驗,
我的觀點卻和他們不同.
首先,不可否認對于前端開發人員來說,直接能夠上手絕對是最簡單的,但是很多人卻沒有考慮,移動端的各種系統的復雜性,移動端開發的各種限制,各種規范...這些對于前端人員來說是缺少的,前端人員很容易的搭建好界面, 但是對于很多復雜的移動開發需求,比如某些硬件類,如藍牙,wifi等 比如某些復雜的框架類,如地圖,如支付,如內購等等這些.此外還有安卓和iOS的差異性導致的某些限制.前端在多線程上面的丟失... 這些都會是一個一個坑等著去填.前端人員能夠迅速的完成界面需求,不可否認,但是當涉及多框架部分或者原生必須支持的時候,就無能為力了,他們去學習iOS?去學習安卓?顯然這個時候更難學習,
簡單的舉一個我在開發中的例子,我與我的朋友都有做過RN的項目 不同的是他只有前端經驗. 于是我們在做項目的時候 我則會考慮多的是性能的優化 ,比如圖片的緩存和異步加載這些.而我的朋友則不會,于是我們同樣寫的一個列表, 我能夠做到盡可能的性能優化,他則會在加載幾百或者上千行就會卡頓的不行
再從移動端角度來說, 移動端的開發人員或多或少的都是有做過簡單的web開發,有的甚至都是學習過前端語言的 html css javaScript 對于任何一個開發人員都不陌生 ,可能不會熟練的寫,但是絕對是能夠閱讀的(當然這里只是簡單的來說,并不是說都精通那些前端框架什么的)
什么vue 什么react 什么angular這些前端框架或許本質很復雜 但是如果開發的方向不是web而是app則不一樣.React Native作為用來開發移動端的框架,其已經抽象出來和簡化了很多多余的不需要的部分, 對于移動端開發人員來說 , 只需要學習一周或者兩周的時間便可以上手React Native的開發,而不會明顯的不適應前端語言,同時作為移動端的開發人員,也有了前端所沒有的開發優勢,此時反而更快的加入開發的隊伍中

說了這么多,都是我個人對于React Native的認知,僅作為參考意見,持有不通觀點也不必要反駁.各持己見而已.

說這么多其實都已經離題很遠了.
一句話拉回來,無論是前端還是移動端,想要開始React Native如何搭建簡單的項目框架呢?
我們可能會從官網上或者中文網上學習如何初始化一個項目

react-native init AwesomeProject
cd AwesomeProject
react-native run-[ios | android]

我們能夠得到只有一個歡迎頁面的APP
那么我們如何以最快的速度搭建有骨架的APP?
這里我簡單的介紹我們需要的兩個庫
一個管理界面跳轉和層級(React Navigation)
https://reactnavigation.org/
一個管理數據傳遞和更新(Redux)
http://www.redux.org.cn/

這里當然只是推薦這兩個庫,并不是說必須要求這兩個庫,
我在這里也只是借這兩個庫來完成我們需要的界面邏輯和數據和行為的綁定

首先一個標準的APP肯定是有很多界面之間的跳轉的,而為這些跳轉邏輯的route
這部分對于前端來說就類似于以前的window.location.herf='xxx'.在移動端就類似于navigation的push xxx.
因為一般的app都是按照既定的跳轉邏輯 最熟悉熟悉的 概要->列表->詳情
那么我們就需要使用react-navigation來完成這樣的路由邏輯
我們可能會分別寫出Home.js 和Detail.js來表示兩個頁面


這里寫圖片描述

這里寫圖片描述

于是我們采用React Navigation的StackNavigator完成導航路由的構建


這里寫圖片描述

于是我們就完成了一個簡單的首頁和詳情模塊之間的跳轉邏輯
當然我們可能還有其他的模塊, 比如個人信息模塊
同理的創建好個人信息模塊所需要的頁面之后我們按照相同的方式添加,我們可以完成第二個模塊的搭建,但是一般的APP首頁肯定是多個tab選項卡可以切換不同模塊的方式
此時我們就用到了新的TabNavigator組件


這里寫圖片描述

如此一個簡單的界面邏輯的跳轉就完成了,我們只需要在響應的添加子模塊的內容和各個界面的關系即可


這里寫圖片描述

這里寫圖片描述

頁面跳轉部分已經完成,那么接下來就是數據管理部分
當然此部分我們可以也可以直接跳過,我們可以采用react自帶state和props來完成
如果不理解或者不熟悉 我們可以參考
http://www.runoob.com/react/react-props.html
至于我為什么又推薦redux來管理數據呢?
Redux 是 JavaScript 狀態容器,提供可預測化的狀態管理,
可以讓你構建一致化的應用,運行于不同的環境(客戶端、服務器、原生應用),并且易于測試.
這是官描 不用管.但是redux是有一個好處的,就是數據和行為與界面分離,原先我們寫一個界面可能會有很多的業務邏輯在其中,使得界面的構造很臃腫,類似于我們mvc中的c的部分,包含的內容不僅有界面的展示 也有很多邏輯部分,比如界面的刷新邏輯,數據的處理邏輯.
我們因此需要分離出action和對應的數據處理部分,所以我推薦redux ,當然如果是小的應用或者簡單的應用就沒有必要了,本身邏輯不復雜,沒有必要舍近求遠.
redux的使用,這里的話算是一個難點

這里寫圖片描述

redux的理念是所有的數據狀態都統一交給一個store來管理,同時當state變化的時候也是有其告知給界面,界面重新渲染數據,而不是每一個界面自己管理數據
如此的好處是,我們可能會省掉很多的界面傳值,回調,通知,監聽等等復雜的數據綁定
首先store中有一個唯一的state作為全局的數據源 同時其有一個dispatch分發方法,負責將我們定義的action和一些動態數據傳輸發送到reducer中,reducer則根據原先的state和action來判斷是否需要更新新的state,重新返回給store, 當state發生變化的時候,store則會告知界面去重新渲染,
如此完成一個循環,這樣所有的界面邏輯就按成了.
行為和數據處理從界面分離出去之后,原來的界面變的就好像是之前的列表中的item,僅僅起到的就是一個類似展示的作用.這樣的好處,即使是界面的樣式或者行為變更了,只需要修改響應的部分,而不需要在原來的某一個界面中改來改去,
至于redux的教程,建議學習官方
http://www.redux.org.cn/

至此,一個簡單應用的兩個大的部分就組合完畢,我們可以輕松的完成界面的搭建和跳轉,我們也可以優雅的處理所有的行為和數據更新的邏輯

這里我提供一份demo 是提取自一個已有項目的
我僅僅抽取出來這兩部分,作為一個應用的基礎腳手架來給你們參考
https://github.com/spicyShrimp/react-navigation-redux

當然,如果你想要學習一個完整的應用或者學習一點更復雜的部分,
我最近的一個仿寫項目足夠滿足你


這里寫圖片描述

https://github.com/spicyShrimp/Misses

也感謝大家的支持,當然移動端或者前端的問題都可以找我...

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,412評論 6 532
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,514評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,373評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,975評論 1 312
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,743評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,199評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,262評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,414評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,951評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,780評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,983評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,527評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,218評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,649評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,889評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,673評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,967評論 2 374

推薦閱讀更多精彩內容