Exploring the implications of making Store conform to ObservableObject

[b1ackturtle]

What are your thoughts on having Store conform to ObservableObject, both in terms of behavior and the implications of conforming when defining Store in the library?

I am using TCA in a multi-module product, where each module represents a bounded context. I believe that making Reducers public, as seen in isowords, and allowing them to be referenced by parent modules does not properly maintain these boundaries. Therefore, I keep Reducers internal and create a Root Store for each module's Reducer.

When using TCA in this way, there are times when I need to initialize a Store within a View. If I use @State to hold the Store, it gets reinitialized every time the View is initialized, which may not lead to the expected behavior.

One solution to this problem is to hold the Store using @StateObject. To do this, the Store must conform to ObservableObject. I would like to know if there are any issues with having Store conform to ObservableObject. Additionally, I am interested in the pros and cons of having Store conform to ObservableObject at the time of its definition.

[mbrandonw]

Hi @b1ackturtle, thanks for bringing this up. I don't think there are many noticeable implications of making Store conform to ObservableObject. The main weirdness is that of expectations of people who see that Store is an ObservableObject. If they expect things will work without using @ObservableState, then they will be disappointed. And also if they expect to be notified of changes in the store via objectWillChange, then they will again be disappointed because we do not want to (and can't) support that.

Overall I just think it's a big bummer that @State does not have a lazy initializer. It was even briefly introduced during a beta period and then removed. And to be honest, the situation with @State and @StateObject is a bit of a mess! Apple's own documentation recommends that when wanting to hold an object in @State that you should make it optional (😳) and use the task view modifier to assign it (🙄). These docs also say that task is "called only once when the view first appears", which is not true at all. It is called every time the view appears.

And so you could follow Apple's advice and use the task modifier to initializer the Store, though I would recommend coalescing to prevent reseting the store when the view appears a 2nd time. Or you can simply add a @retroactive conformance yourself to Store so that you can keep pushing forward.

I could see us adding this conformance to the library at some point, especially with some researching we've been doing into "detached" stores. But I would only want to do so with copious amounts of documentation that details we are only doing this to work around SwiftUI's deficiencies.

[b1ackturtle]

Hi @mbrandonw, thank you for the information!

Overall I just think it's a big bummer that @State does not have a lazy initializer.

Yes, I completely agree. Ideally, I believe the best outcome would be for Apple to add a lazy initializer to @State or to provide an equivalent solution, rather than relying on an awkward workaround like the task modifier they recommend.

I could see us adding this conformance to the library at some point, especially with some researching we've been doing into "detached" stores.

That's a very intriguing topic. If there's already a place where discussions about "detached" stores are happening, I’d greatly appreciate it if you could share that information.

[mbrandonw]

That's a very intriguing topic. If there's already a place where discussions about "detached" stores are happening, I’d greatly appreciate it if you could share that information.

Nothing to share right at this moment, but we do plan on releasing some case studies demonstrating the technique, and also some changes coming to the library will make detached stores even more powerful.

[b1ackturtle]

Thank you for your response. I'm looking forward to the release of the content!