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.7k
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
1.2k
kyash-meetup-vol7-suzuki.pdf
ryota0624
0
240
2019-06-01_10-10_oretoku_frontend.pdf
ryota0624
0
78
実践GraphQL for クライアント側
ryota0624
2
2.5k
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
4 Signs Your Business is Dying
shpigford
185
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.5k
We Have a Design System, Now What?
morganepeng
53
7.8k
Designing Experiences People Love
moore
142
24k
GitHub's CSS Performance
jonrohan
1032
470k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
930
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.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の話を聞きたい
人はこの後捕まえてください