Web 開発者として React Native を学びましたが、すべてが間違っていました

これらの要素の見た目や感じ方はブランドの一部です。ヘッダーが別の Web サイトのように見える場合は、何か違和感を感じます。

ネイティブ アプリを構築し始めたとき、私はこの直感を持ち込んできました。

画面を構築するときに、カスタムヘッダーコンポーネントを作成しました。戻るボタンとヘッダータイトルをレイアウトしました。画面間のアニメーション補間を独自に作成しました。下のタブを自作してみました。安全地帯は自分で管理しました。画面の向きを追跡し、それに応じて遷移をアニメーション化しました。

自分のアプリを他の人のアプリと同じように見せることはできませんでした。

私はすぐに、低レベルの UI プリミティブをゼロから作成することが大きな間違いであったことに気づきました。

ユーザーはすべてのアプリに同様のパターンを期待します。そして、ナビゲーション プリミティブには一定レベルの品質が求められます。 iOS の戻るボタンを長押しして数画面戻ることができないと、奇妙に感じます。細かい詳細、特に悪いものは複雑になります。

ネイティブヘッダーが完璧に機能するのに、なぜカスタムヘッダーを作り直す必要があるのでしょうか?それはウェブで学んだことだからです。結局のところ、ネイティブのヘッダーを使用してその色をカスタマイズするべきだったことがわかりました。

さらに良いことには、カスタマイズを一切加えず、UIKit コンポーネントのみを使用することです。人々は、あなたのアプリがベーシックだと言うよりも、それがいかに iPhone にふさわしいものであるかを称賛するでしょう。

なぜこれほど多くの人が好むのか アポロ 実際の Reddit アプリ上で? iOS のルック アンド フィールを採用しているためです。

一方、ウェブは荒野の西部です。真っ白なキャンバスを用意して、すべてを自分で作ります。組み込みのプリミティブは醜いです。ブラウザで Times New Roman を使用できないようにするには、CSS をリセットする必要があります。ボタンはグレーです。入力には醜い青い輪郭があり、モバイルではズームされます。クリックされたリンクは紫色に変わります。

Web 用の UI キットは、生まれては消えていきます。ボタンを作成するという過酷な作業を避けるために、ライブラリは無料および有料で利用できます。

低レベルの HTML プリミティブが適切に見えるかどうか想像できますか?

振り返ってみると、私にとって最大の驚きは、iOS のデザインのプリミティブがいかに美しく、一貫性があり、独自の意見を持っているかということです。ナビゲーション シェル、アニメーション、検索バー、メニュー、タイポグラフィ、色、アイコンなど。世界の偉大なデジタル アーティストによって作成された、彼らが構築したプラットフォームに合わせたデザイン システムがあります。何十年にもわたって完璧なエクスペリエンスを重視してきた結果が、厳格なガイドラインを備えた言語に焼き付けられています。

この事実を理解するまでに時間がかかりすぎました。ヒューマンインターフェイスガイドラインを読もうとも思いませんでした。

2019 年、React Native アプリは今日の Flutter アプリに少し似ているように感じられました。これらは、基礎となるプラットフォームの外観と一致しましたが、感触は一致しませんでした。高品質の模造品のようなもの。

確かに、React Native の哲学は常に、基盤となるプラットフォームと一致することです。しかし実際には、React Native UI ライブラリがネイティブ UI プリミティブを使用することはほとんどありませんでした。代わりに、プラットフォームに似た JS ベースの実装を使用しました。

Android では、React Native アプリはページでマテリアル デザイン ヘッダーを使用していましたが、それらは JS で実装されました。実際にはネイティブ ヘッダー コンポーネントを使用していませんでした。いつも何かがあった 少し 違う。

Web 開発のバックグラウンドを持つ私のような人間にとって、この抽象化は理想的でした。ヘッダーを完全にカスタマイズできます。なぜそれ以下のものを望むのでしょうか？

React Native 開発者を責めるのは難しいです。結局のところ、React Native により、ネイティブ コードを使用することが非常に困難になりました。たとえ使用できたとしても、Expo では使用できない可能性があります。ネイティブのコンテキスト メニューを使用したい場合は、スタック全体をルート化し、裸の React Native を使用する必要があります。正当化するのはかなり難しい。

ネイティブ コードを含むライブラリはしばしば時代遅れになり、メンテナーはアップグレード間の React Native の構成問題に対処することに興味を失い、消費者はライブラリにパッチを適用するために Objective-C ファイルを編集する方法がわかりません。 「JS ベース」はライブラリの README でちょっとした流行語にさえなり、やっかいなネイティブ依存関係を扱うリスクがないという事実を誇示しました。

JS とネイティブの間のこの緊張感が、私の Web 開発者の考え方を維持し続けました。明らかに JS-first が最適な方法でした。

ここ数年で多くのことが変わりました。 Swift と Kotlin を使用して、はるかに少ない構成で React Native のネイティブ モジュールを構築できるようになりました。おそらく最も素晴らしいのは、ネイティブ コードがついに Expo で動作することです。

ゆっくりではありますが、これらのアーキテクチャの変更は React Native エコシステムに影響を与えています。ネイティブファースト開発の支持が高まっています。 React Navigation などのライブラリは、ネイティブ プリミティブを使用するように UI を変更し、開発者のカスタマイズよりもネイティブのユーザー エクスペリエンスを優先しました。

この傾向が続き、ネイティブ コードの使用が普及することを願っています。 とても簡単 import Element from './file.swift'。

したがって、私が犯した間違いを避けて、プラットフォームを使用してください。

そして何よりも、ルールを破る前にルールを知ってください。

私が書いたのは、 初稿 この投稿は 2023 年 6 月に投稿されましたが、その時点では公開するのを忘れていました。