幾個 React Native 的使用隨筆

「React Native 使用分享 — 五年小回顧」投影片：https://revteltech.pse.is/react-native-5-years
React Native 面試常見問題：https://revteltech.pse.is/rn-interview
功能的厚度？ — 從社群登入及推播說起：https://revteltech.pse.is/feature-thickness

React Native/React 顧問：https://consult.revtel.tech/

選用 React Native 做開發有很多好處，不過也常常卡在一些莫名其妙的坑。有些問題可以從 stackoverflow 等地方找到相關討論，但也存在一大堆不太知道去哪找的問題。這時候就很考驗對整個框架及專案的掌握度。

這裡分享幾個常見的問題及可能做法給大家參考。

作業系統升級後常常有問題，該怎麼管理 React Native 版本？

這是個蠻常見問題，尤其在近期 osx 常常有更版的情況下，一升級就無法正確啟動的慘劇時有所聞。更糟糕的是這些問題通常牽連甚廣，你也不容易快速找到解法。如果發生在你正在趕專案的時候，就真的是欲哭無淚。

React Native 的系統架構注定了他的相依性極為複雜，很多東西都要做版本控制，比如：

• 開發工具 — OSX / Windows / Linux 版本
• 目標平台 — Android / iOS 版本
• 相關套件 — nodejs / cocoapods / …

所以適度管理你的開發環境非常重要

建議做法是

1. 版本號相依性請好好的保存，如 package.json、package-lock.json。即使未必一定要在 release 版時鎖死版本號，也請建立流程做版本的控管。
2. 避免在重大發版前進行升級，新版出現後最好是等個十天半個月再說。升級是一件大事，應該視為另一條開發線而不是臨時起意的事情。
3. 升版時如果會擔心不明原因的相沖，可以考慮手動移植不一定要用官方的工具升級。這裏比較探討的是對於不確定性的掌握度高低，在選擇用哪方式升級之前應該先問看看自己「RN 升版的複雜度」及「應用層邏輯」哪個比較好被掌握。

套件這麼多該如何挑選？

套件挑選議題其實也不全然只在 RN 內出現。React Native 有完整的開發生態社群（如 react native comminity），再加上其來脫胎自 Web 體系，通常在模組挑選上面對的不是沒有人做過而是類似的模組太多。

如果挑的不好除了未必能達到想做的事之外，甚至可能對穩定性及後來的開發造成困擾。在這裏我們列幾個原則供您參考

1. 套件健康度
2. 這個部分可以從專案的 star 數量、作者的專案數以及最後一個 commit 的時間是否離現在過久來觀察
3. 套件來源
4. 如果專案的來源是來自比較大的 organization，如 react-native-commnunity 之類，可信度及穩定度就會比較高
5. 程式碼品質
6. 這個部分就必較難評斷，但為了確保萬一有意外自己還能維護，建議開幾隻檔案起來看一下感覺

當然也可以參考像 expo 這些平台提供的建議，可以少走很多彎路。

功能到底該做在 Javascript 層還是 Native 層？

這是一個大哉問，有些時候難免需要撰寫 native module。但同一個功能我們應該實作在 javascript 層還是 native 層呢？

下圖是 React Native 的架構圖，我們可以發現整體架構其實非常複雜。是以對於複雜的邏輯開發，我會建議大家可以盡量在 js 層處理，這樣一來可以沿用如 chrome debugger 等工具協助開發，Native 層盡量單純，這樣對於雙邊的測試會比較方便。

這裡的想法比較是想提出設計架構時，除專注要解決的問題，也要考慮後續維護及開發的成本。畢竟軟體是活的，永遠有機會翻掉重設計，但如果跨大步造成不必要的隱性成本反而得不償失。

當然這個問題沒有一定答案，某知名的加密硬體產品公司就選擇將一些需要隱藏的部分放在 native 層。這裡就真的很看當下的需求跟考量了。

總結

這篇文章只是簡單隨筆，想到哪寫到哪。過往在<功能的厚度？ — 從社群登入及推播說起>也聊過蠻多類似的議題，有興趣的朋友不如參考一下。

開發之路無限長，穩健的拾級而上外是正道啊（欸?)

RevtelTech 忻旅科技 https://www.revtel.tech/

email：[email protected]

facebook：https://www.facebook.com/RevtelTech/