Slide 1

Slide 1 text

SPA状態設計(Elm)

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

SPAの難しさ こんなことありません? ページA ‑> B ‑> C ‑> Aで遷移したら なんか動かなくなった ページBでXを 削除した のにページAで 出てきた ページAの改修の話してるのにページBの話してるんだけど ( 苦笑) APIからとったJSONをイイ感じに表示してフォームのバリデーショ ンにちょっと利用したいだけなのに...

Slide 7

Slide 7 text

SPAの難しさ なぜこんなことが? ページ間で状態を共有しているから SPAなんだからそういうものでしょ? とりあえずdomain data(だいたいapi data)でStore(状態)を作ってる もんだし...

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

シンプルに作る こんなお気持ち // アプリケーションから見るとページの状態は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でお送りします

Slide 15

Slide 15 text

シンプルに作る こんなフロー

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

シンプルに作る 疑問 常にサーバサイドのデータをとるのか? データの種類にもよる a. 常にめまぐるしく変わる b. 少数のユーザによって変更される c. ごく稀にかわることがある d. 変わらないことを前提にしている 3,4に関してはページごとに状態を持たずアプリケーションと して持っても問題がない = SPAページ遷移でリフレッシュされ ない アプリケーション初期化時に読み込まれればいい

Slide 19

Slide 19 text

シンプルに作る こんな話があった ページで分けると共通ロジックがbrbrbr 共通ロジックがビジネスロジックを指すなら状態構造とは切り 離して作ったほうがよくはないか? 遷移するたびサーバサイドへの負荷が... 最初に提示したdomainでアプリケーション下に配置するよう な定義でも正しくデータを見せようとしたら毎度取って来る必 要はある。 ページの状態作成時は全てじゃなくて差分更新とかしないの? 差分更新のロジックをメンテナンスしていくのとサーバに金を 突っ込むのどっちが安く済むか。

Slide 20

Slide 20 text

うまくいってるの? うまくいっていた(過去形) 当然ページ間でデータ不整合起きてトラブルはなかった 自分以外のElmerでも適応できて開発できてた

Slide 21

Slide 21 text

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