Upgrade to Pro — share decks privately, control downloads, hide ads and more …

N予備校とWebフロントエンドの新陳代謝 / iCARE Dev Meetup #30

berlysia
February 16, 2022
11k

N予備校とWebフロントエンドの新陳代謝 / iCARE Dev Meetup #30

berlysia

February 16, 2022
Tweet

Transcript

  1. 誰 - berlysia (べるりしあ、と読む) - Webとアイマスが両本業 - JSConf JP 2021で発表

    - Webフロントエンドのリプレースを支える テストの考え方 - ドワンゴ教育事業のWebフロント担当 - Webフロントをやる人 - Webフロントのためにいろいろやる人
  2. v1 リリース当初の実装 諸事情💀で実装パターンが入り乱れていた - Rails view - Page.js + jQuery

    on Rails view - CoffeeScriptでjQuery on Rails view - React + Redux + Redux Thunk + 独自ミドルウェア on Rails view ヤバいな、と思っていただければ十分
  3. v2 綺麗な世界を作ろうとした実装 v1の状況をマズいと思ったのか: - React + RxJSで独自の状態管理機構を作った - Reduxの機能は確かにRxJSのscanオペレーターに近い -

    モジュール間の依存を綺麗に定義しようとした - React以外のライブラリに移行できるように計画した しかし1画面作ってみて: - デファクトスタンダードから遠いなどの理由で断念 - 属人性が高くなりすぎることを嫌った
  4. v3 今に連なる素朴なSPA実装の登場 大規模フロントエンド開発のデファクトに倣って: - React + Redux - ミドルウェアにRedux Observable

    - WebSocketを含む複雑な非同期処理の要求に応えるため - flowtypeで型付きの開発 - 当時まだTSはいろいろ整っていなかったという判断 - リポジトリもRailsから分離して身軽に - 今では当たり前の基本的なお作法が導入される - Reducerに副作用を書かない、など
  5. v3のTypeScript化 - 2018年末に2週間ほどかけ一斉に書き換え - 手分けして自動変換をかけつつ漏れた分やエラーを手動修正 - 一旦TSLintを導入するも、ESLintにすぐ移行した - ちょうどTSLintの非推奨ロードマップ が出る頃だった

    なぜflowtypeをやめたか: - ライブラリの型定義がなさすぎた - RxJSでさえflow-typedにPRを送りながらライブラリを使っていた - TypeScriptや周辺ツール群の進化 - strictNullChecksオプションやBabelプラグインの登場 当時国内にあまり事例がない段階でTS化を完了
  6. v3にReact Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが: - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた

    - チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと: - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい
  7. Webフロントエンドで何を大事にするか Webフロントエンドで変化せずにいることは普通できない、なぜなら: - ユーザーやビジネスの要求 - デザイン変更やAPI変更 - ブラウザやWeb標準の変化 - 各種ライブラリの進化や陳腐化

    - セキュリティ、パフォーマンス、アクセシビリティ、etc… 現状を維持するためだけでも、外界に合わせて変化しないといけない より前に進んでいきたければ、なおさら変化が求められる より変化しやすくするために、どんな状態を目指すか?
  8. 反省:要求を捌ける強い仕組みの弊害 - v3は、v2の反省でデファクトスタンダードに寄せた構成を目指した - これは当時の時点では達成された - 一番複雑な画面を表現可能な構成で全体をカバーしようとした - これが無理を各画面に振りまいていった -

    ボイラープレートな実装をいやというほど書かされた - 実装者はやがて疲れていき、秩序が乱れていった 複雑なドメインを備えているのはごく一握りの画面だけだった たいていは、GETリクエストのレスポンスに色を付けて出せればよく、 ユーザーの操作でリクエストをしたり、ページ遷移できればよいと気付いた
  9. 最近の状態管理のトレンド - グローバル/コンポーネントローカルな状態の使い分け - Reduxに代表されるSingle source of truthな道具 - useState/useContextのようなライブラリの素朴な道具

    - Recoilやjotaiのような、コンポーネントツリーと別に状態のツリーがある道具 - 状態というよりAPIリクエストのキャッシュとして扱う - React QueryやSWR、RTK Queryのような道具 - apolloやrelayのGraphQLクライアントもこの機能を持つ - そもそもブラウザの上で長期間管理しない - SSRやSGのような方法で、サーバーやエッジでの処理を中心にする Reactを取り巻く状態管理の潮流を学ぼう。 HooksやServer Componentsなどの登場で何が変わるか - エンジニアHub|Webエンジニアのキャリアを考える!
  10. 再掲)React Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが: - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた

    - チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと: - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい
  11. N予備校Webフロントで選んでいること 「犠牲的アーキテクチャ」 (JP) →コードに寿命があることを認め、そのつもりで交換可能な作りにする Webフロントエンドで寿命が来るときとは: - 外観や操作性の要求が変わる - バックエンドが持っている概念が変わる -

    パフォーマンス要求のためにやり方を変える - より適していそうなやり方・道具に乗り換える - etc… 自分たちでコードの寿命を定め、必要に応じて置き換え続ける ⇒Webフロントエンドの「新陳代謝」