Another alternative to observe

[GreatApe]

Instead of hijacking another thread, again, I will post my idea here. In short, the idea is to separate observing from scoping. In the current WithViewStore the observe option also scopes the state at the same time, which means that it can only really be used in a closure - we wouldn't want to scope the whole store, then we wouldn't be able to peel off other parts and pass down to child views.

But what if we make it possible to specify what a store observes, without causing any scoping. This also seems to make it possible to ditch view stores altogether. Please have a look and let me know all the considerations I've missed! I am new to this and don't really know the first principles behind TCA.

No more ViewStores

The idea is to ditch ViewStores, and only have Store everywhere, but by default a Store doesn't observe anything, it just holds onto the state and forwards it.

struct ViewState {
    var title: String
    var subtitle: String
}

init(store: Store<State, Action, Void>) { // Last generic argument is the observed state
    self.store = store.observe(\.viewState) // self.store is Store<State, Action, ViewState>
}

In short, you need to explicitly tell it what to observe.

Separating .scope and .observe

So observing doesn't cause any scoping change, but you can of course still scope:

// in the body
let childStore = store.scope(state: \.childState) // childStore is Store<ChildState, Action, Void>
ChildView(store: childStore)

Scoping should probably reset it so that nothing is observed.

Naming

You could imagine calling this store type ObservingStore and then do

typealias Store<State, Action> = ObservingStore<String, Action, Void>

You could also probably make it so that the store only exposes a viewState property, so that you can't even read state that isn't observed.

Discussion

Speaking of this, what is the fundamental reason that we want two types, Stores and ViewStores? Are there internal technical reasons or is it usage ergonomics? The way I see it we have four basic requirements:

• Hold onto a large piece of state
• Observe part of it
• Send actions to it
• Be able to peel of a smaller piece of it and pass down

We use a Store for the first point, and a ViewStore for the second and third. Then we use Store.scope for the fourth:

extension MainState {
    var viewState: MainView.ViewState { ... }
}

struct MainView: View {
    struct ViewState: Equatable { ... }
    @ObservedObject var store: Store<MainState, MainAction>

    var body: some View {
        VStack {
            WithViewStore(store, observe: \.viewState) { viewStore in
                Text(viewStore.title)
                Button {
                    viewStore.send(.tappedName)
                } label: {
                    Text(viewStore.name)
                }
            }
            let childStore = store.scope(state: \.child, action: MainState.Action.child)
            ChildView(store: childStore)
        }
    }
}

I don't know if that is how you see it, but to me it makes sense. And if that's true, then I feel that it could be achieved without viewStores, at the price of adding one more generic type to Store. (Although we could make a type alias for "non-observing store").

struct MainView: View {
    struct ViewState: Equatable { ... }

    @ObservedObject var store: Store<MainState, MainAction, MainView.ViewState >

    init(store: Store<MainState, MainAction, Void>) {
        self.store = store.observe(\.viewState)
    }

    var body: some View {
        VStack {
                Text(store.title)
                Button {
                    store.send(.tappedName)
                } label: {
                    Text(store.name)
                }
            }
            let childStore = store.scope(state: \.child, action: MainAction.child)
            ChildView(store: childStore)
        }
    }
}

Ergonomically, it seems like a big advantage that we only have to deal with a single thing, the store. On the flip side, it seems that we will need to always have an init, where we can tell the store what to observe. We could of course do that when passing the store in to MainView, but that seems like leakage.

Another ergonomic difference is that scope and observe are now separate. To me it makes sense and doesn't seem harder to understand, but maybe it is for some people.

I would love to hear if there are other considerations behind the use of ViewStores in addition to Stores. For example wanting to hide .send. I can't see the advantage of that though. And maybe there are other reasons?

[mbrandonw]

Hi @GreatApe, can you share a branch with your explorations so that people can play around with it and understand its implications?

[GreatApe]

I don't have anything finished yet, I'm mostly exploring what kinds of UX are even achievable. I did build a POC that internally uses a ViewStore but it's not usable yet. By the way, the original idea was something like this:

@Observed(\.viewState) var store: Store

