React Nativeの0.59リリースへようこそ！ これは、88人のコントリビューターによる644のコミットを含む、もう1つの大きなリリースです。コントリビューションは他の形でも行われます。したがって、問題の維持、コミュニティの育成、React Nativeに関する人々の教育に「感謝」いたします。今月は多くの待望の変更をもたらし、皆様にお楽しみいただければ幸いです。

🎣 Hooksが登場​

React Hooksはこのリリースの一部であり、コンポーネント間でステートフルなロジックを再利用できます。Hooksについては多くの話題がありますが、まだ聞いたことがない場合は、以下の素晴らしいリソースをご覧ください。

• Hooksの紹介では、なぜReactにHooksを追加するのかを説明しています。
• Hooksの概要では、組み込みHooksの概要を素早く説明しています。
• 独自のHooksの構築では、カスタムHooksによるコードの再利用を示しています。
• React Hooksを理解するでは、Hooksによって開かれた新しい可能性を探求しています。
• useHooks.comでは、コミュニティが管理するHooksのレシピとデモを紹介しています。

ぜひご自身のアプリでお試しください。私たちと同じくらい、再利用性にワクワクしていただけることを願っています。

📱 更新されたJSCはパフォーマンス向上とAndroidでの64ビットサポートを意味します​

React NativeはJSC（JavaScriptCore）を使用してアプリケーションを動作させます。Android上のJSCは数年前のものであり、多くの最新のJavaScript機能がサポートされていませんでした。さらに悪いことに、iOSの最新のJSCと比較してパフォーマンスが劣っていました。このリリースですべてが変わります。

@DanielZlotin、@dulmandakh、@gengjiawen、@kmagiera、@kudoによる素晴らしい作業のおかげで、JSCは過去数年間の遅れを取り戻しました。これにより、64ビットサポート、最新のJavaScriptサポート、そして大幅なパフォーマンス向上がもたらされました。今後のWebKitの改善をそれほど手間なく活用できるように、これを保守可能なプロセスにしたことにも感謝します。また、この作業を可能にしてくれたSoftware MansionとExpoにも感謝します。

💨 インラインrequireによる高速なアプリ起動​

私たちは、デフォルトで高性能なReact Nativeアプリを皆さんに提供できるよう支援したいと考えており、Facebookの最適化をコミュニティにもたらすべく取り組んでいます。アプリケーションは起動を遅くするのではなく、必要に応じてリソースをロードします。この機能は「インライン require」と呼ばれ、Metroが遅延ロードするコンポーネントを特定できるようにします。深く多様なコンポーネントアーキテクチャを持つアプリは、最大の改善を目の当たりにするでしょう。

デフォルトでオンにする前に、コミュニティにその機能がどのように機能するかを知らせてもらう必要があります。0.59にアップグレードすると、新しいmetro.config.jsファイルが作成されます。オプションをtrueに設定して、ご意見をお寄せください！ アプリのベンチマークについては、パフォーマンスドキュメントでインラインrequireについて詳しくお読みください。

🚅 Lean Coreが進行中​

React Nativeは、複雑なリポジトリを持つ大規模で複雑なプロジェクトです。そのため、コードベースはコントリビューターにとってアプローチしにくく、テストが困難で、開発依存関係として肥大化しています。Lean Coreは、より良い管理のためにコードを別のライブラリに移行することで、これらの問題に対処するための私たちの取り組みです。過去数回のリリースでこの最初のステップが見られましたが、真剣に取り組みましょう。

追加のコンポーネントが正式に非推奨になったことに気づくかもしれません。これは素晴らしいニュースです。これらの機能には現在、積極的に保守している所有者がいるからです。警告メッセージに注意し、これらの機能には新しいライブラリに移行してください。将来のリリースで削除されるからです。以下は、コンポーネント、そのステータス、および移行先を示す表です。

今後数ヶ月で、より多くのコンポーネントがこのパスを辿り、よりスリムなコアへと向かいます。この件についてご協力をお願いしています — lean core umbrellaにぜひご参加ください。

👩🏽‍💻 CLIの改善​

React Nativeのコマンドラインツールは開発者のエコシステムへの入り口ですが、長年の問題があり、公式のサポートが不足していました。CLIツールは新しいリポジトリに移動され、専門のメンテナーグループがすでにいくつかの刺激的な改善を行っています。

ログのフォーマットが大幅に改善されました。コマンドはほぼ瞬時に実行されるようになりました。すぐに違いに気づくでしょう。

🚀 0.59へのアップグレード​

React Nativeのアップグレードプロセスに関する皆様からのフィードバックを受け、今後のリリースでエクスペリエンスを改善するための措置を講じています。0.59にアップグレードするには、rn-diff-purgeを使用して現在のReact Nativeバージョンと0.59の間で何が変更されたかを特定し、それらの変更を手動で適用することをお勧めします。プロジェクトを0.59にアップグレードすると、新しく改善されたreact-native upgradeコマンド（rn-diff-purgeに基づいています！）を使用して、新しいリリースが利用可能になったときに0.60以降にアップグレードできるようになります。

🔨 破壊的変更​

0.59 の Android サポートは、Google の最新推奨事項に従って整理されました。これにより、既存のアプリが動作しなくなる可能性があります。この問題は、ランタイムクラッシュや「このアクティビティでは Theme.AppCompat テーマ (またはその派生テーマ) を使用する必要があります」というメッセージとして現れることがあります。プロジェクトの AndroidManifest.xml ファイルを更新し、android:theme の値が AppCompat テーマ (@style/Theme.AppCompat.Light.NoActionBar など) であることを確認することをお勧めします。

react-native-git-upgradeコマンドは0.59で削除され、新しく改良されたreact-native upgradeコマンドが推奨されます。

🤗 感謝​

多くの新しい貢献者が、Flowタイプからのネイティブコード生成の有効化とXcodeの警告の解決に協力してくれました。これらはReact Nativeがどのように機能するかを学び、より大きな利益に貢献する素晴らしい方法です。ありがとうございます！ 今後も同様の問題に注意してください。

これらが私たちが注目したハイライトですが、他にも多くの興奮すべき点があります。すべてのアップデートを見るには、チェンジログをご覧ください。0.59は大規模なリリースです。ぜひお試しください。

年末にかけて、さらに多くの改善が予定されています。ご期待ください！

RyanとReact Nativeコアチーム一同

2018年第4四半期に、React Nativeオープンソースコミュニティへの投資を増やすことを決定した後、React Nativeオープンソースロードマップを発表しました。

最初のマイルストーンとして、私たちはコミュニティの最も目に見える側面の特定と改善に注力しました。目標は、未解決のプルリクエストを削減し、プロジェクトの表面積を減らし、主要なユーザー問題を特定し、コミュニティ管理のガイドラインを確立することでした。

過去2ヶ月間で、私たちは予想以上の進歩を遂げました。詳細については、以下をお読みください。

プルリクエスト​

健全なコミュニティを構築するためには、コード貢献に迅速に対応する必要があります。過去数年間、コミュニティの貢献のレビューを後回しにし、280のプルリクエスト（2018年12月）が蓄積されました。最初のマイルストーンでは、未解決のプルリクエストの数を約65に減らしました。同時に、1日に開かれるプルリクエストの平均数は3.5から7に増加しました。これは、過去3ヶ月間に約600のプルリクエストを処理したことを意味します。

約3分の2をマージし、3分の1のプルリクエストをクローズしました。これらは、廃止されたもの、品質が低いもの、またはプロジェクトの表面積を不必要に増加させるものであれば、マージされずにクローズされました。マージされたプルリクエストのほとんどは、バグを修正したり、クロスプラットフォームの同等性を改善したり、新機能を追加したりしました。注目すべき貢献には、タイプセーフティの改善とAndroidXをサポートするための継続的な作業が含まれます。

