Should viewStore be a StateObject?

[kgrigsby59]

Shouldn’t viewStore in WithViewStore be a StateObject and not an ObservedObject so that it’s tied to the lifetime of the view and not recreated when the view struct is?

[tgrapperon]

(I have the feeling that this isn't an issue with the library per se, and this will be probably moved to a Discussion.)

I've experimented myself a few months ago with a StateObject variant of WithViewStore. If I recall correctly, this wasn't super conclusive. The issue with StateObject is that you can't initialize them with instance parameters. You can only touch them from inside a View's body. Now, if you want to make ViewStore a StateObject, you also need to implement internal methods to allow hot switches of its store's instances. Once you have this, you need to push your new stores to the ViewStore from the body of the view, using onAppear and onChange.
This is a kind of egg and hen problem because it can miss changes that would have made the body update, that would have updated the store in the ViewStore, etc.. It still works most of the time because the previous store instance's state most likely changes too, and body gets evaluated, but I'm not sure there aren't setups where it isn't happening.

I didn't continue with the idea at this point for three reasons:

• It didn't solve the issues I was hoping it will, like when controls are not working properly when wrapping a GeometryReader in the ViewStore. I was suspecting this could has been related to instances of ObservedObject changing very often, but it doesn't seemed to be the case. I didn't find any performance or behavioral changes by having the ViewStore stored as a @StateObject, and it added a lot of boilerplate.
• I think (and I may be wrong on this point) that the maintainers of the library are viewing ViewStore as a kind of view to a store, in the same spirit a SubString is a view to a String. That is, a lightweight, discardable object that only provides specific accessors to some Store instance. It made me think that having this ViewStore as a persisting @StateObject was a little too much responsibility for the type. In this spirit, I guess the Store itself would be a better candidate if required (but it would require to make it conform to ObservableObject).
• A custom property wrapper implementing DynamicProperty would probably be more adapted, but again, I don't know if it provides real life benefits.

I'm sure others will pitch-in with more ideas.

[mbrandonw]

We are certainly open to turning it into a @StateObject, but as @tgrapperon mentioned there are some subtleties to think through. We've tried before without success, but that doesn't mean it's not possible. We may try this again soon, and if anyone finds anything interesting we'd love to see it.

Also, I'm converting this issue to a discussion.