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

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

View Slide

誰
- berlysia （べるりしあ、と読む）
- Webとアイマスが両本業
- JSConf JP 2021で発表
- Webフロントエンドのリプレースを支える
テストの考え方
- ドワンゴ教育事業のWebフロント担当
- Webフロントをやる人
- Webフロントのためにいろいろやる人

View Slide

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

View Slide

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

View Slide

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

View Slide

v1 リリース当初の実装
諸事情💀で実装パターンが入り乱れていた
- Rails view
- Page.js + jQuery on Rails view
- CoffeeScriptでjQuery on Rails view
- React + Redux + Redux Thunk + 独自ミドルウェア
on Rails view
ヤバいな、と思っていただければ十分

View Slide

v2 綺麗な世界を作ろうとした実装
v1の状況をマズいと思ったのか：
- React + RxJSで独自の状態管理機構を作った
- Reduxの機能は確かにRxJSのscanオペレーターに近い
- モジュール間の依存を綺麗に定義しようとした
- React以外のライブラリに移行できるように計画した
しかし1画面作ってみて：
- デファクトスタンダードから遠いなどの理由で断念
- 属人性が高くなりすぎることを嫌った

View Slide

v3 今に連なる素朴なSPA実装の登場
大規模フロントエンド開発のデファクトに倣って：
- React + Redux
- ミドルウェアにRedux Observable
- WebSocketを含む複雑な非同期処理の要求に応えるため
- flowtypeで型付きの開発
- 当時まだTSはいろいろ整っていなかったという判断
- リポジトリもRailsから分離して身軽に
- 今では当たり前の基本的なお作法が導入される
- Reducerに副作用を書かない、など

View Slide

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

View Slide

v3のTypeScript化
- 2018年末に2週間ほどかけ一斉に書き換え
- 手分けして自動変換をかけつつ漏れた分やエラーを手動修正
- 一旦TSLintを導入するも、ESLintにすぐ移行した
- ちょうどTSLintの非推奨ロードマップが出る頃だった
なぜflowtypeをやめたか：
- ライブラリの型定義がなさすぎた
- RxJSでさえflow-typedにPRを送りながらライブラリを使っていた
- TypeScriptや周辺ツール群の進化
- strictNullChecksオプションやBabelプラグインの登場
当時国内にあまり事例がない段階でTS化を完了

View Slide

v3にReact Queryを導入、Redux依存を減らす
全画面でReduxとRedux Observableを使っていたが：
- 単純な画面でもボイラープレートがあり面倒
- 面倒がって過剰に状態を共有してしまう実装が発生しがち
- レビューで指摘しそびれたものがのさばっていた
- チャンク分割と相性が悪い
- できないことはないが今度は型検査しづらい
React Queryに求めたこと：
- 素朴に取得とローディング周りを表現できる道具なこと
- Redux+Redux Observableの面倒さから脱却したい
- 共通実装への依存を減らし、画面ごとの独立度を増す
- 自然に他の画面のことを気にせず変更できる作りに寄せたい
- Suspenseを使ったデータ取得のお作法に移行しやすく
- Concurrent Renderingのような今後の進化に乗っていきたい

View Slide

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

View Slide

Webフロントエンドで何を大事にするか
Webフロントエンドで変化せずにいることは普通できない、なぜなら：
- ユーザーやビジネスの要求
- デザイン変更やAPI変更
- ブラウザやWeb標準の変化
- 各種ライブラリの進化や陳腐化
- セキュリティ、パフォーマンス、アクセシビリティ、etc…
現状を維持するためだけでも、外界に合わせて変化しないといけない
より前に進んでいきたければ、なおさら変化が求められる
より変化しやすくするために、どんな状態を目指すか？

View Slide

反省：要求を捌ける強い仕組みの弊害
- v3は、v2の反省でデファクトスタンダードに寄せた構成を目指した
- これは当時の時点では達成された
- 一番複雑な画面を表現可能な構成で全体をカバーしようとした
- これが無理を各画面に振りまいていった
- ボイラープレートな実装をいやというほど書かされた
- 実装者はやがて疲れていき、秩序が乱れていった
複雑なドメインを備えているのはごく一握りの画面だけだった
たいていは、GETリクエストのレスポンスに色を付けて出せればよく、
ユーザーの操作でリクエストをしたり、ページ遷移できればよいと気付いた

View Slide

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

View Slide

再掲）React Queryを導入、Redux依存を減らす
全画面でReduxとRedux Observableを使っていたが：
- 単純な画面でもボイラープレートがあり面倒
- 面倒がって過剰に状態を共有してしまう実装が発生しがち
- レビューで指摘しそびれたものがのさばっていた
- チャンク分割と相性が悪い
- できないことはないが今度は型検査しづらい
React Queryに求めたこと：
- 素朴に取得とローディング周りを表現できる道具なこと
- Redux+Redux Observableの面倒さから脱却したい
- 共通実装への依存を減らし、画面ごとの独立度を増す
- 自然に他の画面のことを気にせず変更できる作りに寄せたい
- Suspenseを使ったデータ取得のお作法に移行しやすく
- Concurrent Renderingのような今後の進化に乗っていきたい

View Slide

N予備校Webフロントで選んでいること
「犠牲的アーキテクチャ」 (JP)
→コードに寿命があることを認め、そのつもりで交換可能な作りにする
Webフロントエンドで寿命が来るときとは：
- 外観や操作性の要求が変わる
- バックエンドが持っている概念が変わる
- パフォーマンス要求のためにやり方を変える
- より適していそうなやり方・道具に乗り換える
- etc…
自分たちでコードの寿命を定め、必要に応じて置き換え続ける
⇒Webフロントエンドの「新陳代謝」

View Slide

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

View Slide

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

View Slide

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

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

berlysia

More Decks by berlysia

Featured

Transcript