Facebookでは、React Nativeをmasterから実行しているため、すべての変更をReact Nativeリリースに組み込む前にまずテストしています。マージされたすべてのプルリクエストのうち、問題を引き起こしたのはわずか6件でした。そのうち4件は内部開発にのみ影響し、2件はリリース候補の段階で捕捉されました。

コミュニティ貢献の中で最も目立ったものの1つは、更新された「RedBox」画面です。これは、コミュニティが開発者体験をより親しみやすいものにする方法の良い例です。

リーン・コア​

React Nativeは現在、Facebookであまり使われていない、メンテナンスされていない多くの抽象化を含む非常に広い表面積を持っています。私たちはReact Nativeをより小さくし、Facebookでほとんど使われていない抽象化をコミュニティがより適切に管理できるようにするために、この表面積を減らすことに取り組んでいます。

最初のマイルストーンで、リーンコアプロジェクトへのコミュニティからの協力を求めました。その反響は圧倒的で、すべての進捗状況にほとんど追いつけないほどでした。1ヶ月足らずで完了したすべての作業をチェックしてください！

私たちが最も興奮しているのは、メンテナーたちが長年の問題を修正し、テストを追加し、長らく要求されていた機能をサポートするために飛び込んできたことです。これらのモジュールは、React Native内よりも多くのサポートを受けており、これがコミュニティにとって素晴らしい一歩であることを示しています。そのようなプロジェクトの例としては、抽出以来多くのプルリクエストを受け取ったWebViewや、現在コミュニティのメンバーによって管理されているCLIがあり、多くの必要な改善と修正を受けました。

主要なユーザー問題​

12月、私たちはコミュニティにReact Nativeで気に入らない点を尋ねました。私たちは回答を集計し、すべての問題に回答しました。幸いなことに、コミュニティが直面している問題の多くはFacebookでも問題となっています。次のマイルストーンでは、主要な問題のいくつかに対処する予定です。

最も多く票を集めた問題の1つは、React Nativeの新しいバージョンへのアップグレードにおける開発者体験でした。残念ながら、私たちはマスターからReact Nativeを実行しているため、この問題を経験することはありません。ありがたいことに、コミュニティのメンバーはすでにこの問題に対処するために立ち上がっています。

• CallstackのMichał Pierzchałaは、内部でrn-diff-purgeを使用してreact-native upgradeを改善しました。また、古いアップグレード手順を削除するためにウェブサイトを更新しました。
• iOSプロジェクトではデフォルトでCocoaPodsを推奨する予定です。これにより、React Nativeのアップグレード時にプロジェクトファイルの変更が減ります。これにより、サードパーティモジュールのインストールとリンクが容易になり、特にLean Coreのコンテキストでは、プロジェクトがデフォルトでより多くのモジュールをリンクすることを期待しているため、さらに重要です。

0.59 リリース​

React Nativeコミュニティ、特にMike GrabowskiとLorenzo Sciandraの協力がなければ、私たちはリリースを公開することはできませんでした。私たちはリリース管理プロセスを改善し、今後さらに積極的に関与する予定です。

• 各メジャーリリースごとにブログ記事を作成するためにコミュニティメンバーと協力します。
• 新しいバージョンにアップグレードする際に、破壊的変更をCLIに直接表示します。
• リリースにかかる時間を短縮します。自動テストを増やす方法や、改善された手動テスト計画を作成する方法を検討しています。

これらの計画の多くは、近日公開されるReact Native 0.59リリースに組み込まれる予定です。0.59には、React Hooks、Android用の新しい64ビットバージョンのJavaScriptCore、そして多くのパフォーマンスと機能の改善が含まれています。現在、リリース候補として公開されており、今後2週間以内に安定版となる予定です。

次のステップ​

今後2か月間、私たちはプルリクエストの管理を継続し、軌道に乗せながら、未解決のGitHubイシューの数を減らし始めます。Lean Coreプロジェクトを通じて、React Nativeの表面積を減らし続けます。コミュニティの主要な問題のうち5つに対処する予定です。コミュニティガイドラインを確定したら、ウェブサイトとドキュメントに注意を向けます。

3月には、コミュニティから10人以上の貢献者をFacebookロンドンに迎え、これらの取り組みのいくつかを進めることを非常に楽しみにしています。React Nativeをご利用いただきありがとうございます。2019年に私たちが取り組んでいる改善点を感じていただければ幸いです。数か月後には、別の更新をお届けします。それまでは、「あなたのプルリクエストをマージし続けます！」⚛️✌️

2018年、React NativeコミュニティはReact Nativeの開発とコミュニケーションの方法について多くの変更を行いました。数年後に振り返ったとき、この変化がReact Nativeにとっての転換点だったとわかるだろうと信じています。

多くの人々が、Fabricとして広く知られているReact Nativeのアーキテクチャの書き換えに興奮しています。これにより、React Nativeのアーキテクチャにおける根本的な制限が修正され、JSIおよびTurboModulesとともに、将来のReact Nativeの成功が確立されます。

2018年の最大の変化は、React Nativeコミュニティに力を与えることでした。当初から、Facebookは世界中の開発者にReact Nativeのオープンソースプロジェクトに参加するよう奨励しました。それ以来、リリースプロセスなどを担当する多くのコア貢献者が現れました。

これらのメンバーは、コミュニティ全体がこのプロジェクトの未来を形作る力をより持てるようにするため、以下のリソースを用いていくつかの重要なステップを踏み出しました。

react-native-releases 📬​

このリポジトリは1月に作成され、新しいリリースをより協力的に追跡できるという二重の目的を果たし、チェリーピックを提案したい人が特定のリリースの一部となるものについて議論を開くきっかけとなりました（0.57.8とそのすべての以前のバージョンと同様に）。

これは、月ごとのリリースサイクルから脱却し、現在バージョン0.57.xで採用されている「長期サポート」アプローチへと移行する原動力となりました。

これらの決定に至った功績の半分は、今年作られたもう一つのリポジトリによるものです。

discussions-and-proposals 🗣​

7月に作成されたこのリポジトリは、React Nativeに関するよりオープンな議論環境というアイデアを拡張しました。以前は、このニーズはメインリポジトリのFor Discussionというラベルが付いたイシューで処理されていましたが、他のライブラリ（例：React）が採用しているRFCアプローチにこの戦略を拡大したいと考えました。

この実験は、React Nativeのライフサイクルにおいて即座にその役割を見出しました。Facebookチームは現在、コミュニティRFCプロセスを利用して、React Nativeで改善できる点について議論し、Lean Coreプロジェクトに関する取り組みを調整しています（その他、興味深い議論も行われています）。

@ReactNativeComm 🐣​

これらの取り組みを伝える私たちのアプローチが、期待したほど効果的ではなかったことは承知しています。React Nativeコミュニティで起こっているすべてのこと（リリースから活発な議論まで）をより簡単に把握できるようにするため、新しいTwitterアカウント@ReactNativeCommを作成しました。

もしあなたがそのSNSを利用していない場合でも、GitHub経由でリポジトリをWatchできることを覚えておいてください。この機能はここ数ヶ月で改善され、リリースのみの通知を受け取ることが可能になったので、いずれにせよ利用を検討する価値があります。

今後の展望 🎓​

過去7～8か月間、コアコントリビューターはReact Native Community GitHub組織を強化し、React Nativeの開発に対する所有権をさらに高め、Facebookとのコラボレーションを強化しました。しかし、これは常に、同様のプロジェクトが持つかもしれない正式な構造を欠いていました。

この組織は、ホストされているすべてのパッケージ/リポジトリに一連の標準を適用し、メンテナーが互いに助け合い、コミュニティが合意した標準に準拠した高品質のコードを貢献できる単一の場所を提供することで、より大きな開発者コミュニティのすべての人の模範となることができます。

