大神眼中的React Native--備用

標籤：

當我第一次嘗試ReactNative的時候，我覺得這隻是網頁開發人員涉足原生行動裝置 App領域的歪門邪道。

我認為一個js開發人員可以使用javascript來構建iPhone應用確實是一件很酷的事情，但是我很快放棄了自己去使用它的念頭。畢竟我因為愛好而從事ios原生開發多年，並且目前為止已經很熟悉這一套開發專業工具。

我已經創造了一些我引以為傲的iOS應用——一些使用Object－C和Xcode構建的應用，通常人們都是這麼做的。這兩樣工具是蘋果公司提供的、用來開發iOS應用的，所以，我和其他的蘋果開發人員都在用。並且當兩年前蘋果公司發布Swift時，我也毫不猶豫地去嘗試它。

Swift依舊被使用在Xcode中，並且依舊是蘋果公司推薦的開發方式，所以我很快地深入，並且毫不費力地學會了這門語言。我滿足於我的蘋果生態系統圈。React Native看上去只是一個小小的樂子，在我的腦海中，一切原生應用必須被 原生 地開發。對正要開始掌握 原生 開發方式的我來說，學習javascript（我並沒有這方面的經驗）和一種幾乎全新的構建app的方式簡直是荒廢時間。

時間快進到幾個月過後，我可以打保票說，我再也不會使用Objective－C或者Swift來開發iOS應用了。

我們接手了一個新的行動裝置 App開發項目，我大概的看了一下設計和需求。正當我要點開Xcode那漂亮的藍色表徵圖建立一個新的工程時，我們的互動設計師，Adam走過來說，“我們用React Native來做這個東西吧。”

他解釋說，這個項目合約的一部分明確提及了要給這個應用做一個安卓版本。儘管React Native並不支援安卓，我們知道Facebook正積極地在這方面研究。理論上來說，如果我們用RN構建了這個應用的iOS版本，很多部分能夠直接工作在以後的安卓版本上。

好吧，我並不樂意。我覺得我已經站在了iOS開發能力的頂峰，現在卻要我把這一切全部丟棄。在不可避免的學習曲線面前，我懷疑我是不是能夠及時地發布一個高品質的產品。但除此之外，我更加質疑RN是否有能力成產一個高品質的產品。現在看來，我甚至沒有覺得這樣的質疑是不公平的。當時RN作為一個Beta版本剛被公布不久，文檔欠缺，開源庫和組建的數量稀少，示範代碼或者Stack Overflow上的參考幾乎沒有。

我連看都不想看它一眼。但是我這種閉塞的態度只會帶來更多的不良後果。我的第一道坎是學習Flexbox，RN製作UI布局的方式。從最基礎的介面構建器開始，純粹使用代碼來布局UI幾乎擊潰了我的自信。我掙紮著去構建最基礎的視覺效果。

但不僅僅是UI——任何事情都變的不一樣。這對於我是最大的挑戰。

”每當我止步不前或者不理解的時候，我就告訴自己“如果用Objective－C我能夠在五秒鐘之內解決它”。每當我發現了RN中的一個BUG（並且bug的數量非常大），我就會想，“oc中根本不會有這種bug，我為啥一定要和RN鬥智鬥勇呢？”

整整兩個星期，我都在工作中痛苦掙紮。我對自己的感覺從一個傑出的iOS開發人員變成了一個從未寫過一行代碼的人。這很受挫折，直到我花費了整整一個禮拜理清了思路。我後退一步，認識到Adam對RN做了許多研究。作為我的互動知道，我不得不信任他，相信他沒有把我領入一條錯誤的道路。我發誓我要在周一投入工作，埋頭苦幹，假裝Objective－C和Swift從來沒有存在過，並解決這個項目。

學會去喜歡React

幾周之前，我們向App Store提供了第一個React Native應用。對於應用的最終表現結果我真的非常自豪，並且我迫不及待的要開始構建下一個項目了。在僅僅一個月多一點的時間裡，我完全踏上了RN的賊船，是什麼改變了我的想法呢？

React 範例

在React中，所有UI的組件都被放置在render（）方法中，並且被state狀態控制。你的render（）方法定義了UI在各種狀態是如何展現的。當調用setState()的時候，React會找到需要改變的部分並替你修改。想象一個簡單的視圖，擁有一個“Hello World”標籤和按鈕。每點擊一下按鈕，標籤會在“Hello World”和“Goodbye World”之間切換。在Objective－C中，我在按鈕的控制代碼中需要一些難堪的if聲明，就像下面一樣。 

