Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2019-06-01_10-10_oretoku_frontend.pdf
Search
ryota0624
June 12, 2019
0
78
2019-06-01_10-10_oretoku_frontend.pdf
ryota0624
June 12, 2019
Tweet
Share
More Decks by ryota0624
See All by ryota0624
techtalk5-su
ryota0624
0
1.1k
kyash-meetup-vol7-suzuki.pdf
ryota0624
0
240
2019-03-30_11-49_architecture_night.pdf
ryota0624
0
1.7k
実践GraphQL for クライアント側
ryota0624
2
2.5k
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
690
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Side Projects
sachag
455
42k
Why Our Code Smells
bkeepers
PRO
336
57k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
4 Signs Your Business is Dying
shpigford
184
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Transcript
タイガー & ドラゴン
わたし すずき twitter: @4245Ryomt SPA歴 = エンジニア歴 Elm / Elm
/ React & Typescrpt / Vueも嗜んだ 広告運用画面だったりSaaSのダッシュボード作るマン
今日のテーマ 俺得
今日のテーマ 俺得 SPAに疲れた!愚痴を聞いて欲しい!
今日のテーマ SPAの状態管理に疲れた。 最近こんなこと思っているんだけど聞いて欲しい...
なんでSPAやってるんだっけ? サーバサイドからクライアント事情を切り離す 画面遷移で画面真っ白うざい ブラウザ上でいい感じのUIをグリグリさせるため サーバサイドの負荷減らす(?) SPAで作った方が開発が早い
なんでSPAやってるんだっけ? サーバサイドからクライアント事情を切り離す わかる。
なんでSPAやってるんだっけ? 画面遷移で画面真っ白うざい ま、まあセヤナ... ブラウザ上でいい感じのテーブル/フォームをグリグリさせるため SPAじゃなくても良くない...?
なんでSPAやってるんだっけ? サーバサイドの負荷減らす(?) ほんとに? ユーザ操作に合わせて常に正しい情報を伝えようと思ったらそ の都度サーバに問い合わせ行くからさしてかわらなくない? むしろフロントエンドで「リソースaが存在してたら取りに行 かない^^」はバグの温床
なんでSPAやってるんだっけ? SPAで作った方が開発が早い 俺たちフロントエンドはそうだよな!
俺の作ってる(引き継いだ)アプリケーションは本当にSPAだった必要は あるのか... ページごとにhtmlつくってJSがそれぞれのページごとに頑張る。それで よかったのでは..? なんて思いながらSPAを作っている htmlをページごとに用意するよりJSでその辺いい感じにする方が手が早 いのもまた事実ではある しかしページ間で状態が共有される。/ リソースが常にリフレッシュされ ない。
ことでトラブルが起きる...
前振り終わり
SPAでこんな辛い思いしてきたよ 壊れる状態
壊れる状態とは? こんなことありません? ページA ‑> B ‑> C ‑> Aで遷移したら なんか動かなくなった
ページBでXを 削除した のにページAで 出てきた
壊れる状態 意図しないリモート上のデータ組み合わせが起きる
壊れる状態と壊れないために頑張る人間 データフェッチし忘れ リモート上から削除されているデータを持ってる(整合性が壊れる) リモート上のデータ更新にどこまで追従するよ
頑張る人間 間違っちゃったで壊れる状態 とくにユニフロー(vuexとかreduxのアレ)を採用していると fetch自体とそれを必要とする場所が分離されるため間違っち ゃう コンパイラは助けてくれない テスト書けばfetch系を呼び出していることは担保できそう テストを書いているか胸に聞いてみてほしい リモート上のデータに追従して整合性保つのは大変 リソースが更新された時、一緒になって更新されるリソースを
全部更新、再取得するようなコードを書くかい? 間違って漏れちゃう
リモート上のデータを整合性壊さないように 丁寧に扱うのは難しい なぜこんな難しいことをしているだっけ? それがSPAだからさ そうやって作っているのさ
ほんとうにそうか? なんで壊れちゃうのか考えてみた
トップレベルに並べられるリモートリソース の状態 { resourceA: ..., resourceB: ...., resourceOther: ..., resourceOther2:
..., } 無条件にやられるコレ ドメインデータだからページと切り離すゾイ! 共通ロジックがあるからやるぜ!
徐々に辛くなる状態構成 リソースにページングという概念がでてきたら辛くなりそうな気配 リソースの種類/関連がぱっと見でわからなってきた viewと分離されているとはいえ様々な文脈から操作される もちろんそれがベターなケースもあるよ
どうすればいいんだろう(><) 頑張る
どうすればいいんだろう ‑> ぼくはこうした よ! https://speakerdeck.com/ryota0624/2019‑03‑30‑11‑49‑ architecture‑night
どうすればいいんだろう ‑> ぼくはこうした よ! まず無条件にトップレベルにリソースならべてみるのをやめる ページ間で状態が共有されているゆえのデータ不整合は起きなくな る ページにあるリソース = ページにとって必要な文脈
が強要できる { pageA: { resourceA:..., resourceB:... }, pageB: { resourceA:..., resourceOther:... }, }
共通ロジックとかが... ロジック自体は状態の居場所と関係ない 状態の置き場所と密にならないモジュール化
ページごとにリソースも状態をわける 極論いつでもページごとにアプリケーションが分けられるように作 る
うまくいったの? 当時は(退職前) データ不整合でバグるとかなかった Elmのおかげもある
本日お伝えしたかったこと SPAのプラクティスだぜアレソレをSPAらしくない自分達のアプリ ケーションに当てはめてもうまく行くとは限らない 必要なのはページや状態構造/ライブラリに依存しないモジュール化 状態の構造はアプリケーションの要件/構造によってベターなものが 変わるので自分達に合うものを選ぶ努力をしましょう