2019年初頭には、この新しいガイドライン一式が整備される予定です。専用のディスカッションでご意見をお聞かせください。

これらの変更により、コミュニティはより協力的になり、バージョン1.0に到達したときには、この共同の取り組みを活用して、私たち全員が（さらに）素晴らしいアプリを書き続けることができると確信しています 🤗

皆さんが私たちと同じように、このコミュニティの未来にワクワクしていることを願っています。上記のリポジトリで行われている議論や、皆さんが生み出す素晴らしいコードを通じて、皆さんの参加を楽しみにしています。

ハッピーコーディング！

今年、React NativeチームはReact Nativeの大規模な再設計に注力しました。ソフィーがState of React Nativeの投稿で述べたように、私たちはFacebook外部のReact Nativeユーザーと協力者の活発な人口をより良くサポートするための計画を立てました。今、私たちが取り組んできたことについて、より詳細を共有する時が来ました。そうする前に、オープンソースにおけるReact Nativeの長期的なビジョンを説明したいと思います。

React Nativeに対する私たちのビジョンは…

• 健全なGitHubリポジトリ。 IssueとPull Requestが妥当な期間内に処理されること。
  • テストカバレッジの向上。
  • Facebookのコードリポジトリから同期されるコミットが、オープンソースのテストを破壊しないこと。
  • より大規模で意味のあるコミュニティからのコントリビューション。
• 安定したAPI群。 オープンソースの依存関係との連携が容易になること。
  • Facebookがオープンソースと同じ公開APIを使用すること。
  • React Nativeのリリースがセマンティックバージョニングに従うこと。
• 活気のあるエコシステム。 コミュニティによって維持される、高品質なViewManager、ネイティブモジュール、および複数のプラットフォームのサポート。
• 優れたドキュメント。 ユーザーが高品質な体験を創造する手助けに焦点を当て、APIリファレンスドキュメントを最新の状態に保つこと。

このビジョンを達成するために、以下の重点分野を特定しました。

✂️ Lean Core（コアのスリム化）​

私たちの目標は、コア以外の未使用のコンポーネントを削除することで、React Nativeの表面積を削減することです。コア以外のコンポーネントはコミュニティに引き渡し、より迅速に動けるようにします。表面積が削減されることで、React Nativeへの貢献を管理しやすくなります。

WebView は、コミュニティに移行したコンポーネントの例です。リポジトリから削除した後も、内部チームがこれらのコンポーネントを使い続けられるようなワークフローを開発中です。コミュニティに所有権を譲渡するさらに数十のコンポーネントを特定しています。

🎁 内部のオープンソース化と🛠ツールの更新​

Facebookの製品チームにとってのReact Nativeの開発体験は、オープンソースとはかなり異なる場合があります。オープンソースコミュニティで人気のあるツールは、Facebookでは使用されていません。同じ目的を達成する内部ツールがあるかもしれません。場合によっては、FacebookチームはFacebook以外の場所には存在しないツールに慣れてしまっていることもあります。これらの不一致は、今後のアーキテクチャの作業をオープンソース化する際に課題となる可能性があります。

私たちはこれらの社内ツールの一部を公開する作業を進めます。また、オープンソースコミュニティで人気のツールのサポートも改善します。以下は、私たちが取り組むプロジェクトの（すべてではない）リストです。

• JSIをオープンソース化し、コミュニティが独自のJavaScript VMを持ち込み、RNの初期リリースからの既存のJavaScriptCoreを置き換えることを可能にします。JSIが何であるかについては今後の投稿で説明しますが、それまではReact ConfでのParashuramの講演からJSIについて詳しく学ぶことができます。
• Androidでの64ビットライブラリのサポート。
• 新しいアーキテクチャ下でのデバッグを可能にする。
• CocoaPods、Gradle、Maven、および新しいXcodeビルドシステムのサポートを改善する。

✅ テストインフラ​

Facebookのエンジニアがコードを公開する際、すべてのテストに合格すれば安全に着地したと見なされます。これらのテストは、変更がReact Nativeの表面の1つを壊す可能性があるかどうかを特定します。しかし、FacebookがReact Nativeを使用する方法には違いがあります。これにより、意図せずにオープンソースでReact Nativeを壊してしまうことがありました。

内部テストを強化し、オープンソース環境に可能な限り近い環境で実行されるようにします。これにより、これらのテストを破壊するコードがオープンソースに公開されるのを防ぎます。また、GitHubのコアリポジトリのテストを改善するためのインフラストラクチャを構築し、将来のプルリクエストに簡単にテストを含めることができるようにします。

対象領域の縮小と組み合わせることで、コントリビューターは自信を持ってより迅速にPull Requestをマージできるようになります。

📜 公開API​

FacebookはReact Nativeをオープンソースと同様にパブリックAPI経由で利用し、意図しない破壊的な変更を減らします。これに対処するために、内部の呼び出しサイトの変換を開始しました。私たちの目標は、安定したパブリックAPIに収束させ、バージョン1.0でのセマンティックバージョニングの採用に繋げることです。

📣 コミュニケーション​

React Nativeは、コントリビューター数でGitHubでトップクラスのオープンソースプロジェクトの1つです。私たちはそれを本当に嬉しく思っており、継続していきたいと考えています。透明性の向上やオープンな議論など、コントリビューターの参加につながる取り組みを続けていきます。ドキュメントは、React Nativeを初めて使う人が最初に遭遇するものの1つですが、これまでは優先順位が高くありませんでした。自動生成されるAPIリファレンスドキュメントを復活させ、質の高いユーザーエクスペリエンスの作成に焦点を当てた追加コンテンツを作成し、リリースノートを改善することから、この問題を解決したいと考えています。

タイムライン​

これらのプロジェクトは、来年頃に実現する予定です。これらの取り組みの一部は、JSIがすでにオープンソースに採用されているように、すでに進行中です。表面積の削減など、完了にはもう少し時間がかかるものもあります。私たちはコミュニティに最新の進捗状況を伝えるために最善を尽くします。React Nativeコミュニティの取り組みであり、このロードマップで議論されたいくつかの取り組みの作成につながったDiscussions and Proposalsリポジトリに参加してください。

これまで長い間、AppleはUIWebViewの使用を避け、WKWebViewの使用を推奨してきました。数ヶ月以内にリリースされるiOS 12では、UIWebViewは正式に非推奨になります。React NativeのiOS WebView実装はUIWebViewクラスに大きく依存しています。したがって、これらの開発を踏まえ、WKWebViewを使用するWebView React Nativeコンポーネント用の新しいネイティブiOSバックエンドを構築しました。

これらの変更の最終段階はこのコミットで取り込まれ、0.57リリースで利用可能になります。

この新しい実装を選択するには、useWebKitプロパティを使用してください。

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

改善点​

UIWebViewには、WebViewで実行されているJavaScriptとReact Native間の通信を円滑にする正当な方法がありませんでした。WebViewからメッセージが送信されると、それらをReact Nativeに配信するためにハックに頼っていました。簡単に言えば、メッセージデータを特別なスキームを持つURLにエンコードし、WebViewをそこにナビゲートしていました。ネイティブ側では、このナビゲーションをインターセプトしてキャンセルし、URLからデータを解析して、最終的にReact Nativeを呼び出していました。この実装はエラーが発生しやすく、安全ではありませんでした。WKWebViewの機能を活用してこれを完全に置き換えることができたことをお知らせできてうれしいです。

WKWebViewがUIWebViewよりも優れている点は他にもあり、JavaScript実行速度の向上やマルチプロセスアーキテクチャなどが挙げられます。詳細は2014年のWWDCをご覧ください。

注意点​

