Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
N予備校とWebフロントエンドの新陳代謝 / iCARE Dev Meetup #30
berlysia
February 16, 2022
1
9.3k
N予備校とWebフロントエンドの新陳代謝 / iCARE Dev Meetup #30
N予備校
N高等学校・S高等学校プロジェクト採用 | 株式会社ドワンゴ
iCARE Dev Meetup #30
berlysia
February 16, 2022
Tweet
Share
More Decks by berlysia
See All by berlysia
Webフロントエンドのリプレースを支えるテストの考え方 / JSConf JP 2021
berlysia
15
8.5k
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
349
27k
Thoughts on Productivity
jonyablonski
43
2.2k
Build your cross-platform service in a week with App Engine
jlugia
219
17k
Keith and Marios Guide to Fast Websites
keithpitt
404
21k
Code Review Best Practice
trishagee
41
6.8k
The Most Common Mistakes in Cover Letters
jrick
PRO
4
24k
Web Components: a chance to create the future
zenorocha
303
40k
Designing with Data
zakiwarfel
91
3.9k
Teambox: Starting and Learning
jrom
121
7.6k
GraphQLの誤解/rethinking-graphql
sonatard
24
6.2k
jQuery: Nuts, Bolts and Bling
dougneiner
56
6.4k
Transcript
N予備校と Webフロントエンドの新陳代謝 @berlysia / iCARE Dev Meetup #30
誰 - berlysia (べるりしあ、と読む) - Webとアイマスが両本業 - JSConf JP 2021で発表
- Webフロントエンドのリプレースを支える テストの考え方 - ドワンゴ教育事業のWebフロント担当 - Webフロントをやる人 - Webフロントのためにいろいろやる人
お品書き - N予備校のWebフロントエンドのあゆみ - やってきたこと~直近やっていること - N予備校のWebフロントエンドの新陳代謝 - 今の私たちの考え方 具体的な道具の細かいはなしはしません
教材・生授業・Q&Aをスマホにも最適化した オールインワン受験アプリ スマホに最適化された 教材 なかまと受ける 双方向生授業 なかまと話し教え 高め合いができる場所 N予備校
https://www.nnn.ed.nico/pages/introduction/feature/
N予備校Webフロントエンド約6年のあゆみ
v1 リリース当初の実装 諸事情💀で実装パターンが入り乱れていた - Rails view - Page.js + jQuery
on Rails view - CoffeeScriptでjQuery on Rails view - React + Redux + Redux Thunk + 独自ミドルウェア on Rails view ヤバいな、と思っていただければ十分
v2 綺麗な世界を作ろうとした実装 v1の状況をマズいと思ったのか: - React + RxJSで独自の状態管理機構を作った - Reduxの機能は確かにRxJSのscanオペレーターに近い -
モジュール間の依存を綺麗に定義しようとした - React以外のライブラリに移行できるように計画した しかし1画面作ってみて: - デファクトスタンダードから遠いなどの理由で断念 - 属人性が高くなりすぎることを嫌った
v3 今に連なる素朴なSPA実装の登場 大規模フロントエンド開発のデファクトに倣って: - React + Redux - ミドルウェアにRedux Observable
- WebSocketを含む複雑な非同期処理の要求に応えるため - flowtypeで型付きの開発 - 当時まだTSはいろいろ整っていなかったという判断 - リポジトリもRailsから分離して身軽に - 今では当たり前の基本的なお作法が導入される - Reducerに副作用を書かない、など
v2がv3によって置き換えられ、滅亡 - v2は結局1画面しか作られなかった - v3の能力が確認され、すべてをv3化していくと確認 - 一番複雑な画面を綺麗に実装できたので
v3のTypeScript化 - 2018年末に2週間ほどかけ一斉に書き換え - 手分けして自動変換をかけつつ漏れた分やエラーを手動修正 - 一旦TSLintを導入するも、ESLintにすぐ移行した - ちょうどTSLintの非推奨ロードマップ が出る頃だった
なぜflowtypeをやめたか: - ライブラリの型定義がなさすぎた - RxJSでさえflow-typedにPRを送りながらライブラリを使っていた - TypeScriptや周辺ツール群の進化 - strictNullChecksオプションやBabelプラグインの登場 当時国内にあまり事例がない段階でTS化を完了
v3にReact Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが: - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた
- チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと: - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい
再掲)N予備校Webフロントエンド約6年のあゆみ
Webフロントエンドで何を大事にするか Webフロントエンドで変化せずにいることは普通できない、なぜなら: - ユーザーやビジネスの要求 - デザイン変更やAPI変更 - ブラウザやWeb標準の変化 - 各種ライブラリの進化や陳腐化
- セキュリティ、パフォーマンス、アクセシビリティ、etc… 現状を維持するためだけでも、外界に合わせて変化しないといけない より前に進んでいきたければ、なおさら変化が求められる より変化しやすくするために、どんな状態を目指すか?
反省:要求を捌ける強い仕組みの弊害 - v3は、v2の反省でデファクトスタンダードに寄せた構成を目指した - これは当時の時点では達成された - 一番複雑な画面を表現可能な構成で全体をカバーしようとした - これが無理を各画面に振りまいていった -
ボイラープレートな実装をいやというほど書かされた - 実装者はやがて疲れていき、秩序が乱れていった 複雑なドメインを備えているのはごく一握りの画面だけだった たいていは、GETリクエストのレスポンスに色を付けて出せればよく、 ユーザーの操作でリクエストをしたり、ページ遷移できればよいと気付いた
最近の状態管理のトレンド - グローバル/コンポーネントローカルな状態の使い分け - 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エンジニアのキャリアを考える!
再掲)React Queryを導入、Redux依存を減らす 全画面でReduxとRedux Observableを使っていたが: - 単純な画面でもボイラープレートがあり面倒 - 面倒がって過剰に状態を共有してしまう実装が発生しがち - レビューで指摘しそびれたものがのさばっていた
- チャンク分割と相性が悪い - できないことはないが今度は型検査しづらい React Queryに求めたこと: - 素朴に取得とローディング周りを表現できる道具なこと - Redux+Redux Observableの面倒さから脱却したい - 共通実装への依存を減らし、画面ごとの独立度を増す - 自然に他の画面のことを気にせず変更できる作りに寄せたい - Suspenseを使ったデータ取得のお作法に移行しやすく - Concurrent Renderingのような今後の進化に乗っていきたい
N予備校Webフロントで選んでいること 「犠牲的アーキテクチャ」 (JP) →コードに寿命があることを認め、そのつもりで交換可能な作りにする Webフロントエンドで寿命が来るときとは: - 外観や操作性の要求が変わる - バックエンドが持っている概念が変わる -
パフォーマンス要求のためにやり方を変える - より適していそうなやり方・道具に乗り換える - etc… 自分たちでコードの寿命を定め、必要に応じて置き換え続ける ⇒Webフロントエンドの「新陳代謝」
未来の「当たり前」の教育をつくる Vision / Mission ほんの少し先の未来、 ネットで学ぶときに「当たり前」とされるようなサービスを創るのは、 私たちにしかできない。 日々そう考えて企画開発しています。 それは教育の「当たり前」を変えること。 この前人未到の挑戦に、加わってみませんか。
採用情報 お話ししましょう 各技術業種で募集中です N高等学校・S高等学校プロジェクト採用 | 株式会社ドワンゴ