search

ogakuzuko / output

学んだことをログとして残しておく場所（試験運用 → 廃止）
0 stars 0 forks source link

【学び】Reactは何を提供するLibraryなのか？ #11

Open ogakuzuko opened 2 years ago

ogakuzuko commented 2 years ago

参考リスト

ogakuzuko commented 2 years ago

Reactの構造

Reactのリポジトリ（これ）の中で、Reactに関わる重要な部分は以下の3つとのこと。

  • Core（react）
    • Componentの定義に必要なAPI（useStateなどのhooksやFC、ReactNodeなど）
  • Renderer（react-dom, react-native-renderer）
    • Component Treeをプラットフォーム固有のHost(=各プラットフォームごとの描画する対象(DOM, Native View))に変換
  • Reconciler（react-reconciler）
    • 仮想DOM(*1)の管理・差分検出
    • *1 ... 仮想DOMは、宣言的UIの構築におけるパフォーマンスの問題を解決するための技術

【📝 NOTE】 Reconcilerが差分検出を行なっているのは度々見るから理解してはいたのだけれど、その差分検出して導き出された再描画対象をRendererに伝える役割も持っていたのか。

Reconcilerで差分を検出して、そこから判定された再描画対象をRendererがDOMに変換する流れを取るのね。


(↓)とてもわかりやすかったReactの構造図（出典：Reactは何を提供するLibraryなのか？(19ページ目)） Core部分とReconcilerはWeb, Native問わず各Rendererで共通して用いられる。

CleanShot 2022-07-06 at 15 17 36@2x

共通して使うのはCore（Componentの定義に必要なAPI）とReconciler（仮想DOMの管理・差分検出）の2つ → Reactが提供するのはComponentベースな宣言的UIの構築のみ（プラットフォームには依存しない）

Reactは何を提供するLibraryなのか？

  • Componentベース
    • JSX
  • 宣言的
    • JSX
    • Flux Architecture(2014.5), Stateless Functional Component(2015.10), Hooks(2019.02), Suspense(2022.03)
  • プラットフォーム共通の方法
    • React Native(2015.03)
    • Web用のコードがreact-domに移動(2015.10)

でのUIの構築を提供するLibrary

【📝 NOTE】 何に(どこに)レンダリングするかは問わず、内部のコンポーネント実装機構と仮想DOM機構のみを提供することで、その適用範囲というか汎用性を広げている感じなんだろうか。

ここまで読むと、React公式のトップに書いてあるReactの特徴「宣言的なView」と「コンポーネントベース」っていうのがとても腹落ちして理解できた気がする。

あとこれ見て驚いたのは、今では当たり前に使う 関数コンポーネント(Functional Component) って最近できたものではなくて、Reactの初期の段階である2015年にはもうあったんだということ。 あったにはあったけど、ステートレスである関数ゆえに「状態」を保持することが出来なかったためにクラスコンポーネントが台頭していたといことだろうね。ただ、そこに2019年革新的なHooksというものが誕生し、関数コンポーネントでも擬似的に(?)「状態」を扱うことが可能になり、一気にこれまで日の目を見なかった関数コンポーネントの流れが出来たということなんだね。Hooksの誕生って本当に凄いことだったんだなと改めて実感した。

Reactの年表についてはこちら（React今昔物語）の記事がわかりやすくまとまっていて良い感じだった。👀


ソフトウェア開発におけるReactの役割

ReactはComponentベースな宣言的UIの構築を提供するLibrary → なぜ「UI」ではなく「UIの構築」なのか？ どんなUIを提供するかは開発者が決める Reactはそれ(UI)をどうやって実現するか(構築するか)の責任を持つ

React開発者としての皆さんはユーザー体験をどんな見た目にしたいかを考えることに集中し、その見た目をどのように実現するのかはReactが受け持ちます。

【📝 NOTE】 これは凄いReactの思想的な部分を感じるところで良いなあ。あくまでUIとしての部品を作りやすくする手助けをするだけであって、ReactがUI自体を提供するわけではないということ。 これがReactが「ライブラリ」と呼ばれる所以なのかもしれないね。どう使うか(使い方)は使う人に任されているといような感じ。似た言葉でよく挙げられる「フレームワーク」はどう使うか(使い方)を使う人に強制するとよく言われるよね。


UIはユーザーがシステムを操作する窓口的なもの

  • Why(何のためのUIか？) → 開発者が担う
  • What(どんなUIか) → 開発者が担う
  • How(どうやってUIを作るか(*1)) → Reactが担う
    • *1 ... どうやってUIを作るか → 宣言的に、コンポーネントベースで、プラットフォーム共通な方法で高いUXのUIを作れる

【📝 NOTE】 「UIはユーザーがシステムを操作する窓口」 これはまさにだなと思った。ユーザーとシステムの間を繋ぐインターフェイスが「ユーザーインターフェース（UI）」だもんね。


これからReactが提供したいもの

スケジューリングされた高いUXのUI構築

React は汎用的なデータ処理ライブラリではありません。ユーザインターフェイスを構築するためのライブラリです。アプリ内において React は、どの計算が今すぐ必要でどの計算がそうでないのかを知ることができる特殊な位置づけにある、と私たちは考えています。

鍵はReact Fiber Reconciler(V16~ from 2017.09) 同期的だった差分検出処理が、Fiberという作業単位に分割され非同期処理が可能に！

  • 優先度順に割り込み可
  • 中断可
  • 不要になった処理は破棄

→ レンダリング中でもユーザーの入力を反映することが可能に！

  • Concurrent Rendering(v18)
  • Automatic Batching(v18)
  • Suspense(v18)
  • Transition(v18) etc.

【📝 NOTE】 これからのReactは並行処理が肝になってくるとどこかの誰かが言っていたような気がするけれど、こうやって実際にReact v18における並行処理に周りの様々な機能の追加を見ると、いや本当にそうなんだなと実感せざるを得なくなるね。

最後の冗談として書いてあったReactチームの

React は完全に「リアクティブ」であることを望んでいないため、React は “Schedule” と呼ばれるべきだったというチーム内の冗談があります。

って話面白いね。笑

確かに、ユーザーの入力に必ず応答して対応するのが「リアクティブ」だとするならば、ユーザーの入力の中でも優先度の高い入力と優先度の低い入力を見分けて、その処理の優先度に応じて処理を実行順序を決める場合、 「完全にリアクティブ」 ではないもんね。笑


このスライド大変学びになった。そしてもっとReactが好きになった。やっぱりその技術の思想系を深堀りするようなものは読んでいて楽しい。☺️