コンポーネントが以下のプロパティを使用している場合、WKWebViewに切り替えると問題が発生する可能性があります。当面の間、これらのプロパティの使用は避けることをお勧めします。

動作の不整合

automaticallyAdjustContentInsets および contentInsets (コミット)

WKWebViewにcontentInsetsを追加しても、WKWebViewのビューポートは変更されません。ビューポートはフレームと同じサイズのままです。UIWebViewでは、ビューポートのサイズは実際に変更されます（contentInsetsが正の場合、小さくなります）。

backgroundColor (コミット)

新しいiOS WebViewの実装では、このプロパティを使用すると、背景色がちらつく可能性があります。さらに、`WKWebView`は`UIWebview`とは異なる方法で透明な背景をレンダリングします。詳細はコミットの説明をご覧ください。

非サポート

scalesPageToFit (コミット)

WKWebViewはscalesPageToFitプロパティをサポートしていなかったため、WebView React Nativeコンポーネントではこれを実装できませんでした。

動機​

テクノロジーが進歩し、モバイルアプリが日常生活においてますます重要になるにつれて、アクセシブルなアプリケーションを作成する必要性も同様に重要性を増しています。

React Nativeの限定的なアクセシビリティAPIは、開発者にとって常に大きな悩みの種でした。そこで私たちは、インクルーシブなモバイルアプリケーションをより簡単に作成できるように、アクセシビリティAPIにいくつかのアップデートを行いました。

既存のAPIの問題点​

問題1：完全に異なるが似たような2つのプロパティ - accessibilityComponentType（Android）とaccessibilityTraits（iOS）​

accessibilityComponentTypeとaccessibilityTraitsは、AndroidのTalkBackとiOSのVoiceOverに、ユーザーがどの種類のUI要素を操作しているかを伝えるために使用される2つのプロパティです。これらのプロパティの2つの最大の問題は、

1. これらは異なる使用方法を持つ2つの異なるプロパティですが、同じ目的を持っています。以前のAPIでは、これらは（プラットフォームごとに）2つの別々のプロパティであり、不便なだけでなく、多くの開発者にとって混乱を招くものでした。iOSのaccessibilityTraitsは17種類の異なる値を許可しますが、AndroidのaccessibilityComponentTypeは4種類の値しか許可しません。さらに、ほとんどの値は重複していませんでした。これらの2つのプロパティの入力タイプも異なります。accessibilityTraitsは特性の配列または単一の特性を渡すことを許可しますが、accessibilityComponentTypeは単一の値のみを許可します。
2. Androidでの機能が非常に限られています。 古いプロパティでは、Talkbackが認識できるUI要素は「button」、「radiobutton_checked」、「radiobutton_unchecked」のみでした。

問題2：存在しないアクセシビリティヒント：​

アクセシビリティヒントは、TalkBackやVoiceOverを使用しているユーザーが、アクセシビリティラベルだけでは明らかでないアクセシビリティ要素に対してアクションを実行した場合に何が起こるかを理解するのに役立ちます。これらのヒントは設定パネルでオンオフを切り替えることができます。以前のReact NativeのAPIでは、アクセシビリティヒントはまったくサポートされていませんでした。

問題点3：色の反転の無視​

視覚障害を持つ一部のユーザーは、画面のコントラストを高めるために、携帯電話で反転色を使用しています。AppleはiOS用のAPIを提供しており、開発者が特定のビューを無視できるようにしています。これにより、ユーザーが反転色の設定をオンにしている場合でも、画像や動画が歪むことはありません。このAPIは現在React Nativeではサポートされていません。

新しいAPIの設計​

解決策1：accessibilityComponentType (Android) と accessibilityTraits (iOS) の統合​

accessibilityComponentTypeとaccessibilityTraitsの間の混乱を解決するために、それらを単一のプロパティに統合することにしました。これらは技術的に同じ意図された機能を持っていたため、統合することで開発者はアクセシビリティ機能を構築する際にプラットフォーム固有の複雑さを心配する必要がなくなりました。

背景

iOSでは、UIAccessibilityTraitsは任意のNSObjectに設定できるプロパティです。JavaScriptプロパティを介してネイティブに渡される17個の特性はそれぞれ、Objective-CのUIAccessibilityTraits要素にマップされます。特性はそれぞれlong intで表され、設定されたすべての特性はORされます。

しかし、Androidでは、AccessibilityComponentTypeはReact Nativeによって作成された概念であり、Androidのどのプロパティにも直接マッピングされません。アクセシビリティはアクセシビリティデリゲートによって処理されます。各ビューにはデフォルトのアクセシビリティデリゲートがあります。アクセシビリティアクションをカスタマイズしたい場合は、新しいアクセシビリティデリゲートを作成し、カスタマイズしたい特定のメソッドをオーバーライドし、処理しているビューのアクセシビリティデリゲートを新しいデリゲートに関連付けられるように設定する必要があります。開発者がAccessibilityComponentTypeを設定すると、ネイティブコードは渡されたコンポーネントに基づいて新しいデリゲートを作成し、ビューにそのアクセシビリティデリゲートを設定しました。

行われた変更

新しいプロパティでは、2つのプロパティのスーパーセットを作成したかったのです。accessibilityTraitsにははるかに多くの値があるため、新しいプロパティは既存のプロパティaccessibilityTraitsを主にモデル化することにしました。これらの特性に対するAndroidの機能は、アクセシビリティデリゲートを変更することによってポリフィルされます。

iOSのaccessibilityTraitsに設定できるUIAccessibilityTraitsの値は17種類あります。しかし、そのすべてを新しいプロパティの可能な値として含めたわけではありません。これは、これらの特性の一部を設定する効果が実際にはあまり知られておらず、これらの値の多くはほとんど使われていないためです。

UIAccessibilityTraitsに設定された値は、通常、2つの目的のいずれかを果たしていました。UI要素が持っているロールを記述するか、UI要素が置かれている状態を記述するかです。以前のプロパティのほとんどの使用例では、通常、ロールを表す1つの値を使用し、それを「状態選択済み」、「状態無効」、またはその両方と組み合わせていました。したがって、私たちは2つの新しいアクセシビリティプロパティ、accessibilityRoleとaccessibilityStateを作成することにしました。

アクセシビリティロール

新しいプロパティaccessibilityRoleは、TalkbackやVoiceoverにUI要素の役割を伝えるために使用されます。この新しいプロパティは、以下のいずれかの値を取ることができます。

• なし
• ボタン
• リンク
• 検索
• 画像
• キーボードキー
• テキスト
• 調整可能
• ヘッダー
• 要約
• 画像ボタン

このプロパティは、UI要素が論理的にこれらのうちの1つ以上を取ることが一般的にないため、1つの値のみを渡すことができます。例外はimageとbuttonなので、両方を組み合わせたimagebuttonという役割を追加しました。

アクセシビリティ状態

新しいプロパティaccessibilityStatesは、TalkbackやVoiceoverにUI要素がどのような状態にあるかを伝えるために使用されます。このプロパティは、以下の値のいずれかまたは両方を含む配列を取ります。

• 選択済み
• 無効

解決策2：アクセシビリティヒントの追加​

このために、新しいプロパティaccessibilityHintを追加しました。このプロパティを設定すると、TalkbackやVoiceoverがユーザーにヒントを読み上げることができるようになります。

アクセシビリティヒント

このプロパティは、読み上げられるアクセシビリティヒントを文字列の形式で受け取ります。

iOSでは、このプロパティを設定すると、ビューに対応するネイティブプロパティAccessibilityHintが設定されます。iPhoneでアクセシビリティヒントがオンになっている場合、ヒントはVoiceoverによって読み上げられます。

Androidでは、このプロパティを設定すると、ヒントの値がアクセシビリティラベルの末尾に追加されます。この実装の利点は、iOSのヒントの動作を模倣していることですが、欠点は、これらのヒントをiOSのようにAndroidの設定でオフにできないことです。

