Skip to content

Instantly share code, notes, and snippets.

@yosshi4486
Last active April 5, 2020 08:01
Show Gist options
  • Save yosshi4486/2f4cc67161c7ce84490b352c628aa34d to your computer and use it in GitHub Desktop.
Save yosshi4486/2f4cc67161c7ce84490b352c628aa34d to your computer and use it in GitHub Desktop.
宣言的UI時代のアプリケーション開発マニフェスト

iOSのCombine/SwiftUIや、AndroidのJetpackComponentなど、宣言的記法を利用したパラダイムがモバイルアプリ開発で当たり前になろうとしている。 考え方をそもそも変えないといけない場面が出そうなので、gistに残しておく。今はただの考えにすぎないので、実装出来てきたらレポジトリやQiitaで公開する

1. 変更はやってくる

今まではRepositoryに対してgetを投げて、非同期のクロージャで結果を返して...。のようにしていたが、 宣言的パラダイムでは変更はSubscribeしており、流れきてたら自動で更新がなされる。getのようなリクエストを送ることはない。

実現のためにポーリングなどが必要な場合も、データレイヤーでカプセル化する。

2. ライフサイクルに頼らない

  1. の変更はやってくるを考慮すると、UIKit時代のviewDidLoadやviewWillAppearに頼った実装は必要がなくなる。 ライフサイクルに頼らず、自分が監視しているオブジェクトや値に変更があれば自身の更新を行う。

3. Controllerを作らず、中央集権をやめる

UIKit時代はMediatorとしてControllerが役割を持っており、これをMVPにしようがMVVMにしようが「どこかが画面上のリクエストを一身に受けて、周りへ流す」 という役割のオブジェクトが必要なことに変わりはなかった。これはライフサイクルがもたらすフォースを受けており、仕方ない問題であったが、 SwiftUIではBindingやEnvironmentなどを利用してSingle Source of Truthを実現することで、Viewが自律的に自分の興味のあるデータを監視し自信を更新する。 つまり中央集権をやめて自立分散管理のアプローチを取る方がいいだろう。

@yosshi4486
Copy link
Author

画面を跨いだデータの変更は自動で伝搬される。

@yosshi4486
Copy link
Author

このレポジトリがすごく参考になった。
https://github.com/peterfriese/MakeItSo/tree/master/final/MakeItSo

@yosshi4486
Copy link
Author

ViewModelではEntityの配列を持たない。操作しない。

@yosshi4486
Copy link
Author

ListRepositoryが必要だと思っていたけど、実際に必要なのはTaskレポジトリだった。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment