[Experiment] ObservedStore property wrapper

[tgrapperon]

Hello!
I've recently experimented with a DynamicProperty called @ObservedStore. The objective was to offer an alternative to top-level WithViewStore while keeping the same .init(store: Store<State, Action>) synthetized initializer for the views.

If your store's state is Equatable and you want to observe all of it, then

struct View {
  let store: Store<State, Action>
  var body: some View {
    WithViewStore(store) { viewStore in
      VStack {
        Text(viewStore.name)
        DetailView(store: store.scope(…))
      }
    }
  }
}
// becomes
struct View {
  @ObservedStore var store: Store<State, Action>
  var body: some View {
    VStack {
      Text($store.name)
      DetailView(store: store.scope(…))
    }
  }
}

The projected value right now is a ViewStore<State, Action>. You can instantiate this view from a parent as usual: View(store: store).

In case you need a ViewState, I've introduced a ViewStateProtocol which is an Equatable that as an init(state: State) initializer. When using a ViewState:

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

  struct ViewState: Equatable {
    let name: String
    init(state: State) {
      self.name = state.name
    }
  }
  var body: some View {
    WithViewStore(store.scope(state: ViewState.init)) { viewStore in
      VStack {
        Text(viewStore.name)
        DetailView(store: store.scope(…))
      }
    }
  }
}
// becomes
struct View {
  @ObservedStore.Of<ViewState> var store: Store<State, Action>

  struct ViewState: ViewStateProtocol {
    let name: String
    init(state: State) {
      self.name = state.name
    }
  }
  var body: some View {
    VStack {
      Text($store.name)
      DetailView(store: store.scope(…))
    }
  }
}

If you need a ViewAction that narrows the actions you can send to a Store, I've introduced the ViewActionProtocol which has only a static embed: (Self) -> StoreAction requirement. When using a ViewAction and a ViewState, you would use

@ObservedStore.Of<ViewState>.And<ViewAction> var store: Store<State, Action>

Again, when you instantiate the view from a parent, you still use View(store: store).
I've experimented with a few different names for the ViewState/Action chain:

@ObservedStore.Of<ViewState>.And<ViewAction>
@ObservedStore.State<ViewState>.Action<ViewAction>
@ObservedStore.ViewState<ViewState>.ViewAction<ViewAction>

I've selected the first for obvious reasons after trying the third (there is currently a remnant of it if you want a ViewAction only: @ObservedStore.ViewAction<ViewAction>).

EDIT: The branch was updated and is now using:

@ObservedStore.Of<ViewState>.Sending<ViewAction>

You can find here a branch with this experiment, and where I've updated TicTacToe and one Study to show how it's used. Unfortunately, I've reindented the bodies when removing the WithViewStore, so diffing shows many changes, but in bodies, it merely consists in replacing viewStore by $store. You can also define a var viewStore: ViewStore<ViewState, ViewAction> { $store } computed property in your view. It is also possible to define a StoreViewProtocol: View with this property already defined in an extension.

There's a lot of repeats in the code, but I've tried many things without success, and this is by far the easiest. In the same branch, you can check the first commit where I used another approach that was working but was rather odd: @ViewScope<ViewState>.ObservedStore var store: Store<>.

This is not a replacement for WithViewStore, which is very convenient and allows to really narrow the scope of modified views, but this property wrapper can provide a convenient alternative to switching to a manual @ObservedObject var viewStore.

It is also possible to use this property wrapper in another way. Right now, we're returning the ViewStore as its projected value, but we could imagine returning the property wrapper itself instead. By doing so, we could probably regain the $ notation for bindings (I don't remember exactly why it was pulled off, but I believe it was related to ObservableObject getting in the way with its own bindings. With ObservedStore, we have one level of indirection that can maybe provides enough room to reinstate this functionality. I didn't push farther yet, as I don't know if the whole idea of this wrapper is sound.

What do you think?

[stephencelis]

Very cool, @tgrapperon! You've probably had the most luck with a problem @mbrandonw and I have struggled to find a good solution for.

I think the ergonomics we want just isn't possible with property wrappers today, but your solution could offer an alternative...we'll have to think about it. One other name to consider:

@ObservedStore.Of<State>.Sending<Action>

I think in an ideal world we would be able to do something like:

// Your proposal:

@ObservedStore var store: Store<State, Action>
// $store == ViewStore<State, Action>

// But overloadable:

@ObservedStore(state: ViewState.init, action: ViewAction.init)
var store: Store<State, Action>
// $store == ViewStore<ViewState, ViewAction>

This isn't possible today for a few reasons:

1. Property wrapper generic inference prevents the former from compiling if there are other generics, even if the initializer is constrained (where State == ViewState, action == ViewAction).
2. The latter would require some kind of staged property wrapper initialization

We've explored a bunch of other permutations that were worse, and most of them didn't work.

[tgrapperon]

@stephencelis Thanks for the feedback!
I would have more likely leaned toward Receiving instead of Sending, but I get how Sending matches viewStore.send(Action) cognitively, and I'll update my branch with this. This is way better than And and it furthermore also works with the rarer case of ViewAction over an Equatable store's State.
I've also tried very weird permutations. It is possible that something could work with placeholder types or by composing property wrappers, but I haven't checked yet.

[tgrapperon]

I managed to get the @ObservedStore(state:… syntax to build, but it unfortunately crashes at runtime. I'll push more this weekend!
One observation: at some point, we may need to implement explicitly the trivial:

init(store: Store<State, Action>) {
  self.store = store
}

It seems that the compiler doesn't want to synthetize it if there are too much inferred generics, which is what the Of.Sending approach prevented.
This is not utterly problematic when working with hyper-modularized projects as we already have to do so to make it public.