Androidでこの決定を下した理由は、通常、アクセシビリティヒントは特定のアクション（例：クリック）に対応しており、プラットフォーム間で動作の一貫性を保ちたかったためです。

問題点3への解決策​

accessibilityIgnoresInvertColors

私たちはAppleのAPIであるAccessibilityIgnoresInvertColorsをJavaScriptに公開しました。これにより、色を反転させたくないビュー（例：画像）がある場合、このプロパティをtrueに設定すると、反転されなくなります。

新しい使い方​

これらの新しいプロパティは、React Native 0.57リリースで利用可能になります。

アップグレード方法​

現在accessibilityComponentTypeとaccessibilityTraitsを使用している場合は、以下の手順で新しいプロパティにアップグレードできます。

1. jscodeshiftの使用​

最も単純なユースケースは、jscodeshiftスクリプトを実行することで置き換えることができます。

このスクリプトは、以下のインスタンスを置き換えます。

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

以下のように

accessibilityRole= “trait”

このスクリプトはまた、AccessibilityComponentTypeのインスタンスを削除します（AccessibilityComponentTypeを設定するすべての場所でAccessibilityTraitsも設定すると仮定しています）。

2. 手動でのcodemodの使用​

AccessibilityTraitsを使用していたケースで、AccessibilityRoleに該当する値がない場合や、複数の特性がAccessibilityTraitsに渡されたケースでは、手動でコード変更を行う必要がありました。

一般的に、

accessibilityTraits= {[“button”, “selected”]}

は手動で以下のように置き換えられます。

accessibilityRole=“button”
accessibilityStates={[“selected”]}

これらのプロパティはすでにFacebookのコードベースで使用されています。Facebookのコード変更は驚くほど簡単でした。jscodeshiftスクリプトがインスタンスの半分を修正し、残りの半分は手動で修正しました。全体として、プロセス全体にかかった時間は数時間未満でした。

更新されたAPIが役立つことを願っています！そして、引き続きアクセシブルなアプリを作り続けてください！#inclusion

待望のReact Native 0.56バージョンが利用可能になりました🎉。このブログ記事では、この新しいリリースで導入された変更のいくつかを紹介します。変更点また、3月以降に私たちを忙しくさせてきたことを説明する機会も設けたいと思います。

破壊的変更のジレンマ、あるいは「いつリリースするか？」​

貢献者ガイドには、React Nativeへのすべての変更が経る統合プロセスが説明されています。このプロジェクトは多くの異なるツールで構成されており、すべてを適切に機能させるためには調整と継続的なサポートが必要です。これに、プロジェクトに貢献する活気あるオープンソースコミュニティが加わると、その途方もない規模がわかるでしょう。

React Nativeの驚くべき採用により、破壊的変更は細心の注意を払って行われる必要があり、そのプロセスは望ましいほどスムーズではありません。コアチームが新しい一連の破壊的変更を統合してテストできるように、4月と5月のリリースをスキップするという決定が下されました。専用のコミュニティコミュニケーションチャネルが途中で使用され、2018年6月（0.56.0）のリリースが、安定版リリースを辛抱強く待っていた人々にとって可能な限り手間のかからないものとなるようにしました。

0.56.0は完璧でしょうか？いいえ、世の中のすべてのソフトウェアと同様に、完璧ではありません。しかし、私たちは「さらなる安定性を待つ」と「テストが成功したため、前進できる」というトレードオフのバランスが取れた地点に達し、リリースする準備が整ったと感じています。さらに、最終的な0.56.0リリースでは解決されていないいくつかの問題を認識しています。ほとんどの開発者は0.56.0へのアップグレードで問題はないはずです。前述の問題でブロックされている方々には、私たちの議論にご参加いただき、これらの問題の解決策について協力できることを楽しみにしています。

0.56.0は、より安定したフレームワークに向けた基礎的なビルディングブロックと考えることができるでしょう。すべてのエッジケースが取り除かれるまでには、おそらく1〜2週間の幅広い採用が必要ですが、これにより2018年7月の（0.57.0）リリースはさらに良いものになるでしょう。

このセクションの最後に、合計818コミット(!)に取り組んだ67名のコントリビューター全員に感謝の意を表したいと思います。彼らの貢献が皆様のアプリをさらに改善するのに役立つでしょう👏。

それでは、早速ですが...

大きな変更点​

Babel 7​

ご存知のように、最新かつ最高のJavaScript機能を使用できるようにするトランスパイラツールであるBabelは、間もなくv7に移行します。この新しいバージョンにはいくつかの重要な変更が伴うため、今がアップグレードの好機であると感じました。これにより、Metroがその改善点を活用できるようになります。

アップグレードで問題が発生した場合は、関連するドキュメントセクションを参照してください。

Androidサポートの近代化​

Androidでは、周辺のツールが大幅に変更されました。Gradle 3.5、Android SDK 26、Fresco 1.9.0、OkHttp 3.10.0、さらにはNDK APIターゲットをAPI 16に更新しました。これらの変更は問題なく行われ、ビルド速度の向上につながるはずです。さらに重要なのは、来月から施行される新しいPlayストア要件に開発者が準拠できるようになることです。

これに関連して、特にDulmandakh氏が、これを可能にするために提出された多くのPRに感謝したいと思います👏。

この方向性でさらにいくつかの手順を踏む必要があります。Androidサポートの更新に関する今後の計画と議論については、専用のイシュー（およびJSCのサイドイシュー）で追跡できます。

新しいNode、Xcode、React、そしてFlow – なんてことだ！​

Node 8がReact Nativeの標準になりました。実はすでにテストが行われていましたが、Node 6がメンテナンスモードに入ったため、私たちは両足を前に踏み出しました。Reactも16.4にアップデートされ、多くの修正がもたらされました。

iOS 8のサポートを終了し、iOS 9がターゲットにできる最古のiOSバージョンとなりました。iOS 8を実行できるすべてのデバイスはiOS 9にアップグレードできるため、これが問題になるとは考えていません。この変更により、iOS 8を実行している古いデバイスの回避策を実装していた、めったに使用されないコードを削除できました。

継続的インテグレーションツールチェーンはXcode 9.4を使用するように更新され、すべてのiOSテストがAppleが提供する最新の開発者ツールで実行されることを保証しています。

Flow 0.75にアップグレードし、多くの開発者が評価する新しいエラー形式を使用できるようになりました。さらに多くのコンポーネントに型を作成しました。プロジェクトでまだ静的型付けを強制していない場合は、実行時ではなくコード作成時に問題を特定するためにFlowの使用を検討してください。

その他多くのこと...​

たとえば、YellowBoxは新しい実装に置き換えられ、デバッグが大幅に改善されました。

完全なリリースノートについては、こちらの完全なチェンジログを参照してください。また、この新しいバージョンへの移行で問題を避けるために、アップグレードガイドに常に注意してください。

最後に：今週から、React Nativeコアチームは毎月の会議を再開します。会議で何が議論されたかについて全員が最新の情報を把握できるようにし、今後の会議のために皆様からのフィードバックを手元に置いておくようにします。

皆さん、楽しいコーディングを！

Lorenzo、Ryan、そしてReact Nativeコアチーム一同

追伸： いつものことながら、React Nativeはまだ多くの変更が進行中であるため0.xバージョンであることを思い出していただきたいと思います。そのため、アップグレードの際には、おそらく何かがクラッシュしたり破損したりする可能性があることを覚えておいてください。イシューやPRを送信する際にはお互いに協力し、施行されているCoCに従うことを忘れないでください。画面の向こうには常に人間がいます。

React Nativeの現状について最後のアップデートを公開してから、しばらく時間が経ちました。

