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

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

berlysia
February 16, 2022
9.8k

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

berlysia

February 16, 2022
Tweet

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高等学校プロジェクト採用 | 株式会社ドワンゴ