1. if([label.text isEqual:@”HelloWorld”]){
2. label.text =@”GoodbyeWorld”;
3. }else{
4. label.text =@”HelloWorld”;
5. }

這樣很有用，但是這種UI代碼和我第一次建立這個標籤的地方（可能在代碼中，也可能在介面構建器裡）完全脫節。在React中，我們會在state狀態中定義一個buttonClicked的bool變數，在render()函數中，標籤看起來會是這樣的:

1. <Text>
2. {this.state.buttonClicked ? ‘Hello World’ : ‘Goodbye World’}</Text>

並且我們的按鈕控制代碼也會非常簡單

1. this.setState({buttonClicked:!this.state.buttonClicked});

所有和可視化相關的代碼都在同一地方，並且由狀態控制一切。這使得理解和修複這段代碼變的非常容易。

Flexbox

這就是我一開始非常痛恨的UI布局工具，現在變成了RN中我最喜歡的事物之一。我承認一開始非常難以掌握，但一旦你開始使用，它把 為多種不同尺寸螢幕構建UI這件事 變的機器快速和簡單。我曾經對Xcode中的可視化介面編輯器十分熱衷，相比於Flexbox，它的自動布局還是國語複雜。Flexbox使用的CSS式樣式使得樣式重用變的和複製粘貼一樣簡單。其中最棒的事莫過於允許你在一瞬間將樣式值改變到完美。

Live/Hot Reload

沒錯，想看看按鈕右移5像素的樣子就和command＋s一樣簡單。React Native能夠被設定為在iPhone模擬器中自動重繪當前畫面而不重建Xcode工程。這非常厲害因為你不僅可以通過避免重新編譯兒節省時間，你還能夠調整一個深度嵌套在應用中的介面，調整UI而不用回到最初的介面。

Android

現在依舊沒有發布，但就快了——這一定會非常神奇。在最初我對於ReactNative猶豫不決是因為我已經習慣於做原生的iOS開發。對此我從沒有過任何的抱怨。但是我也做過原生的安卓開發，這並不讓人開心。React Native在安卓上會變的很瘦歡迎，同時我也在期待它的發布。這會改變行動裝置 App開發的現狀，通過使用相同的代碼來部署兩個平台的應用。

回顧想念 Xcode

我還是會想念Xcode，或者說是一個IDE編輯器。我已經有了一個很好的RN開發設定，但這並不容易，Sublime Text和一大堆的外掛程式讓我有了文法高亮。sublime能夠完成同一個檔案中基於變數的自動補全，但始終少了一些Xcode自動補全的穩健性。我還是不得不一直查詢開發人員文檔做參考。

小缺點，比如鍵入React.PropTypes.f  IDE並不會告訴我我到底在找func還是function，這很讓人困惑。我也懷念Xcode的版本控制——允許我一一比較我上一次git提交的版本和現在的版本，甚至還允許我基於行撤銷一些特別的改動。我意識到第三方程式能夠協助我完成這些，但是對IDE來說最棒的事情就是將這些囊括到一個包中。（譯者使用VSCode可以解決這些問題）

為了運行RN項目，我需要終端運行npm，Chrome用來debug，sublime來編輯代碼，最終還需要Xcode來運行這個項目並開啟模擬器。在大項目中，這些都是細小的抱怨，但是當我面對RN的時候這依舊是缺點。對於Nuclide（Facebook的新IDE）我抱有很高的期望，希望它能結束所有的這些缺點。

橋接

Facebook還沒有也不會去提供所有iOS轉向React Native的API，所以對於那些缺失的片段他們提供了橋接js的方法。當我第一次深入RN的時候，這方面的文檔非常的糟糕。每當我意識到我需要串連某些事物的時候，我差點就對RN放棄了，因為這些事情早就能夠在Objective－C中正常運作。但是當她們更加詳細地解釋了橋接過程，提供優秀的執行個體之後，這就無所懼怕了。它仍然是一個麻煩，但是我能夠預見到開源社區和nom上會有所有的橋接方案。事實上，大多數的iOSAPI已經存在了。

漏洞，文檔，開源社區

大概所有我最初關於RN的抱怨現在都已經消失殆盡，如果我從今天開始學習它的話。漏洞每天都在被修複，新版本每一周都在迭代。文檔還需要加把勁，但比以前好多了。Facebook和開源社區對於研發這個架構變的十分嚴謹。人們開始聚集在Github和Stack Overflow上探討它。如果你是一個正在考慮嘗試RN的iOS開發人員，你要知道你不是一個人在戰鬥。RN非常棒，你應該帶著開放的態度擁抱他。不要像我一樣吧自己局限在溫室裡。

大神眼中的React Native--備用