Facebookでは、React Nativeをこれまで以上に、多くの重要なプロジェクトで使用しています。当社の最も人気のある製品の1つはMarketplaceです。これはアプリのトップレベルタブの1つで、毎月8億人が利用しています。2015年の立ち上げ以来、MarketplaceのすべてがReact Nativeで構築されており、アプリのさまざまな部分にわたって100を超える全画面表示が含まれています。

また、アプリの多くの新しい部分にもReact Nativeを使用しています。先月のF8の基調講演をご覧になった方なら、献血、危機対応、プライバシーショートカット、健康診断を認識されるでしょう。これらはすべて、React Nativeで構築された最近の機能です。そして、主要なFacebookアプリ以外のプロジェクトでもReact Nativeが使用されています。新しいOculus Go VRヘッドセットには、完全にReact Nativeで構築されたコンパニオンモバイルアプリが含まれており、ヘッドセット自体で多くの体験を動かすReact VRは言うまでもありません。

当然ながら、私たちはアプリを構築するために他の多くのテクノロジーも使用しています。LithoとComponentKitは、アプリで広範に使用されている2つのライブラリです。どちらも、ネイティブ画面を構築するためのReactのようなコンポーネントAPIを提供しています。React Nativeが他のすべてのテクノロジーを置き換えることを目標としたことはありません。私たちはReact Native自体をより良くすることに焦点を当てていますが、他のチームがReact Nativeからアイデアを借用し、非JavaScriptコードにもインスタントリロードをもたらすのを見るのが大好きです。

アーキテクチャ​

2013年にReact Nativeプロジェクトを開始した際、JavaScriptとネイティブの間に非同期、シリアライズ可能、バッチ処理される単一の「ブリッジ」を持つように設計しました。React DOMがReactの状態更新をdocument.createElement(attrs)や.appendChild()のような命令的で可変的なDOM API呼び出しに変換するのと同様に、React Nativeは[["createView", attrs], ["manageChildren", ...]]のような、実行する変更をリストした単一のJSONメッセージを返すように設計されました。私たちは、同期的な応答を返すことに決して依存せず、そのリストのすべてがJSONに完全にシリアライズできることを保証するようにシステム全体を設計しました。これは、柔軟性をもたらしたためです。このアーキテクチャの上に、WebSocket接続を介してすべてのJavaScriptコードを非同期に実行するChromeデバッグのようなツールを構築することができました。

過去5年間で、これらの初期の原則が一部の機能の構築を困難にしていることがわかりました。非同期ブリッジとは、JavaScriptロジックを同期的な応答を期待する多くのネイティブAPIと直接統合できないことを意味します。ネイティブ呼び出しをキューに入れるバッチ処理されたブリッジは、React Nativeアプリがネイティブに実装された関数を呼び出すことをより困難にします。そして、シリアライズ可能なブリッジは、2つの世界間でメモリを直接共有する代わりに、不必要なコピーを意味します。完全にReact Nativeで構築されたアプリの場合、これらの制限は通常許容できます。しかし、React Nativeと既存のアプリコードの間で複雑な統合が行われるアプリの場合、これらは不満です。

私たちは、React Nativeのアーキテクチャの大規模な再構築に取り組んでおり、フレームワークをより柔軟にし、ハイブリッドJavaScript/ネイティブアプリのネイティブインフラストラクチャとの統合を改善することを目指しています。 このプロジェクトでは、過去5年間で学んだことを適用し、アーキテクチャを段階的に現代的なものにします。React Nativeの内部の多くを書き直していますが、変更のほとんどは内部的なものです。既存のReact Nativeアプリは、変更なし、またはほとんど変更なしで動作し続けます。

React Nativeをより軽量にし、既存のネイティブアプリに適合させるために、この再構築には3つの主要な内部変更があります。まず、スレッドモデルを変更しています。各UI更新で3つの異なるスレッドで作業を実行する必要がある代わりに、優先度の高い更新のために任意のすべてのスレッドでJavaScriptを同期的に呼び出すことが可能になり、応答性を維持するためにメインスレッドから優先度の低い作業を維持します。第二に、複数のレンダリング優先度を可能にし、非同期データ処理を簡素化するために、React Nativeに非同期レンダリング機能を組み込んでいます。最後に、ブリッジを簡素化して、より高速で軽量にします。ネイティブとJavaScript間の直接呼び出しはより効率的になり、クロス言語スタックトレースのようなデバッグツールを簡単に構築できるようになります。

これらの変更が完了すれば、より密接な統合が可能になります。現在、ネイティブのナビゲーションやジェスチャー処理、UICollectionViewやRecyclerViewのようなネイティブコンポーネントを複雑なハックなしに組み込むことはできません。スレッドモデルの変更後は、このような機能の構築が簡単になります。

この作業が完了に近づくにつれて、今年後半に詳細を公開する予定です。

コミュニティ​

Facebook内のコミュニティと共に、Facebook以外にもReact Nativeユーザーと協力者の活発な人口がいることを嬉しく思います。React Nativeユーザーへのサービスを改善し、プロジェクトへの貢献を容易にすることで、React Nativeコミュニティをさらにサポートしたいと考えています。

私たちのアーキテクチャの変更がReact Nativeを他のネイティブインフラストラクチャとよりクリーンに相互運用できるようにするのと同様に、React NativeはJavaScriptエコシステムに適合させるためにJavaScript側でよりスリムであるべきであり、これにはVMとバンドラを交換可能にすることが含まれます。破壊的変更のペースに追いつくのが難しいことは承知していますので、主要なリリースを減らす方法を見つけたいと考えています。最後に、一部のチームが、私たちの専門知識がまだ文書化されていない起動最適化などのトピックについて、より徹底したドキュメントを求めていることを知っています。今後1年間でこれらの変更の一部が見られることを期待してください。

あなたがReact Nativeを使用しているなら、あなたは私たちのコミュニティの一員です。React Nativeをあなたにとってより良くするために、引き続きご意見をお聞かせください。

React Nativeはモバイル開発者の道具箱の中の一つのツールに過ぎませんが、私たちが強く信じているツールであり、過去1年間で500人以上のコントリビューターから2500以上のコミットを得て、日々改善しています。

JavaScript！誰もが大好きですよね。しかし、中には型も好きな人もいます。幸い、JavaScriptに強力な型を追加するオプションは存在します。私のお気に入りはTypeScriptですが、React NativeはFlowをそのままサポートしています。どちらを好むかは好みによるもので、それぞれがJavaScriptに型の魔法を追加する方法について独自のアプローチを持っています。今日は、React NativeアプリでTypeScriptを使用する方法を見ていきましょう。

この記事では、MicrosoftのTypeScript-React-Native-Starterリポジトリをガイドとして使用します。

更新: このブログ記事が書かれてから、さらに簡単になりました。このブログ記事で説明されているセットアップはすべて、たった1つのコマンドを実行するだけで置き換えられます。

npx react-native init MyAwesomeProject --template react-native-template-typescript

ただし、BabelのTypeScriptサポートにはいくつかの制限があり、上記のブログ記事で詳細に説明されています。この投稿で概説されている手順は依然として機能し、Artsyは引き続き本番環境でreact-native-typescript-transformerを使用していますが、React NativeとTypeScriptをすぐに開始する最速の方法は上記のコマンドを使用することです。必要に応じて、後でいつでも切り替えることができます。

いずれにせよ、楽しんでください！元のブログ記事は以下に続きます。

前提条件​

いくつかの異なるプラットフォームで開発し、いくつかの異なる種類のデバイスをターゲットにしている可能性があるため、基本的なセットアップには手間がかかることがあります。まず、TypeScriptなしで通常のReact Nativeアプリを実行できることを確認する必要があります。React Nativeのウェブサイトの指示に従って始めましょう。デバイスまたはエミュレーターにデプロイできるようになったら、TypeScript React Nativeアプリを開始する準備が整います。

