2019-03-30_11-49_architecture_night.pdf

51674cc4370048dd25b2e3bd148aa5f6?s=47 ryota0624
April 25, 2019
900

 2019-03-30_11-49_architecture_night.pdf

51674cc4370048dd25b2e3bd148aa5f6?s=128

ryota0624

April 25, 2019
Tweet

Transcript

  1. SPA状態設計(Elm)

  2. わたし twitter: @4245Ryomt HRBrainのエンジニア フロントエンド

  3. 今日話すこと 前職 で広告プロダクトの運用画面、審査画面やらを開発するとき に設計でやったこと 端的にやったこと 状態をページごとで構成した https://github.com/rtfeldman/elm‑spa‑example ↑をパクった

  4. お品書き SPAの難しさ ページごとにつくる

  5. SPAの難しさ 今日話すのはユーザからみるとリッチなwebページくらいに見える アプリケーション ◦: 運用画面, 管理画面 ✖ : twitter

  6. SPAの難しさ こんなことありません? ページA ‑> B ‑> C ‑> Aで遷移したら なんか動かなくなった

    ページBでXを 削除した のにページAで 出てきた ページAの改修の話してるのにページBの話してるんだけど ( 苦笑) APIからとったJSONをイイ感じに表示してフォームのバリデーショ ンにちょっと利用したいだけなのに...
  7. SPAの難しさ なぜこんなことが? ページ間で状態を共有しているから SPAなんだからそういうものでしょ? とりあえずdomain data(だいたいapi data)でStore(状態)を作ってる もんだし...

  8. SPAの難しさ domain dataでStore(状態)を分ける よくあるやりかたの一つ 世のサンプルを見ているとコレのパターンは大いにある 一体なぜこうするのか? アプリケーションのコアになるデータはUIに依存しないから? ページを跨いでも揮発しないことでAPIのキャッシュになるか ら? まあ色々理由はあるらしいんです

    これをやらない
  9. SPAの難しさ data domainでStore(状態)を分ける これをやらない

  10. SPAの難しさ data domainでStore(状態)を分ける これをやらない

  11. シンプルに作る アプリケーションはURLに応じて あるページの状態を1つ持ってい る 見えてないページに状態はナイ(ということにする) APIからとれるデータはページの状態の下にいるようにする

  12. シンプルに作る ページごとに状態をぶったぎり

  13. シンプルに作る ページごとに状態をぶったぎり

  14. シンプルに作る こんなお気持ち // アプリケーションから見るとページの状態は1つしか持たない case class SPAState(val page: Page) sealed

    trait PageState case class PageA( domainA: DoaminA domainC: DomainC ) extends PageState // ページごとに必要なデータは宣言する case class PageB(domainB: DomainB) extends PageState // ページごとに必要なデータは宣言する Elmわかる人が少ないと思うのでScalaでお送りします
  15. シンプルに作る こんなフロー

  16. シンプルに作る こんなフロー 各ページは表示されるまえに必ずそのページが必要とするデータを 必ずサーバに問い合わせる ページは表示される時必ずサーバと整合性が取れる ページA ‑> Bに遷移したときページAの状態は捨てられる、再訪問 したときAの状態はデータ取得から再作成される 前のページのXXXが残ってたはおきない

  17. シンプルに作る あれ... サーバサイドでつくるwebページとだいたい一緒やん!

  18. シンプルに作る 疑問 常にサーバサイドのデータをとるのか? データの種類にもよる a. 常にめまぐるしく変わる b. 少数のユーザによって変更される c. ごく稀にかわることがある

    d. 変わらないことを前提にしている 3,4に関してはページごとに状態を持たずアプリケーションと して持っても問題がない = SPAページ遷移でリフレッシュされ ない アプリケーション初期化時に読み込まれればいい
  19. シンプルに作る こんな話があった ページで分けると共通ロジックがbrbrbr 共通ロジックがビジネスロジックを指すなら状態構造とは切り 離して作ったほうがよくはないか? 遷移するたびサーバサイドへの負荷が... 最初に提示したdomainでアプリケーション下に配置するよう な定義でも正しくデータを見せようとしたら毎度取って来る必 要はある。 ページの状態作成時は全てじゃなくて差分更新とかしないの?

    差分更新のロジックをメンテナンスしていくのとサーバに金を 突っ込むのどっちが安く済むか。
  20. うまくいってるの? うまくいっていた(過去形) 当然ページ間でデータ不整合起きてトラブルはなかった 自分以外のElmerでも適応できて開発できてた

  21. Elmの話をしてくださいよぉ!! Elmなら話していた状態の構造、フローが 宣言的に 、 暗黙の何かが ない ように実装できる https://github.com/rtfeldman/elm‑spa‑example https://dev.to/rtfeldman/tour‑of‑an‑open‑source‑elm‑spa 詳しく聞きたい/Elmの話を聞きたい

    人はこの後捕まえてください