前言

最後一篇來提到一些上架以後還要持續進行的維護，例如：盡量保持著 React Native 的更新，不至於落後太多。

升級 React Native

React Native 雖然開發快速方便，但這個新穎的技術這兩年一直是用不可思議的速度在往前邁進，之前兩個禮拜發布一次新版，2016 年 12 月開始的 v0.40.0 變成每個月發佈一次，快速的版本升級對於開發者與套件開發者都是很大的負擔，也不是每個版本的升級都能很順利。

v0.40.0 有一個 iOS native headers moved 的 Breaking Change 會影響幾乎所有的 Native 套件，升級要特別注意。

以往的升級方式

以往是使用 react-native upgrade 來升級：

$ npm install --save react-native@latest
$ react-native upgrade

這背後是使用 rn-diff 來更新，在處理衝突時必須完全人工去比對，如果能使用下面這個新方法的話就不會再使用舊的方式。

使用 git 來升級

2016 年 12 月，React 發佈了使用 git 來 升級的新方法。

安裝

要安裝全域的 react-native-git-upgrade：

$ npm install -g react-native-git-upgrade

或是

$ yarn global add react-native-git-upgrade

直接更新到最新版本

預設不給任何參數就是瞄準 latest 的 React Native：

$ react-native-git-upgrade

更新到版本 X.Y.Z

$ react-native-git-upgrade X.Y.Z

解決衝突

只要是跟 React Native 核心團隊開發到一樣的地方，就很有可能發生升級時的衝突，尤其是在 Native 跟 iOS、Android 套件設定檔的部分最容易發生這些問題。

因為用 git 來做合併的處理，所以遇到衝突的時候解決的方式就跟平常用 git 是一樣的，例如以下的部分：

13B07F951A680F5B00A75B9A /* Release */ = {
  isa = XCBuildConfiguration;
  buildSettings = {
    ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
<<<<<<< ours
    CODE_SIGN_IDENTITY = "iPhone Developer";
    FRAMEWORK_SEARCH_PATHS = (
      "$(inherited)",
      "$(PROJECT_DIR)/HockeySDK.embeddedframework",
      "$(PROJECT_DIR)/HockeySDK-iOS/HockeySDK.embeddedframework",
    );
=======
    CURRENT_PROJECT_VERSION = 1;
>>>>>>> theirs
    HEADER_SEARCH_PATHS = (
      "$(inherited)",
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include,
      "$(SRCROOT)/../node_modules/react-native/React/**",
      "$(SRCROOT)/../node_modules/react-native-code-push/ios/CodePush/**",
    );

就用人工的方式看一下 <<<<<<< ours 跟 >>>>>>> theirs 中間要如何取捨就好了。

這部分也可以參考官方的 Upgrading Guide。

寫在最後的最後

當初在選題目的時候想了許久，原先有不少的一些選擇：

• 三十天學 Rx
• 三十天學 GraphQL
• 三十天做一個開源的 JavaScript ORM (使用 Flowtype & Async Function)
• 三十天用 React Native 做一個 App

除了希望題目不會太冷門、希望不會完全流於教學沒有實作、希望不會有太大的負擔，最重要的還是希望能學到東西並寫出一些自己不寫就不會存在的文章，最後折衷的作出了用 React Native、GraphQL 做開源 App 的決定。

三十天說長不長說短不短，這個題目對我來說相當的有挑戰性，雖然 React 已經很熟悉，但很多 React Native 的題目則是要當天摸當天寫出心得與教學。現代的技術開發並不是參考十年不變的教科書，常常都必須在 Stackoverflow 或是 Github 上面參考各種的整合問題、不同版本間的 API 相容性與各模組的極限，從而做出抉擇，找出最好的可能性，但這個過程相當有趣，在這過程中不經意地的留下的蹤跡，或許在哪時又能幫到其他人也說不定。

計劃趕不上變化，參賽前所粗略寫好這三十天每天要寫什麼的計畫，隨著實際寫下去，需要補充的題目跟篇幅時間不足已補上的內容，讓計畫沒有嚴格照著走，尤其原本打算花個十天左右來寫 App 的，最後實際上只花了三天，完成度也大大不及預期。不過隨機應變、船到橋頭自然直這就是鐵人賽的有趣之處吧。

筆者是個不常寫文章的人，比起寫文章，動手做開源的套件更為吸引人。這次在同事的推坑下才報名了鐵人賽，花了許多許多的時間跟精力，希望能啟發到一些讀者。更大的收獲是，經過了這樣一個月的重新了解，看到了更多的技術細節與優點，所以筆者接下來能夠對 React Native 跟 GraphQL 抱持著更高的期待。

總之，這三十天，感謝有在觀看的所有讀者！