Node.js、npm、Yarnも必要です。

初期化​

通常のReact Nativeプロジェクトのひな形を作成してみたら、TypeScriptを追加する準備が整います。さあ、やってみましょう。

react-native init MyAwesomeProject
cd MyAwesomeProject

TypeScriptの追加​

次のステップは、プロジェクトにTypeScriptを追加することです。以下のコマンドは、

• プロジェクトにTypeScriptを追加します
• プロジェクトにReact Native TypeScript Transformerを追加します
• 空のTypeScript設定ファイルを初期化します。これは次に設定します
• 空のReact Native TypeScript Transformer設定ファイルを追加します。これは次に設定します
• ReactとReact Nativeの型定義を追加します

では、これらを実行してみましょう。

yarn add --dev typescript
yarn add --dev react-native-typescript-transformer
yarn tsc --init --pretty --jsx react
touch rn-cli.config.js
yarn add --dev @types/react @types/react-native

tsconfig.jsonファイルにはTypeScriptコンパイラのすべての設定が含まれています。上記のコマンドで作成されたデフォルトはほとんど問題ありませんが、ファイルを開いて次の行のコメントを解除してください。

{
  /* Search the config file for the following line and uncomment it. */
  // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
}

rn-cli.config.jsにはReact Native TypeScript Transformerの設定が含まれています。それを開いて以下を追加してください。

module.exports = {
  getTransformModulePath() {
    return require.resolve('react-native-typescript-transformer');
  },
  getSourceExts() {
    return ['ts', 'tsx'];
  },
};

TypeScriptへの移行​

生成されたApp.jsと__tests_/App.jsファイルをApp.tsxにリネームします。index.jsは.js拡張子を使用する必要があります。新しいファイルはすべて.tsx拡張子（またはファイルにJSXが含まれていない場合は.ts）を使用する必要があります。

今すぐアプリを実行しようとすると、「オブジェクトのプロトタイプはオブジェクトまたはnullのみである必要があります」のようなエラーが発生します。これは、Reactからのデフォルトのエクスポートと、同じ行の名前付きエクスポートのインポートに失敗したことが原因です。App.tsxを開き、ファイルの先頭のインポートを修正します。

-import React, { Component } from 'react';
+import React from 'react'
+import { Component } from 'react';

これの一部は、BabelとTypeScriptがCommonJSモジュールと相互運用する方法の違いに関係しています。将来的には、両者は同じ挙動に安定するでしょう。

この時点で、React Nativeアプリを実行できるはずです。

TypeScriptテストインフラの追加​

React NativeはJestを同梱しているため、TypeScriptでReact Nativeアプリをテストするには、devDependenciesにts-jestを追加する必要があります。

yarn add --dev ts-jest

次に、package.jsonを開き、jestフィールドを以下に置き換えます。

{
  "jest": {
    "preset": "react-native",
    "moduleFileExtensions": [
      "ts",
      "tsx",
      "js"
    ],
    "transform": {
      "^.+\\.(js)$": "<rootDir>/node_modules/babel-jest",
      "\\.(ts|tsx)$": "<rootDir>/node_modules/ts-jest/preprocessor.js"
    },
    "testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
    "testPathIgnorePatterns": [
      "\\.snap$",
      "<rootDir>/node_modules/"
    ],
    "cacheDirectory": ".jest/cache"
  }
}

これにより、Jestは.tsおよび.tsxファイルをts-jestで実行するように設定されます。

依存関係の型定義ファイルのインストール​

TypeScriptで最高の体験を得るには、型チェッカーが依存関係の形状とAPIを理解する必要があります。一部のライブラリは.d.tsファイル（型宣言/型定義ファイル）をパッケージに含めて公開し、基盤となるJavaScriptの形状を記述できます。その他のライブラリについては、@types/npmスコープにある適切なパッケージを明示的にインストールする必要があります。

たとえば、ここではJest、React、React Native、およびReact Test Rendererの型が必要になります。

yarn add --dev @types/jest @types/react @types/react-native @types/react-test-renderer

これらの宣言ファイルパッケージは、開発時のみこれらの依存関係を使用し、実行時には使用しないReact Native「アプリ」であるため、開発依存関係に保存しました。ライブラリをNPMに公開している場合は、これらの型依存関係の一部を通常の依存関係として追加する必要があるかもしれません。

.d.tsファイルの入手方法についてはこちらで詳しく読むことができます。

無視するファイルの追加​

ソース管理では、.jestフォルダを無視するように設定する必要があります。gitを使用している場合は、.gitignoreファイルにエントリを追加するだけです。

# Jest
#
.jest/

チェックポイントとして、ファイルをバージョン管理にコミットすることを検討してください。

git init
git add .gitignore # import to do this first, to ignore our files
git add .
git commit -am "Initial commit."

コンポーネントの追加​

アプリにコンポーネントを追加しましょう。Hello.tsxコンポーネントを作成します。これは教育的なコンポーネントであり、実際にアプリで書くようなものではありませんが、React NativeでTypeScriptを使用する方法を示すための、ある程度複雑なものです。

componentsディレクトリを作成し、以下の例を追加してください。

// components/Hello.tsx
import React from 'react';
import {Button, StyleSheet, Text, View} from 'react-native';

export interface Props {
  name: string;
  enthusiasmLevel?: number;
}

interface State {
  enthusiasmLevel: number;
}

export class Hello extends React.Component<Props, State> {
  constructor(props: Props) {
    super(props);

    if ((props.enthusiasmLevel || 0) <= 0) {
      throw new Error(
        'You could be a little more enthusiastic. :D',
      );
    }

    this.state = {
      enthusiasmLevel: props.enthusiasmLevel || 1,
    };
  }

  onIncrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel + 1,
    });
  onDecrement = () =>
    this.setState({
      enthusiasmLevel: this.state.enthusiasmLevel - 1,
    });
  getExclamationMarks = (numChars: number) =>
    Array(numChars + 1).join('!');

  render() {
    return (
      <View style={styles.root}>
        <Text style={styles.greeting}>
          Hello{' '}
          {this.props.name +
            this.getExclamationMarks(this.state.enthusiasmLevel)}
        </Text>

        <View style={styles.buttons}>
          <View style={styles.button}>
            <Button
              title="-"
              onPress={this.onDecrement}
              accessibilityLabel="decrement"
              color="red"
            />
          </View>

          <View style={styles.button}>
            <Button
              title="+"
              onPress={this.onIncrement}
              accessibilityLabel="increment"
              color="blue"
            />
          </View>
        </View>
      </View>
    );
  }
}

// styles
const styles = StyleSheet.create({
  root: {
    alignItems: 'center',
    alignSelf: 'center',
  },
  buttons: {
    flexDirection: 'row',
    minHeight: 70,
    alignItems: 'stretch',
    alignSelf: 'center',
    borderWidth: 5,
  },
  button: {
    flex: 1,
    paddingVertical: 0,
  },
  greeting: {
    color: '#999',
    fontWeight: 'bold',
  },
});

おお！たくさんありますが、分解してみましょう。

• div、span、h1などのHTML要素をレンダリングする代わりに、ViewやButtonなどのコンポーネントをレンダリングしています。これらは、異なるプラットフォームで動作するネイティブコンポーネントです。
• スタイリングは、React Nativeが提供するStyleSheet.create関数を使用して指定されます。Reactのスタイルシートを使用すると、Flexboxを使用してレイアウトを制御したり、CSSの他の構成要素に似たものを使用してスタイルを設定したりできます。

コンポーネントテストの追加​

コンポーネントができたので、テストしてみましょう。

