2019-06-01_10-10_oretoku_frontend.pdf

Transcript

1. タイガー & ドラゴン

2. わたし すずき twitter: @4245Ryomt SPA歴 = エンジニア歴 Elm / Elm

   / React & Typescrpt / Vueも嗜んだ 広告運用画面だったりSaaSのダッシュボード作るマン

3. 今日のテーマ 俺得

4. 今日のテーマ 俺得 SPAに疲れた！愚痴を聞いて欲しい!

5. 今日のテーマ SPAの状態管理に疲れた。 最近こんなこと思っているんだけど聞いて欲しい...

6. なんでSPAやってるんだっけ？ サーバサイドからクライアント事情を切り離す 画面遷移で画面真っ白うざい ブラウザ上でいい感じのUIをグリグリさせるため サーバサイドの負荷減らす(?) SPAで作った方が開発が早い

7. なんでSPAやってるんだっけ？ サーバサイドからクライアント事情を切り離す わかる。

8. なんでSPAやってるんだっけ？ 画面遷移で画面真っ白うざい ま、まあセヤナ... ブラウザ上でいい感じのテーブル/フォームをグリグリさせるため SPAじゃなくても良くない...?

9. なんでSPAやってるんだっけ？ サーバサイドの負荷減らす(?) ほんとに？ ユーザ操作に合わせて常に正しい情報を伝えようと思ったらそ の都度サーバに問い合わせ行くからさしてかわらなくない？ むしろフロントエンドで「リソースaが存在してたら取りに行 かない^^」はバグの温床

10. なんでSPAやってるんだっけ？ SPAで作った方が開発が早い 俺たちフロントエンドはそうだよな！

11. 俺の作ってる(引き継いだ)アプリケーションは本当にSPAだった必要は あるのか... ページごとにhtmlつくってJSがそれぞれのページごとに頑張る。それで よかったのでは..? なんて思いながらSPAを作っている htmlをページごとに用意するよりJSでその辺いい感じにする方が手が早 いのもまた事実ではある しかしページ間で状態が共有される。/ リソースが常にリフレッシュされ ない。

    ことでトラブルが起きる...

12. 前振り終わり

13. SPAでこんな辛い思いしてきたよ 壊れる状態

14. 壊れる状態とは？ こんなことありません？ ページA ‑> B ‑> C ‑> Aで遷移したら なんか動かなくなった

    ページBでXを 削除した のにページAで 出てきた

15. 壊れる状態 意図しないリモート上のデータ組み合わせが起きる

16. 壊れる状態と壊れないために頑張る人間 データフェッチし忘れ リモート上から削除されているデータを持ってる(整合性が壊れる) リモート上のデータ更新にどこまで追従するよ

17. 頑張る人間 間違っちゃったで壊れる状態 とくにユニフロー(vuexとかreduxのアレ)を採用していると fetch自体とそれを必要とする場所が分離されるため間違っち ゃう コンパイラは助けてくれない テスト書けばfetch系を呼び出していることは担保できそう テストを書いているか胸に聞いてみてほしい リモート上のデータに追従して整合性保つのは大変 リソースが更新された時、一緒になって更新されるリソースを

    全部更新、再取得するようなコードを書くかい？ 間違って漏れちゃう

18. リモート上のデータを整合性壊さないように 丁寧に扱うのは難しい なぜこんな難しいことをしているだっけ？ それがSPAだからさ そうやって作っているのさ

19. ほんとうにそうか？ なんで壊れちゃうのか考えてみた

20. トップレベルに並べられるリモートリソース の状態 { resourceA: ..., resourceB: ...., resourceOther: ..., resourceOther2:

    ..., } 無条件にやられるコレ ドメインデータだからページと切り離すゾイ! 共通ロジックがあるからやるぜ!

21. 徐々に辛くなる状態構成 リソースにページングという概念がでてきたら辛くなりそうな気配 リソースの種類/関連がぱっと見でわからなってきた viewと分離されているとはいえ様々な文脈から操作される もちろんそれがベターなケースもあるよ

22. どうすればいいんだろう(><) 頑張る

23. どうすればいいんだろう ‑> ぼくはこうした よ！ https://speakerdeck.com/ryota0624/2019‑03‑30‑11‑49‑ architecture‑night

24. どうすればいいんだろう ‑> ぼくはこうした よ！ まず無条件にトップレベルにリソースならべてみるのをやめる ページ間で状態が共有されているゆえのデータ不整合は起きなくな る ページにあるリソース = ページにとって必要な文脈

    が強要できる { pageA: { resourceA:..., resourceB:... }, pageB: { resourceA:..., resourceOther:... }, }

25. 共通ロジックとかが... ロジック自体は状態の居場所と関係ない 状態の置き場所と密にならないモジュール化

26. ページごとにリソースも状態をわける 極論いつでもページごとにアプリケーションが分けられるように作 る

27. うまくいったの？ 当時は(退職前) データ不整合でバグるとかなかった Elmのおかげもある

28. 本日お伝えしたかったこと SPAのプラクティスだぜアレソレをSPAらしくない自分達のアプリ ケーションに当てはめてもうまく行くとは限らない 必要なのはページや状態構造/ライブラリに依存しないモジュール化 状態の構造はアプリケーションの要件/構造によってベターなものが 変わるので自分達に合うものを選ぶ努力をしましょう