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
73
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
970
kyash-meetup-vol7-suzuki.pdf
ryota0624
0
200
2019-03-30_11-49_architecture_night.pdf
ryota0624
0
1.6k
実践GraphQL for クライアント側
ryota0624
2
2.3k
Featured
See All Featured
How to Ace a Technical Interview
jacobian
275
23k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
The Invisible Side of Design
smashingmag
297
50k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
A designer walks into a library…
pauljervisheath
202
24k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Writing Fast Ruby
sferik
626
61k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Embracing the Ebb and Flow
colly
84
4.4k
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らしくない自分達のアプリ ケーションに当てはめてもうまく行くとは限らない 必要なのはページや状態構造/ライブラリに依存しないモジュール化 状態の構造はアプリケーションの要件/構造によってベターなものが 変わるので自分達に合うものを選ぶ努力をしましょう