Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
2019-06-01_10-10_oretoku_frontend.pdf
ryota0624
June 12, 2019
0
21
2019-06-01_10-10_oretoku_frontend.pdf
ryota0624
June 12, 2019
Tweet
Share
More Decks by ryota0624
See All by ryota0624
ryota0624
0
79
ryota0624
0
930
ryota0624
2
1.6k
Featured
See All Featured
kneath
219
15k
gr2m
83
11k
skipperchong
8
710
michaelherold
225
8.5k
pauljervisheath
195
15k
caitiem20
308
17k
jonrohan
1021
380k
destraynor
146
19k
mojombo
359
62k
bryan
31
3.4k
stephaniewalter
260
11k
ammeep
655
54k
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らしくない自分達のアプリ ケーションに当てはめてもうまく行くとは限らない 必要なのはページや状態構造/ライブラリに依存しないモジュール化 状態の構造はアプリケーションの要件/構造によってベターなものが 変わるので自分達に合うものを選ぶ努力をしましょう