But it doesn't seem possible to have a property wrapper with "arguments" without specifying initial values, at least I can't figure out how. I'm also not sure how to build a property wrapper that will trigger SwiftUI renders. I have a vague memory that you can put a @Published on it, and that will trigger things, but I'm not sure.

In any case, I don't have anything fully functional yet. And before I spend too much time I would like get a high level understanding of the problem. Would you say that my understanding of the requirements and considerations is is reasonably correct, or have I missed something important? Perhaps there are other reasons that we want or need a separate type for viewstores that I haven't thought of?

[mbrandonw]

Yeah, I think those 4 points mostly cover the responsibilities of Store+ViewStore, but if someone thinks of more please chime in. I think also further being able to transform actions that can be sent is a nice-to-have, especially since many are starting to coalesce around the pattern of putting view actions into a separate case (see #1440).

The only reason Store and ViewStore are separate concepts is because we never found an ergonomic way of accomplishing everything in a single package.

[GreatApe]

Hm, it seems my examples got lost when I moved this over to this thread, now I understand your first comment better. I added some clarifications to the first part now.

[fabstu]

Interesting idea.

Small question: how does the view detect that the store changed? WithViewStore does it by being embedded as a View and having the ViewStore as an observed object, which triggers a re-render of the WithViewStore body when ViewStore sends objectWillChange.send().

If you store the store as an @ObservedObject, then the whole view body gets re-rendered. If you want to replace WithViewStore with its body-closure to only re-render a small part, then you have to make it a View that contains an ObservedObject and call objectWillChange.send() on the observed object inside that view.

[stephencelis]

@GreatApe I think getting a branch with a full, working example will be helpful, and will give us, and anyone watching this discussion, an opportunity to understand any trade-offs that come with the changes, especially if you convert the case studies that come with the repo.

Brandon and I have collectively spent many days trying to come up with something better than the current Store-ViewStore divide. We're far from satisfied with the current design, but we also haven't figured out something that we think is better. Property wrappers would seem to be the most promising design space here, but as I think you also found, they also seem to be too limited to accomplish what we want here, no matter how hard we try. Other attempts we've made fight the language or its idioms in other ways, or make some things better but the experience collectively worse, especially for newcomers to the library. We welcome others to explore the space! We just think it's difficult to judge a sketch. The problem space is larger and a lot more subtle than it appears to be, something we've had rough reminders of every time we tried to take one of our sketches to completion 😄

I'll reserve comments till you have a working implementation, since you may come to similar conclusions in the process. One question about your current sketch, though: what is MainStore?

[GreatApe]

Sorry, MainStore is just a Store<MainState, MainAction, MainView.ViewState>, I always use type aliases in my own code so I forgot to clarify that. In general the example still isn't entirely clear perhaps. I've updated them again now.

And of course, I realise you have spent a lot of time thinking about this and trying different solutions, and most of all you know the framework intimately where I only have very vague ideas. That's precisely why I didn't want to spend a lot of time implementing something that you already tried and discarded, or that you can quickly see doesn't work.

But if you don't see any obvious flaws, I can try to put together a more complete POC.

[GreatApe]

@fabstu

So the way it does it is by listening to its internal _state, map to viewState and compare it to the previous value. If it's different we call our objectWillChange.send() and set the new value - the store needs to be an @ObservedObject.

As to the ergonomics, you are right that as it is it can only be used like a ViewStore property, it doesn't replace WithViewStore. But looking at the four types of views again, it seems to me we seldom or never have to use WithViewStore with my proposal, since you can control scoping and observing separately you can tell the Store to observe precisely the values you need, and still be able to pass down other values to a child view:

// No stateful views in the body
struct ViewA: View {
    var body: some View {
      Text("Hello world")
    }
}

// All stateful views are system views - we only need a "ViewStore"
struct ViewB: View {
    struct ViewState {
        let title: String
        let sutitle: String
    }

    let store: Store<B.State, B.Action, ViewState>

    init(store: Store<B.State, B.Action, Void>) {
        self.store = store.observe(\.viewState)
    }

    var body: some View {
        Text(store.title)
            .onTapGesture {
                store.send(.tappedTitle)
            }
        Text(store.subtitle)
    }
}

// All stateful views are custom views -  we only need a "Store"
struct ViewC: View {
    let store: Store<B.State, B.Action, Void>

    var body: some View {
        VStack {
            Text("Children:")
            Child1(store.scope(state: \.child1, action: C.Action.child1))
            Child2(store.scope(state: \.child2, action: C.Action.child2))
        }
    }
}

// Stateful views are mix of system views and custom views - we need both a "Store" and a "ViewStore"
struct ViewD: View {
    struct ViewState {
        let title: String
        let subtitle: String
        let tabItem
    }

    let store: Store<B.State, B.Action, ViewState>

    init(store: Store<B.State, B.Action, Void>) {
        self.store = store.observe(\.viewState)
    }

    var body: some View {
          VStack {
              Text(store.title)
              Text(store.subtitle)
              TabView(selection: store.binding(\.tabItem, send: .tabItemChanged) {
                  Child1(store.scope(state: \.child1, action: D.Action.child1))
                  Child2(store.scope(state: \.child2, action: D.Action.child2))
              }
          }
       }
    }
}

Now it could of course be that I'm missing some situation here, and it's also possible that some people have strong preference for using the framework in a way that requires something like WithViewStore, for example if they want to different "ViewStore" type things in the same body. So if that is something we need, then a version of WithViewStore for the unified Store could probably be devised.

[GreatApe]

I hacked together a proof of concept (internally using ViewStore), and while the ergonomics seem to cover at least all the usage in my own app, I am not sure it is much better than status quo. Yes, it only has one type of store, but separating what you scope to and what you observe will probably cause at least the same amount of confusion - it's not a clear improvement.

One option that might be an improvement is to replace WithViewStore with a method on store:

struct ViewB: View {
    let store: Store<B.State, B.Action>

    var body: some View {
        store.observing(\.viewState) { viewState, send in
            Text(viewState.title)
                .onTapGesture {
                    send(.tappedTitle)
                }
            Text(viewState.subtitle)
        }
    }
}

[JacksonUtsch]

If Store moves toward using Actor (as it probably should) I believe there must be a separation of Store vs ViewStore to subscribe to changes. Did some experimenting with this a while back (Swift 5.5) when Swift was lacking some important items in concurrency (still is).

Just noting my observations here. It seems this design of Store vs ViewStore is acceptable. I could be wrong on the requirement here, but it is what I remember of it.

[stephencelis]

@JacksonUtsch That's a good point! On top of that, while SwiftUI's view store should obviously be an observable object, view stores on other platforms (including UIKit) don't have the same requirements. Currently we jam SwiftUI and UIKit into a single ViewStore concept, but as we expand to other platforms, like SwiftWASM, Linux, Windows, etc., it'll make even more sense to have platform-specific view stores.

[JacksonUtsch]

Yes, once we have removed Combine from the dependencies we can look to support other platforms in this manner. Platform specific ViewStore's. Will need to separate these into different targets somehow, similar to how is being done with live vs client modules. Or possibly different packages.

[tgrapperon]

@JacksonUtsch I completely agree with you. ViewStore is a fundamental type, at least for its ViewState part, and the fact that one has difficulties trying to do without it is no stranger to that.
WithViewStore is not perfect but quite convenient, and extracting a ViewStore (or ObservedStore or whatever it is called) from a property wrapper would probably be better, but we will not be able to avoid using this kind of type. This will be obvious if Store are actors as you mentioned. At this point, the ViewAction role will be more important than some simple gatekeeping.
ViewStores are localized observations of an absolute object that is the Store, like two pictures of a car from different angles are different pictures from the same car.

[JacksonUtsch]

@tgrapperon I tend to opt for not using WithViewStore much and use an @ObservableObject var viewStore: ViewStore<State, Action>. Seems more SwiftUI like and explicit for view refreshes. TCA could do away with WithViewStore really.

Good to have some validation on this, still looking for some on my thoughts for typed error handling 😅