Reactでのマルチストア運用を考察する

Effectorにを触ってみてマルチストアの運用について考察してみました。

Transcript

1. Reactでのマルチストア運用を 考察する
2. 自己紹介
3. 自己紹介 Hayashi Takao (れむ@9almondchocola) software engineer / React, Scala, Go Cyberbuzz,inc.
4. マルチストアというユートピア
5. ドメインが適切に切られていて、 ドメインは自分の関心ごとに必要な情報だけを更新し 必要なコンポーネントがその情報を取りに行くって最高じゃね？ Reduxのシングルストアはでかくなりすぎる！ ミドルウェアのメンテキッツ！ 同じような情報がストア内にいるしいらない情報まで取りに行って欲しくない！ となったのでマルチストアでのフロントエンド開発をしてみました。
6. 今回はマルチストアを実現するために Effectorというライブラリを使用しました。 Effector : https://effector.now.sh/
7. 今回注目してみているポイント
8. 注目ポイント - ストアの予測はしやすいか？ - メンテナンスコストは低いか？ - テストしやすいか？またはテストカバレッジを阻害されないか？
9. ストアが予測しやすいか？
10. ストアの予測 EffectorにはDomainという実装がある。 DomainはそのDomainの中で発生する通信やイベント、状態変化を サブスクライブするがDomainの外の情報には干渉しない。 また、Domainの中にDomainを作ることができる。
11. ❌ App User Likes Follower
12. micro serviceがBfFからのリクエストに応じる感覚に近く てとてもすき。 データ設計がシンプルなほど強い。
13. Domainは名前空間 親は子のDomainをサブスクライブできるが、子は親の状態を知らない。 つまり名前空間をきちんと切って通信して APIの戻り値や状態をストアリングしてくれる！！
14. メンテナンスしやすい？
15. メンテナンス性 DomainごとにEventやEffectがあるので責務が明確。 明確な責務のものほどメンテナンスがしやすい！ 発行されたEventの処理は一つの関数が担うため、Domainがわかれてるから 関係ない値を選別したりする必要はない。
16. テストしやすい？
17. テストのしやすさ マルチストアはテストしにくい！ ストアの状態が色々あるためテストパターンを用意するのが大変。 特にコンポーネント単位になってくるとカオス。 テスト性能に置いてReduxはすごく快適。
18. ここまでを振り返る
19. 振り返り - ストアの予測 ◦ - メンテナンス性能 ◦ - テスト ✖ でもよく考えると辛い本質はストアの形ではない気がする。。。
20. Reduxのときつらいなと思ったこと - 不必要にでかいオブジェクト - 責務があやふやなaction - 巨大すぎるMildeWear - コンポーネントテストつらい！
21. 翻って見てみればきつい原因は - とりあえずで作った計画性のないaction - 責務が不明確なままつくったMiddleWear - デザイナーに適当に振ってしまったコンポーネント 　　...etc
22. ごめんなさい、ちゃんと設計をすべきでした。 銀の弾丸を望んですいまんせんでしたm(_ _)m
23. まとめ
24. - そもそも論、情報設計が悪かった(Redux) - 情報設計の筋の悪さはマルチストアでも解消されない！！ - マルチストアにしてテストカバレッジ下がるくらいならしないほうがいい - ミドルウェア部分のメンテナンス性は抜群 - ストアの中身の予測もしやすい
25. マルチストアは全然銀の弾丸ではなかった。 基本的な設計がすごく大切。 関わる人全員で知見を深め作り上げてく必要がある。
26. Thank you!!