從網頁到 App— 從 React 到 React Native 的奇幻旅程
什麼是 React Native？
Learn once, write anywhere. — React Native
React Native 是 Facebook 所維護的開源跨平台 app 框架，並基於 React。至今已有許多公司使用在 production app 上，例如： facebook, instagram, Uber, pinterest, wix ……。相反的，也有公司採用然後棄用的例子，Airbnb 在 2018 年宣布棄用 React Native。
在我們團隊內而言，由於原本是以 React 為網頁開發框架，因此採用 React Native 作為 App 開發框架是最容易且節省成本的選擇，React Native 確實幫助我們解決了問題，也讓我們遇到了新的問題，也讓我們明白跨平台開發解決方案的極限，何時該採用？何時則不。
在這篇文章中將會分享我們採用 React Native 開發 App 之後至今所遇到的問題以及心得。
在採用 React Native 前，你可能會想知道…
你可以「Learn once, write anywhere」但無法「Write once, run anywhere」
React Native 讓開發者可以使用 Javascript render Native component，但由於不同平台的 Native component 會有不同的 API、外觀，因此由於系統設計風格的不同，透過 React Native render 的 component 在雙平台上外觀大部分不會一模一樣。在介面的還原度上，Flutter 由於沒有使用 native bridge，所以可以有更完整的還原度，這算是兩個框架技術策略上的不同。
同時，React Native 也會存在只能在部分平台使用的參數設置。透過 React Native 可以加速雙平台的開發，但他不保證雙平台都能如你預期的運作，如果你在意細節，在兩個平台上使用不同的樣式以及參數可能會是必須的。你無法「Write once, run anywhere」。
React Native 有豐富的生態和函式庫，但它們可能並不可靠
特別是當函式庫不是完全由 javascript 寫成，相比於 React 的第三方函式庫，React Native 的第三方函式庫有更大的機會出錯。
因為要完成一個 React Native 的函式庫並不容易，多數時候，這代表函式庫作者、貢獻者必須對 React Native, Android, iOS 三種平台開發都至少有中等程度的了解，這是跨平台框架的原罪。
但這也不是致命的錯誤，因為大多錯誤發生在細節，或是特定的版本、使用情境，只要你有心理準備當出錯時去 fork 這些函式庫，你可以自己把它修好，讓它在你的使用情境下正常運作就可以了。
React Native 的錯誤訊息讓人困惑：Write once, Debug anywhere
比較致命的錯誤在於，錯誤訊息有時會讓開發者不明白發生了什麼事，無法閱讀的 callstack 與 error message 會讓人搞不清楚，究竟是我寫的程式碼出錯、函式庫出錯、React Native 出錯、還是 Native 出錯？太多地方可以出錯了，我該如何修正這個 bug？最後我們通常只能把 error message 貼上 google 尋求解方。
模擬器無法模擬實際狀況，你需要準備測試用的裝置
雖然 Android emulator 跟 iOS simulator 都可以模擬運作程式，但有時他們的行為會跟實際機器有所不同，而當你需要測試硬體相關的功能時，例如：相機、藍芽，你會需要實體的測試用機器。
給 React 開發者的建議
一開始建議從 React Native 官方的 getting start 開始，他們寫了相當清楚的文件。如果沒有套件相依的問題，建議採用最新版本的 React Native 以確保安全性與可以享用最新的功能，因為開始開發之後再升級會需要處理更多套件相依的問題。
先了解 React Native 提供的 Component
React Native 提供了許多現成、功能強大的 component，活用他們可以省下許多時間。
例如：
FlatList可以創造一個效能好的 list，是一個幾乎每個 App 都會使用到的 component，並且提供了pull to refresh的實作。- 使用
SafeAreaView作為 container，可以避免畫面中的 component 出現在裝置中不可見的區域（例如 iPhone X 的瀏海）。 - 使用
ActivityIndicator作為載入時的符號。
Native Base
除了 React Native 內建提供的 component 以外，NativeBase 提供了更多更強大（也更複雜）的 component ，同時，也提供了一個可以客製化參數的設計系統，讓開發者可以更容易打造一個有風格的 App。
React Navigation
大部分的 App 會需要換頁，在 React Native 的介紹上推薦了 React Navigation 與 React Native Navigation。如果你傾向直覺使用的 API，可以使用前者。如果你想要在雙平台都有 Native 的體驗，可以選擇後者。
React Native 的優點？
雖然在上方說了許多 React Native 的缺點，但 React Native 作為一個跨平台解決方案，仍舊提供了許多優點：
- 承襲了部分 css 的樣式系統
在 React Native，你可以使用很接近於 CSS 的語法給予元件樣式，這對於有 CSS 經驗的人來說， 可以說是一大福音。
2. 承襲了 React 的優點
包含宣告式的 API、元件化開發、virtual DOM 一直到最近發布的 react hook。React Native 承襲了 React 的優點，讓編寫規模化的 UI 系統更加簡潔、容易維護．
3. Fast refresh
當你修改了 React Native component 的樣式，React Native 提供了近乎馬上更新，讓你可以即時觀看成果，修改程式碼，加速了程式碼的開發。
什麼樣的情況下適合用 React Native 開發
然而，React Native 這樣的跨平台解決方案並不適合每一種專案，在我們的經驗中，當專案具有以下幾種特質時，採用 React Native 可以減少程式碼與開發成本：
- App 沒有串接相機、藍芽、麥克風、陀螺儀等等系統硬體 API 需求
也就是說，你的 App 非常接近於網頁時，使用 React Native 開發時會更加容易，因為當你串接不同系統硬體 API （或者函式庫），有兩種平台、X 種版本與 Y 種機型，這些的組合就是五花八門的問題。
2. 專案在意在時程、人力限制內交付產品，更勝於 Pixel perfect
React Native 可以快速打造出 App，但是在雕琢細節上需要花費許多功夫，更適合用在需要快速打造出的試驗性產品、產品原型。
React Native 是一個仍在持續發展中的框架，也有十分熱絡的社群，如果你理解他的長處與短處之後，他會是一個相當強大的工具。
