Yuri’s Tech Note

技術系アウトプット

React Native for Web / dom 関連の記事多読まとめ

f:id:yuri_iOS:20180717205642p:plain
記事一覧

  • React NativeをWebに持ってくることの意味
  • react-native-web と react-native-dom
  • GitHub - vincentriemer/react-native-dom
  • GitHub - necolas/react-native-web
  • react-native-dom の何がすごいのか
  • Web最新技術がてんこ盛りのreact-native-domから目が離せない



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


React Native for Web 概念関連記事

✒︎React NativeをWebに持ってくることの意味

要点

・ブラウザはそもそもドキュメントビューアであり、アプリのランタイムではない。
・React Nativeはプラットフォームを限定しない抽象化を行なっているため、
 react-native-windowsやreact-native-macosなど
 様々なプラットフォームの抽象化を実現化できている。
 まさに "learn once write anywhere"
・React Native for Webは、ネイティブアプリをブラウザ上で再現しようとしたものではなく、
 React Nativeが提唱したGUIの抽象化を、Webアプリケーションの世界でも使えるようにした、
 ブラウザ向けのReactコンポーネント&便利モジュール集ライブラリである。
・事例としてはTwitter Liteが挙げられる。
・React Nativeによって抽象化された「モバイルアプリ開発の当たり前」をブラウザの世界に持ち込んでくれる存在。

まとめ

もともとReact Natibeは "Webの技術であったReactをモバイルで使えるようにしたにもの" という発祥であったがゆえに "Webに回帰するなんておかしいのではないか" という意見もあった。
しかし、そもそもReact Nativeは様々なプラットフォームの抽象化を実現化したものであるのでWebでReact Nativeを動かそうという発想自体が理にかなったものであるということがわかり、技術を採用するにあたり不安を払拭することができた。

react-native-dom 概念関連記事

✒︎react-native-web と react-native-dom

要点

・react-native-domは既存のreact-nativeの仕組みを使ってさらに新しいプラットフォームをターゲットとする。
・react-native-webはreact-nativeという本来アプリを作るための基盤・コンポーネントを、Webでも動かせるようにしたもの。

..........理解できなかったので一旦本家リポジトリで各自の説明を読み比べてみる。



✒︎GitHub - react-native-dom
マルチスレッド
モバイルのReact Nativeと全く同じ仕組みでコンポーネントやロジックはweb workerによって実行される。
(web worker: JavaScriptにスレッド機能を提供することでWeb コンテンツがスクリプトをバックグラウンドのスレッドで実行可能にする手段)

モバイルのReact Nativeと同じレイアウトの挙動
yogaへのカスタムバインディングを使い、webアセンブリコンパイルすることでネイティブでもwebでも同じレイアウトを実現させる。
(yoga: クロスプラットフォームを意識して作られてたレイアウトエンジン)

既存のReact Nativeと同じバンドラで構築されている
React Nativeで使用されているJavaScriptのbundlerであるMetroを使用しており、ネィティブとJSが別スレッドでJS関連(ホットローディングなど)のビルドは早く、開発者にとっても良い体験を提供する。
(bundler: gem同士の互換性を保ちながらパッケージの種類やバージョンを管理してくれる仕組みのこと)

DOMの循環
同じネイティブモジュールブリッジを使用することで... 既存のReact Nativeのモジュールを使うことができるよね。というようなことを言っているとおもうのだが曖昧。

react-native-domのinitial commitは2017年の6月。
発表されたのは2018年5月のReactEurope2018なので今の所大きな変更が起こる可能性は多いにある。



✒︎[GitHub - react-native-web
高品質のインターフェース
JavaScriptで高速かつ柔軟なWeb UIを作ることができる。
ネイティブ品質のインタラクション、複数の入力モード(タッチ、マウス、キーボード)のサポート、最適化されたベンダープレフィックススタイル、RTLレイアウトのビルトインサポート、組み込みのアクセシビリティ、React Dev Toolsとの統合を提供する。

Write once, render anywhere
既存のReact DOMコンポーネントと相互運用し、React Native APIの大半と互換性があるため、既存のコードを書き直すことなく、ネイティブおよびWeb用の新しいコンポーネントを開発できる。

導入事例は既にあり、TwitterをはじめUberメジャーリーグサッカーやプレステなどが挙げられる。
ブラウザはChromeFirefox、Edge、Safari 7以上、IE 10以上に対応。



✒︎react-native-dom の何がすごいのか

要点

・react-native-domのすごいことはブリッジの仕組みにのっとって構築されているということ

ブリッジ

ブリッジとはJSとネィティブの処理を成立させるための仕組みであるが、実現する上でで課題となることが2つある。

ブリッジを実現する際の課題

1: リソースの競合
2: JSとネィティブ間のやりとりのすべての往復に伴う一定のオーバーヘッドがある
f:id:yuri_iOS:20180804140228p:plain

ブリッジを実現するためのポイント

これらを解消するために意識しないといけないポイントが2つ
1: JSとネィティブ間のやりとりを非同期で行うこと
2: JSとネィティブ間のやりとりによるスレッド間通信オーバーヘッドを最小限に抑えること

ブリッジの仕組み

・ブリッジはReact Nativeがもつ3つのスレッド(下記参照)の実行と、JSからネイティブ機能を呼び出す際、キューへのタスク追加、またネイティブからJS機能を呼び出す際にキューへのタスク追加を行う

スレッド1: シャドウキュー(コンポーネント再配置時に使用)
スレッド2: メインスレッド(UIKitが使用)
スレッド3: JSスレッド(開発者が書いたJSコードが動く。主にレンダリングを行う)

JavaScript スレッドとその他スレッドはそれぞれ機能呼び出しを媒介しているキューが存在し、キューに積まれたタスクを各スレッドが消化していって JS 層とネイティブ層の連携がなされている


・このブリッジ仕組みをreact-native-domではWeb Workerをスレッドとして使用することで実現
・Web Workerをスレッドとして使用することで実現
レンダリングスレッドを Yoga の DOM 実装ベースで作っている

まとめ

私にとって魅力的にうつったのはコンポーネントベース開発の加速
atomic design でいうところの atoms や molecules はプラットフォーム共通のコンポーネントを使い、OrganismsやTemplateのみ各プラットフォームにあわせて作成する。
これを実現するためにフォルダ構成を粒度単位でわけることを進めていきたいと考えた。

また、既存のReact Nativeプラットフォームに使用されているのと同じバンドラで構築されているためにwebpackなども必要なく、本当にReact Nativeと同じ感覚での開発をすることができそうである。




✒︎Web最新技術がてんこ盛りのreact-native-domから目が離せない
・React Native向けのUIライブラリや各種モジュールが、ブラウザ上でも動く
・React Nativeは UIスレッドと別にJavaScriptを実行するためのバックグラウンドスレッドを持っていて、react-natieve-domではWeb Workerの中でReactアプリケーションを動かす ことで、ブラウザ上であるにも関わらずReact Nativeの2スレッド制を完全再現している
・レイアウト計算をするYogaをWebで実現
Yoga: AndroidiOSといったプラットフォーム上でFlexboxによるレイアウト計算する

まとめ

噛み砕けていないが、webのviewを完璧にネィティブのViewだとして扱わせることに成功しているということだと思う。
故にReact Nativeで使っていたモジュールが使えて、しかもWeb workerを使ってブラウザ上でマルチスレッドを実現しているので処理速度的にも問題ないものが出来上がっており、その内情はメンテ性などを顧みないかなりゴリ押しな面があるが大いに期待できるものである。