テストランナーとしてJestはすでにインストールされています。コンポーネントのスナップショットテストを記述するので、スナップショットテストに必要なアドオンを追加しましょう。

yarn add --dev react-addons-test-utils

それでは、componentsディレクトリに__tests__フォルダを作成し、Hello.tsxのテストを追加しましょう。

// components/__tests__/Hello.tsx
import React from 'react';
import renderer from 'react-test-renderer';

import {Hello} from '../Hello';

it('renders correctly with defaults', () => {
  const button = renderer
    .create(<Hello name="World" enthusiasmLevel={1} />)
    .toJSON();
  expect(button).toMatchSnapshot();
});

テストが最初に実行されると、レンダリングされたコンポーネントのスナップショットが作成され、components/__tests__/__snapshots__/Hello.tsx.snapファイルに保存されます。コンポーネントを変更すると、スナップショットを更新し、意図しない変更がないか確認する必要があります。React Nativeコンポーネントのテストについては、こちらで詳しく読むことができます。

次のステップ​

公式のReactチュートリアルと状態管理ライブラリReduxをチェックしてみてください。これらのリソースは、React Nativeアプリを作成する際に役立ちます。さらに、Web上のReactとReact Nativeの両方をサポートする、完全にTypeScriptで書かれたコンポーネントライブラリであるReactXPも検討することをお勧めします。

より型安全なReact Native開発環境で楽しんでください！

カリフォルニア州チコに本社を置くBuild.comは、住宅改修用品のオンライン小売業者として最大手の1つです。同チームは18年間ウェブ中心のビジネスで堅調な実績を上げてきましたが、2015年にモバイルアプリを検討し始めました。小規模なチームと限られたネイティブ経験のため、AndroidとiOSの固有のアプリを構築することは現実的ではありませんでした。その代わりに、私たちは非常に新しいReact Nativeフレームワークに賭けることにしました。最初のコミットは2015年8月12日、React Native v0.8.0を使用していました！2016年10月15日には両方のApp Storeで公開されました。過去2年間で、アプリのアップグレードと拡張を続けています。現在、React Nativeバージョン0.53.0を使用しています。

アプリはhttps://www.build.com/appでご覧いただけます。

機能​

当社のアプリはフル機能であり、電子商取引アプリに期待されるすべての機能が含まれています。商品リスト、検索とソート、複雑な商品の設定機能、お気に入りなどです。標準的なクレジットカード決済方法、PayPal、そしてiOSユーザー向けにはApple Payも利用できます。

期待されないかもしれない、いくつかの際立った機能は次のとおりです。

1. 約40製品、90種類の仕上げに対応した3Dモデルが利用可能
2. 拡張現実（AR）により、ユーザーは照明や蛇口が自宅でどのように見えるかを98%のサイズ精度で確認できます。Build.comのReact Nativeアプリは、Apple App StoreのARショッピングで特集されています！ARは現在、AndroidとiOSの両方で利用可能です！
3. 共同プロジェクト管理機能により、人々がプロジェクトのさまざまな段階ごとに買い物リストを作成し、選定について協力できます。

私たちは、ARによる没入型ショッピングの次の段階を含め、アプリ体験を向上させ続ける多くの新しくエキサイティングな機能に取り組んでいます。

私たちの開発ワークフロー​

Build.comでは、各開発者が自分に最適なツールを選択できます。

• IDEには、Atom、IntelliJ、VS Code、Sublime、Eclipseなどがあります。
• 単体テストについては、開発者は新しいコンポーネントに対してJestの単体テストを作成する責任があり、私たちはjest-coverage-ratchetを使用してアプリの古い部分のカバレッジを増やす作業に取り組んでいます。
• ベータ版とリリース候補のビルドにはJenkinsを使用しています。このプロセスは私たちにとってうまく機能していますが、リリースノートやその他の成果物を作成するには依然としてかなりの作業が必要です。
• 結合テストには、デスクトップ、モバイル、Webにまたがって作業するテスターの共有プールが含まれています。私たちの自動化エンジニアは、JavaとAppiumを使用して自動化された結合テストスイートを構築しています。
• ワークフローの他の部分には、詳細なeslint設定、テストに必要なプロパティを強制するカスタムルール、問題のある変更をブロックするpre-pushフックなどがあります。

アプリで使用されているライブラリ​

Build.comアプリは、Redux、Moment、Numeral、Enzyme、そして多数のReact Nativeブリッジモジュールを含む多くの一般的なオープンソースライブラリに依存しています。また、放棄されたか、カスタム機能が必要だったためにフォークされたオープンソースライブラリも多数使用しています。ざっと数えると、約115のJavaScriptおよびネイティブの依存関係があります。未使用のライブラリを削除するツールを検討したいと考えています。

私たちは現在、TypeScriptによる静的型付けの追加を進めており、オプショナルチェイニングも検討しています。これらの機能は、私たちがまだ目にしているいくつかの種類のバグを解決するのに役立つ可能性があります。

• データが間違った型である
• オブジェクトが期待した内容を含んでいないためにデータが未定義である

オープンソースへの貢献​

私たちはオープンソースに大きく依存しているため、私たちのチームはコミュニティに貢献することにコミットしています。Build.comは、チームが構築したライブラリをオープンソース化することを許可し、私たちが使用しているライブラリに貢献することを奨励しています。

私たちは、いくつかのReact Nativeライブラリをリリースし、維持してきました。

• react-native-polyfill
• react-native-simple-store
• react-native-contact-picker

また、ReactとReact Native、react-native-schemes-manager、react-native-swipeable、react-native-gallery、react-native-view-transformer、react-native-navigationなど、多くのライブラリにも貢献しています。

私たちの道のり​

過去数年間で、React Nativeとそのエコシステムは大きく成長しました。当初は、React Nativeのバージョンごとにバグが修正される一方で、新たなバグがいくつか発生するように思えました。例えば、AndroidではRemote JS Debuggingが数ヶ月間壊れていました。幸いなことに、2017年には事態はかなり安定しました。

ナビゲーションライブラリ​

私たちが抱えていた大きな課題の1つは、ナビゲーションライブラリでした。長い間、Expoのex-navライブラリを使用していました。それは私たちにとってうまくいっていましたが、最終的に非推奨になりました。しかし、当時は機能開発が盛んだったため、ナビゲーションライブラリを切り替えるのは現実的ではありませんでした。そのため、ライブラリをフォークしてReact 16とiPhone Xをサポートするようにパッチを当てる必要がありました。最終的に、react-native-navigationに移行することができ、今後もサポートが継続されることを願っています。

ブリッジモジュール​

もう一つの大きな課題はブリッジモジュールでした。私たちが初めて始めた頃、多くの重要なブリッジが不足していました。チームメイトの1人がreact-native-contact-pickerを作成したのは、アプリでAndroidの連絡先ピッカーにアクセスする必要があったからです。また、React Native内の変更によって壊れたブリッジもたくさん見てきました。たとえば、React Native v40で破壊的な変更があり、アプリをアップグレードしたときに、まだ更新されていなかった3〜4個のライブラリを修正するためにPRを提出しなければなりませんでした。

今後の展望​

React Nativeが成長し続ける中で、私たちのコミュニティへのウィッシュリストは次のとおりです。

• ナビゲーションライブラリを安定させ、改善する
• React Nativeエコシステム内のライブラリのサポートを維持する
• プロジェクトにネイティブライブラリとブリッジモジュールを追加する体験を改善する

React Nativeコミュニティの企業や個人は、私たち全員が使用するツールを改善するために、時間と労力を喜んで提供してくれています。もしオープンソースに関わったことがないのなら、あなたが使用しているライブラリのコードやドキュメントの改善に取り組んでみてはいかがでしょうか。始めるのに役立つ記事はたくさんありますし、思っているよりもずっと簡単かもしれません！