我的 Web 開發思維方式如何讓我在 React Native 中誤入歧途

當我建立第一個 React Native 應用程式時，我之前有一些 Web 開發經驗。在 iOS 和 Android 上使用 React 似乎是我技能的自然延伸。

但我很快就發現——這是一個艱難的過程——網頁開發人員的思維方式並不總是能很好地轉化為原生應用程式開發。

以導航為例。在網路上，每個網站通常都會製作自己獨特的頁面佈局。頁眉、側邊欄和頁腳都是客製化的。您可能從一個簡單的元素開始，但它只是一個空白畫布。您必須使用 JavaScript 和 CSS 來使其具有功能性和視覺吸引力。

這種客製化成為您品牌識別的一部分。如果您的標題看起來像另一個網站的標題，那就感覺很普通。

當我轉向本機應用程式開發時，我也帶著同樣的心態。

我為一切精心設計了自訂元件。我用後退按鈕和標題建立了自己的標題。我創建了自訂螢幕轉換和動畫。我什至自己管理安全區域並跟踪螢幕方向以動畫過渡。我精心製作了自訂底部選項卡 - 任何確保我的應用程式看起來與其他人的不同的東西。

沒多久就意識到這是一個錯誤。

本機應用程式使用者期望跨應用程式保持一致的模式。他們對導航等基本 UI 元素的品質也抱有很高的期望。例如，在 iOS 上，使用者希望長按後退按鈕以返回多個畫面。如果缺少這一點，體驗就會感覺不完整。

那為什麼要重新發明輪子呢？本機組件已經針對該平台進行了最佳化。我可以簡單地使用本機並調整其顏色，而不是從頭開始建立自訂標頭。更好的是，我可以完全跳過自訂並直接使用 UIKit 元件。用戶不會感覺“基本”，而是會欣賞該應用程式如何自然地融入 iOS 生態系統。

以 Apollo for Reddit 等應用程式的成功為例。人們喜歡它，因為它採用了 iOS 的原生設計語言，讓人感覺像是該平台的自然擴充。

這與 Web 開發形成鮮明對比。在網路上，您從空白畫布開始，自己建立一切。開箱即用的基元通常笨重且沒有吸引力。按鈕是灰色的。輸入具有粗糙的輪廓。您甚至需要重設 CSS 才能獲得一致的基線。

Web UI 函式庫的存在就是為了緩解這些挫折感，但它們是一個拼湊的解決方案。相較之下，像 iOS 這樣的原生平台具有凝聚力強、製作精美的設計原語。導航、動畫、選單、版面、顏色和圖示均由專家精心設計，以創造無縫的使用者體驗。這些不僅僅是工具——它們是經過數十年完善而形成的設計系統。

我花了太長時間才意識到這一點。最初我甚至懶得去讀蘋果的人機介面指南。

早在 2019 年，React Native 應用程式常常讓人感覺像是對原生應用程式的高品質模仿。他們看起來很像，但並沒有完全感覺到。 React Native 的理念一直是匹配底層平台，但在實踐中，許多程式庫依賴基於 JavaScript 的元件來模仿本機元件，而不是使用真實的元件。

例如，Android 上的 React Native 應用程式經常使用 Material Design 標頭，但它們是用 JavaScript 實現的，而不是利用實際的本機標頭元件。

身為 Web 開發人員，我發現這種抽像很有吸引力。它讓我可以完全控制定制。但這種方法常常會導致微妙的不一致，進而降低使用者體驗。

React Native 開發者並不完全是罪魁禍首。當時，使用本機程式碼很麻煩，尤其是在使用 Expo 的情況下。新增本機功能通常需要放棄 Expo 並重新配置整個堆疊。具有本機程式碼的程式庫經常與 React Native 更新不同步，導致開發人員必須處理他們不完全理解的 Objective-C 或 Java 檔案。

「基於 JS」甚至成為庫的一個賣點，向開發人員承諾他們不必處理原生依賴關係。

JavaScript 和本機程式碼之間的這種分歧強化了我的網路優先心態。為什麼不堅持使用 JavaScript 來完成所有事情？

值得慶幸的是，React Native 生態系統已經發展。如今，您可以使用 Swift 和 Kotlin 編寫原生模組，而配置則少得多。更好的是，Expo 現在支援本機程式碼。這些改進使得原生優先開發變得更容易，鼓勵程式庫接受原生原語。

例如，React Navigation 已轉向使用本機元件，優先考慮無縫的使用者體驗而不是廣泛的開發人員自訂。

這一轉變標誌著 React Native 的未來更加光明。隨著原生工具變得更容易使用，我們可以建立看起來和感覺都屬於其平台的應用程式。

所以，從我的錯誤中學習。使用該平台的工具並接受其設計理念。最重要的是，在決定打破規則之前先掌握規則。

以上是我的 Web 開發思維方式如何讓我在 React Native 中誤入歧途的詳細內容。更多資訊請關注PHP中文網其他相關文章！