React Native應用實現步驟

React Native應用實現步驟

 

　　在整個應用設計中，始終按照自下而上的原則進行。在大型的項目中，自下而上的設計方式簡單，能夠並行工做，而且能夠在構建的同時寫測試用例。

React Native設計大致爲五個步驟。

1、應用原型

　　設計各界面的草圖。從主界面開始，處理各類跳轉的關係。

2、基礎組件結構設計

　　原型設計完成後，須要設計每一個界面的React Native基礎組件的分層結構。

2.1 列出全部須要使用的基礎組件

　　首先要作的是從UI界面上找出全部須要使用的基礎組件。基礎組件須要遵循「責任惟一原則」，意思是一個基礎組件只應當負責一個工做。若是一個組件負責多個工做，就應該將這個組件拆分爲多個子組件。

2.2 對基礎組件進行分層

　　對基礎組件進行分層，目的是爲了能使用功能強大的flexbox佈局來實現界面。分層就是把顯示在同一個行區域或者列區域中的多個組件放在同一個view中。

　　開發者須要在界面上畫出一個個方框，每一個方框對應一個flexbox樣式的React Native組件。須要在方框中再畫出小方框，對應組件的子組件，直到沒法畫出更小的方框。這時，就獲得了界面對應的組件分層結構。

2.3 自下而上的設計

　　從UI界面的底部（最基礎的React Native組件）開始構建，每分出的一層組件構成了一個上層React Native組件，直到向上分層到一個界面的根View組件。

3、使用React Native組件搭建靜態界面

　　獲得了組件結構後，就須要搭建React Native組件的靜態界面。

　　這一步只編寫各個界面對應組件的render函數，排列render函數中使用到的基礎React Native組件，生成對應的樣式。在編寫中，開發者會不斷地發如今某個界面中須要填入數據，這就是數據表。若是數據表比較多，則能夠用一個文本文件記錄下來。

4、React Native組件分層

　　靜態界面搭建完成後，開發者須要對React Native組件進行分層。不一樣於基礎組件的分層，React Native組件分層是區分控制React Native組件 與顯示React Native組件的（固然也可能有兩個功能都有的組件）。

4.1 分析界面之間的聯繫

　　若是業務邏輯須要從界面A跳轉到界面B，或者須要把界面A呈現時獲得（用戶輸入或者網絡獲取等）的數據展現在界面B上，咱們就說界面A須要給界面B發送消息。若是界面A須要給界面B發送消息。但界面B不須要給界面A發送消息，那麼在React Native應用設計中，界面B對應的React Native組件應當成爲成爲界面A對應的React Native組件的子組件。若是界面A、B都須要給對方發信息，那麼它們對應的React Native組件就應當有一個共同的父控制組件。

顯示組件與控制組件的分層也是按照自下而上的原則進行的。

4.2 肯定數據的顯示者與擁有者

　　在React Native框架中，數據是沿着組件樹從上到下單向流動。擁有數據的React Native組件不必定負責顯示該數據，它常常把本身擁有的數據（存儲在它的狀態機變量中）做爲一個子組件的屬性傳遞給子組件，由子組件來顯示它。

　　肯定數據的顯示者與擁有者，一樣遵循從下到上的原則。對生成的數據表中的每個數據，找出負責在手機界面上渲染數據的組件，而後判斷該數據是否能夠被該組件的上層擁有。若是能夠（意味着這個數據不會在本組件中被改變），把它丟給上層組件（意味着這個數據由上層組件經過props傳遞下來）；若是不能夠，那麼這個數據可能會是本組件的一個狀態機變量。繼續將這個數據向上丟的過程，直到數據被丟到了最上層或者沒法向上丟了。當這一步完成後，對於每個組件，開發者就獲得了該組件須要使用的屬性表，以及該組件可能擁有的狀態機變量表。

4.3 肯定狀態機變量

　　React Native應用程序工做時，React Native組件接收各類事件，對所接收到的事件的處理可能致使處理結果中的某些數據須要顯示在UI界面上。這些數據能夠成爲該React Native組件的狀態機變量。咱們把他們稱做狀態機變量備選名單。

　　開發者須要對這份名單上的數據作進一步分析，找出重複的數據。重複的數據是指：（1）該數據能夠由備選名單上的其餘數據經過某種規則計算得出；（2）該數據能夠由組件中的數據經過某種規則計算得出；（3）該數據能夠由備選名單上的其餘數據再加上屬性上的某些數據按某種規則計算得出。

把這些重複的數據踢出備選名單，就獲得了一個狀態機變量的最小集。

4.4 肯定各事件的接收者與處理者

　　對上一步獲得的事件列表中的每個事件，肯定其處理者。

　　若是事件是在上層處理的，那麼把事件丟給上層組件（意味着上層須要提供給事件接收層一個回調函數，而且把這個回調函數做爲屬性傳給負責接收事件的組件）。在上層組件中寫出這個回調函數的原型，而且將它傳遞到下層組件，下層組件再將它與按鈕的按下事件掛上鉤。

　　若是事件是由本層組件處理的，那麼寫出這個處理函數的原型。

　　繼續這個過程，直到每一個事件都被丟到了負責處理它的組件，而且實現了該事件的處理函數原型。

4.5 非界面出發事件的接收者與處理者

　　非界面出發事件，是指不能由React Native基礎組件（React Native框架提供的組件稱爲React Native基礎組件）上報的事件。好比各類監聽事件（Android手機後退鍵監聽、混合開發原生代碼測消息監聽等）、定時器事件等。

　　首先須要肯定這些事件的接收者在React Native組件分層結構中的位置。思路是：觀察分析某個事件會形成哪些React Native組件（每一個組件表明一個界面）被改變，將這些React Native組件當作一個樹形結構（可能須要補充某些控制React Native組件），將接收者肯定爲這個樹形結構的最高節點，而後讓這個事件被觸發的消息按業務邏輯處理，在這個樹形結構中經過屬性從上到下流動。

5、實現各組件業務邏輯

　　各組件的屬性、狀態機變量定型後，就能夠實現各組件業務邏輯了。在實現業務邏輯的過程當中，有可能須要給某組件增長成員變量、成員方法等。業務邏輯包括但不限於：

5.1 直接渲染狀態機變量和屬性

　　在各組件的render函數的相應位置填入狀態機變量和屬性名稱。

5.2 將狀態機變量以屬性的方法交給下層組件

　　不少組件的狀態機變量是由其子組件負責顯示的，須要經過屬性將狀態機變量傳給子組件。在render函數的子組件聲明中添加對屬性的賦值語句，實現狀態機變量的傳遞。

5.3 實現狀態機變量的其餘業務控制邏輯

　　某些狀態機變量是用來進行業務邏輯控制的。好比說，聲明一個狀態機變量來控制當前顯示哪個界面。