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

Transcript

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

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

   - Webフロントエンドのリプレースを支える テストの考え方 - ドワンゴ教育事業のWebフロント担当 - Webフロントをやる人 - Webフロントのためにいろいろやる人

3. お品書き - N予備校のWebフロントエンドのあゆみ - やってきたこと～直近やっていること - N予備校のWebフロントエンドの新陳代謝 - 今の私たちの考え方 具体的な道具の細かいはなしはしません

4. 教材・生授業・Q&Aをスマホにも最適化した オールインワン受験アプリ スマホに最適化された 教材 なかまと受ける 双方向生授業 なかまと話し教え 高め合いができる場所 N予備校 


   https://www.nnn.ed.nico/pages/introduction/feature/

5. N予備校Webフロントエンド約6年のあゆみ

6. v1 リリース当初の実装 諸事情💀で実装パターンが入り乱れていた - Rails view - Page.js + jQuery

   on Rails view - CoffeeScriptでjQuery on Rails view - React + Redux + Redux Thunk + 独自ミドルウェア on Rails view ヤバいな、と思っていただければ十分

7. v2 綺麗な世界を作ろうとした実装 v1の状況をマズいと思ったのか： - React + RxJSで独自の状態管理機構を作った - Reduxの機能は確かにRxJSのscanオペレーターに近い -

   モジュール間の依存を綺麗に定義しようとした - React以外のライブラリに移行できるように計画した しかし1画面作ってみて： - デファクトスタンダードから遠いなどの理由で断念 - 属人性が高くなりすぎることを嫌った

8. v3 今に連なる素朴なSPA実装の登場 大規模フロントエンド開発のデファクトに倣って： - React + Redux - ミドルウェアにRedux Observable

   - WebSocketを含む複雑な非同期処理の要求に応えるため - flowtypeで型付きの開発 - 当時まだTSはいろいろ整っていなかったという判断 - リポジトリもRailsから分離して身軽に - 今では当たり前の基本的なお作法が導入される - Reducerに副作用を書かない、など

9. v2がv3によって置き換えられ、滅亡 - v2は結局1画面しか作られなかった - v3の能力が確認され、すべてをv3化していくと確認 - 一番複雑な画面を綺麗に実装できたので

10. v3のTypeScript化 - 2018年末に2週間ほどかけ一斉に書き換え - 手分けして自動変換をかけつつ漏れた分やエラーを手動修正 - 一旦TSLintを導入するも、ESLintにすぐ移行した - ちょうどTSLintの非推奨ロードマップ が出る頃だった

    なぜflowtypeをやめたか： - ライブラリの型定義がなさすぎた - RxJSでさえflow-typedにPRを送りながらライブラリを使っていた - TypeScriptや周辺ツール群の進化 - strictNullChecksオプションやBabelプラグインの登場 当時国内にあまり事例がない段階でTS化を完了

11. v3にReact Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが： - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた

    - チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと： - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい

12. 再掲）N予備校Webフロントエンド約6年のあゆみ

13. Webフロントエンドで何を大事にするか Webフロントエンドで変化せずにいることは普通できない、なぜなら： - ユーザーやビジネスの要求 - デザイン変更やAPI変更 - ブラウザやWeb標準の変化 - 各種ライブラリの進化や陳腐化

    - セキュリティ、パフォーマンス、アクセシビリティ、etc… 現状を維持するためだけでも、外界に合わせて変化しないといけない より前に進んでいきたければ、なおさら変化が求められる より変化しやすくするために、どんな状態を目指すか？

14. 反省：要求を捌ける強い仕組みの弊害 - v3は、v2の反省でデファクトスタンダードに寄せた構成を目指した - これは当時の時点では達成された - 一番複雑な画面を表現可能な構成で全体をカバーしようとした - これが無理を各画面に振りまいていった -

    ボイラープレートな実装をいやというほど書かされた - 実装者はやがて疲れていき、秩序が乱れていった 複雑なドメインを備えているのはごく一握りの画面だけだった たいていは、GETリクエストのレスポンスに色を付けて出せればよく、 ユーザーの操作でリクエストをしたり、ページ遷移できればよいと気付いた

15. 最近の状態管理のトレンド - グローバル／コンポーネントローカルな状態の使い分け - 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エンジニアのキャリアを考える！

16. 再掲）React Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが： - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた

    - チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと： - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい

17. N予備校Webフロントで選んでいること 「犠牲的アーキテクチャ」 (JP) →コードに寿命があることを認め、そのつもりで交換可能な作りにする Webフロントエンドで寿命が来るときとは： - 外観や操作性の要求が変わる - バックエンドが持っている概念が変わる -

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

18. 未来の「当たり前」の教育をつくる Vision / Mission ほんの少し先の未来、 ネットで学ぶときに「当たり前」とされるようなサービスを創るのは、 私たちにしかできない。 日々そう考えて企画開発しています。 それは教育の「当たり前」を変えること。 この前人未到の挑戦に、加わってみませんか。

19. 採用情報 お話ししましょう 各技術業種で募集中です N高等学校・S高等学校プロジェクト採用 | 株式会社ドワンゴ