swiftui-tutorial-question.md

https://developer.apple.com/tutorials/swiftui/handling-user-input

このチュートリアルの最後の場面で、LandmarkDetail画面で、お気に入りのスターを表示する処理と、タップによってスターをオン/オフする処理が実装される。

この画面の設計が気持ち悪い。

まず、LandmarkDetailはinitでlandmark: Landmarkを受けてvarに保存している。 それを、self.landmark.nameなどの表示に使っている。

一方、LandmarkDetailは@EnvironmentObjectでuserData: UserDataも暗黙に受け取っている。 そして、self.landmark.idを使ってself.userData.landmarksからインデックスを引いてきて、self.userData.landmarks[index]として、Landmark型を取り出す処理がある。 こうやって取り出した方のLandmarkは、isFavoriteの方の表示に使っている。

このように、引数で受けたLandmarkを静的な値の表示、UserDataの中のLandmarkを動的な値の表示にと使い分けている。この作りは、値が静的か動的かどうかという必要のない関心をコードに生じさせてしまっていると思う。

また、LandmarkDetailは一つのランドマークを表示するための画面なのに、UserData型固有のデータ構造に依存したコードになってしまっていて、これも必要のない関心が埋め込まれていると思う。

この画面は本来、@Binding var landmark: Landmarkなどとやって、表示するLandmark一つだけに依存させるべきで、画面表示側で、必要であればこれをUserData.landmarksと結合させる、といった構造になるべきだと思う。

ただ現状、SwiftUIにはlandmarks: [Landmark]からある一要素に対するBinding<Landmark>を作る標準の道具が無いような気がする？

「大本」があることをViewが知るべきじゃないと思う
先述したTabの例であれば、「大本」とは別個に、detailが通信で取得される可能性もあるでしょう
ほかにも「Listには含まれているけど、それとは関係なくディープリンクによって遷移したDetail」があったとしたら、その操作もListには反映させるべき

なので、「Viewが参照しているデータが単一の参照であり、それが変わればすべて連携する」という期待は持たず、
「グローバルな変更通知に対して、Identifiableなものがあればそれを適用」できる仕組みが欲しい気がする

SwiftUIそんなにしっかりキャッチアップできてないので見当外れなこと言ってるかもしれない

Binding型で受け取ると大本があることが暗喩されちゃうということ？
インターフェースとしては結局普通の型と同じでリード/ライトできるだけだけれど。
あと、通信で取得した場合でも、普通に値を保持しつつBindingに包む事自体はできるはず。
でも確かに微妙な気もする。

確かに明示的に値で持っておいて、必要に応じて変更通知を送信したり、それを受信して読み込んだりするほうが、
インターフェース的に自然な気はする。

ただIdentifiableをグローバルで考えちゃうと、環境を切ったり、小さい範囲で使いたい場合に面倒になるから、
殆どの場合にグローバルと同一であったとしても、なんらかのコンテキストオブジェクトは指定するようにしたほうが良いと思う。
例えばサブミット前の編集作業中の状態を表すオブジェクトと、それをPOSTして確定するまでのサーバ状態を知識として持っておくオブジェクトは、同じIDを持つけど状態としては独立させておきたい。

SwiftUI的にはそのようなコンテキストに当たるのがEnvironmentObjectだと思う。

そうすると現状のUserDataはまあまあ惜しくて、
landmarksでアクセスするんではなくて、
idを渡すgetter/setterと、idを渡してPublisherを返すAPIを追加してやるのがいいのかな。

そのへんはボイラープレート化しそうだから標準的な道具がやっぱり欲しいですね。

「大本」があることをViewが知るべきじゃないと思う

Binding型で受け取ると大本があることが暗喩されちゃうということ？

Binding型で受け取ることに対しては特に意見はなくて…というかそこまでBindingを理解できてなくて、

この方向性だとLandmarkDetailEnvironmentに実体を持たせずに、
リードは大本からの検索、ライトは大本への書き込みにする

という点が気になりました

https://twitter.com/omochimetaru/status/1151341934138408960

ForEach.initのcontentクロージャが、Data.Element.IdentifiedValueじゃなくてBinding<Data.Element.IdentifiedValue>をくれたらいい

の方針も、それだとViewが自らの認識の外の通知を受け取れる余地がないので…
となると結論は

なんらかのコンテキストオブジェクトは指定するようにしたほうが良いと思う。
SwiftUI的にはそのようなコンテキストに当たるのがEnvironmentObjectだと思う。

ってことになりますね

それだとViewが自らの認識の外の通知を受け取れる余地がないので…

確かにそうだけど、「大本(A)」以外からの変更通知を(Bで)受け取るシチュエーションはおかしいのでは？
他の場所(C)で変更が発生するとしても、それを(Bで)受け取る必要があるとしたら、同じ実体を意味しているはずなので、
そのほかの場所(C)から大本(A)に反映するような形にした上で、(Bでは)大本(A)経由で受け取るようにすると思います。

ただその大本の管理主体がコンテキストオブジェクトであるEnvironmentObjectとなるとは思います。

あー
大本=landmarks だと思って話してました

大本=A=EnvironmentObject
とすれば、認識一致してそう

landmarks: [Landmark]からある一要素に対するBindingを作る標準の道具

ができるときには、
引数としてEnvironmentを取りつつラクに書けると嬉しい世界なのかな

引数としてEnvironmentを取りつつラクに書けると嬉しい

そう思います。

(Twitter@iceman5499です。)

Xcode11 Beta5 くらいからいつの間にか Binding が自分で生成できるようになった（ init(get: @escaping () -> Value, set: @escaping (Value) -> Void) が生えた）ので

landmarks: [Landmark]からある一要素に対するBindingを作る標準の道具

これができるようになったように見えます。
Bindingとしての取り出しはやや煩雑ですが、ある程度理想的な形でかけるようになりました

https://gist.github.com/sidepelican/330ca3255cffcf13cd5352d5935040c7