Identify stores based off state identity

[stephencelis]

Potential fix for #3451.

Draft for now. We've talked about this in the past but still don't know the ramifications of it all. It does seem like it should be a good thing, but I'm worried about unforeseen consequences, so we should vet them out.

[BastianKusserow]

Hey, sorry to bother but is there any news on this? This unfortunately stops us from using alerts in UIKit at all, as they just show once and destination state is not reflected correctly :(

[acosmicflamingo]

If it helps, I've been using the changes in this PR to unblock my UIKit development and haven't seen issues from this.

[BastianKusserow]

@acosmicflamingo did you fork the repo or did you directly checkout the branch?

[acosmicflamingo]

@BastianKusserow I have my own fork because it makes it really easy for me to debug issues, upstream any fixes I find, and I can also slap on a public modifier here and there 😉

[nesium]

This fix does not work if the initial state is non-nil. E.g. in the attached project in #3636 change the code…

// RootFeature.swift::14
@ObservableState
struct State {
-  @Presents var route: Route.State?
+  @Presents var route: Route.State? = .feature1(.init(id: .a))
}

The ViewController with the title "Feature 1 ('a')" will then be presented on launch. Dismiss it, tap "Present Feature 1.b" and dismiss it again. The effects of the second VC are not cancelled and the route is not reset to nil.

[stephencelis]

@nesium Thanks for the counterexample! We're still not sure of the validity of incorporating state identity into the store, but also haven't had time to vet it, so going to leave this as a draft till we can revisit.