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-03-30_11-49_architecture_night.pdf
Search
ryota0624
April 25, 2019
0
1.6k
2019-03-30_11-49_architecture_night.pdf
ryota0624
April 25, 2019
Tweet
Share
More Decks by ryota0624
See All by ryota0624
techtalk5-su
ryota0624
0
980
kyash-meetup-vol7-suzuki.pdf
ryota0624
0
200
2019-06-01_10-10_oretoku_frontend.pdf
ryota0624
0
73
実践GraphQL for クライアント側
ryota0624
2
2.3k
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
505
140k
For a Future-Friendly Web
brad_frost
175
9.4k
Done Done
chrislema
181
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Writing Fast Ruby
sferik
626
61k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Building Adaptive Systems
keathley
38
2.3k
Happy Clients
brianwarren
97
6.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Optimizing for Happiness
mojombo
376
69k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
42
2.2k
Transcript
SPA状態設計(Elm)
わたし twitter: @4245Ryomt HRBrainのエンジニア フロントエンド
今日話すこと 前職 で広告プロダクトの運用画面、審査画面やらを開発するとき に設計でやったこと 端的にやったこと 状態をページごとで構成した https://github.com/rtfeldman/elm‑spa‑example ↑をパクった
お品書き SPAの難しさ ページごとにつくる
SPAの難しさ 今日話すのはユーザからみるとリッチなwebページくらいに見える アプリケーション ◦: 運用画面, 管理画面 ✖ : twitter
SPAの難しさ こんなことありません? ページA ‑> B ‑> C ‑> Aで遷移したら なんか動かなくなった
ページBでXを 削除した のにページAで 出てきた ページAの改修の話してるのにページBの話してるんだけど ( 苦笑) APIからとったJSONをイイ感じに表示してフォームのバリデーショ ンにちょっと利用したいだけなのに...
SPAの難しさ なぜこんなことが? ページ間で状態を共有しているから SPAなんだからそういうものでしょ? とりあえずdomain data(だいたいapi data)でStore(状態)を作ってる もんだし...
SPAの難しさ domain dataでStore(状態)を分ける よくあるやりかたの一つ 世のサンプルを見ているとコレのパターンは大いにある 一体なぜこうするのか? アプリケーションのコアになるデータはUIに依存しないから? ページを跨いでも揮発しないことでAPIのキャッシュになるか ら? まあ色々理由はあるらしいんです
これをやらない
SPAの難しさ data domainでStore(状態)を分ける これをやらない
SPAの難しさ data domainでStore(状態)を分ける これをやらない
シンプルに作る アプリケーションはURLに応じて あるページの状態を1つ持ってい る 見えてないページに状態はナイ(ということにする) APIからとれるデータはページの状態の下にいるようにする
シンプルに作る ページごとに状態をぶったぎり
シンプルに作る ページごとに状態をぶったぎり
シンプルに作る こんなお気持ち // アプリケーションから見るとページの状態は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でお送りします
シンプルに作る こんなフロー
シンプルに作る こんなフロー 各ページは表示されるまえに必ずそのページが必要とするデータを 必ずサーバに問い合わせる ページは表示される時必ずサーバと整合性が取れる ページA ‑> Bに遷移したときページAの状態は捨てられる、再訪問 したときAの状態はデータ取得から再作成される 前のページのXXXが残ってたはおきない
シンプルに作る あれ... サーバサイドでつくるwebページとだいたい一緒やん!
シンプルに作る 疑問 常にサーバサイドのデータをとるのか? データの種類にもよる a. 常にめまぐるしく変わる b. 少数のユーザによって変更される c. ごく稀にかわることがある
d. 変わらないことを前提にしている 3,4に関してはページごとに状態を持たずアプリケーションと して持っても問題がない = SPAページ遷移でリフレッシュされ ない アプリケーション初期化時に読み込まれればいい
シンプルに作る こんな話があった ページで分けると共通ロジックがbrbrbr 共通ロジックがビジネスロジックを指すなら状態構造とは切り 離して作ったほうがよくはないか? 遷移するたびサーバサイドへの負荷が... 最初に提示したdomainでアプリケーション下に配置するよう な定義でも正しくデータを見せようとしたら毎度取って来る必 要はある。 ページの状態作成時は全てじゃなくて差分更新とかしないの?
差分更新のロジックをメンテナンスしていくのとサーバに金を 突っ込むのどっちが安く済むか。
うまくいってるの? うまくいっていた(過去形) 当然ページ間でデータ不整合起きてトラブルはなかった 自分以外のElmerでも適応できて開発できてた
Elmの話をしてくださいよぉ!! Elmなら話していた状態の構造、フローが 宣言的に 、 暗黙の何かが ない ように実装できる https://github.com/rtfeldman/elm‑spa‑example https://dev.to/rtfeldman/tour‑of‑an‑open‑source‑elm‑spa 詳しく聞きたい/Elmの話を聞きたい
人はこの後捕まえてください