Selector Ergonomics

[PierreCapo]

It often happens for performance reason that we want our component to observe only a part of our store so that it is not redrawn every time other attributes it doesn't depend on, change.

struct AppState {
  var a: String
  var b: String
  // etc.
}

struct App: View {
// ....

  var body: some View {
  
    // Avoids redrawing MyComputationalHeavyComponent when AppState.b changes
    WithViewStore(self.store.scope(\.a)) { viewStore in
        MyComputationalHeavyComponent(viewStore.a)
    }
  }
}

This is looking good when MyComputationalHeavyComponent relies on one variable from the store, but that doesn't seem to scale well ergonomically if MyComputationalHeavyComponent relies on multiple parameters:

struct App: View {
// ....

  var body: some View {
  
    // only redraws when a, b, c change
    WithViewStore(self.store.scope(\.a)) { viewStoreA in
       WithViewStore(self.store.scope(\.b)) { viewStoreB in
           WithViewStore(self.store.scope(\.c)) { viewStoreC in
              MyComputationalHeavyComponent(viewStore.a, viewStore.b, viewStore.c)
            }
        }
    }
  }
}

A bit similar to how Redux selectors work with objects, I would hope WithViewStore being a variadic function and so, it would accept multiple parameters to avoid nested components:

struct App: View {
// ....

  var body: some View {
  
    // only redraws when a, b, c change
    WithViewStore(self.store.scope(\.a), self.store.scope(\.b), self.store.scope(\.c)) { a, b, c in
        MyComputationalHeavyComponent(a, b, c)
    }
  }
}

I know the whole project has worked on lot on ergonomics, so I was wondering if I was missing something and something similar already exists or if that would be worth that I open a PR.

[tgrapperon]

Hello! You're right that it is a good practice to only observe what's needed for a View. In this case, you could probably achieve what you're looking for using an intermediary state called ViewState that exists only to be the repository of the values you want to observe.

If you define:

extension App { // Your view
  struct ViewState: Equatable {
    let a: String
    let b: String
    let c: String

    init(state: AppState) {
      self.a = state.a
      self.b = state.b
      self.c = state.c
    }
  }
}

You can then use WithViewStore(store.scope(state: { ViewState(state: $0) })) { viewStore in … }, or the point-free variant: WithViewStore(store.scope(state:ViewState.init)) { viewStore in … }. If needed, you can also derive values from your state's properties. For example with a var count: Int in ViewState which correspond to state.a.count.

You can find more information on the subject here for example.

[PierreCapo]

Oh thanks ! I have learnt something, I missed this part in the documentation, and that's better solution compared to the nested WithViewStores 👍

However if this is the state of the art, that still seems to be a bit boilerplate given you need to write this code for every specific ViewState you want to use. Again, this would seem more natural and less cumbersome to use a variadic function or even some utility functions to pick the subset you want like:

WithViewStore(self.store.pick(\.a, \.b, \.c) { (a, b, c) in
}

[tgrapperon]

If you think about it, and without considering the overload situation, you will need to write and maintain a quite similar amount of code. If you don't want to rely on the tuple indices to access its data, you will need to declare parameters in the closure's side, matching the ones and the order of the KeyPaths from the picking side. All of this in some order-dependent way. Furthermore, you will need to be able to express all your derived values as properties of the store's state, as I don't think that using functions will work very long in this kind of very generic context.

I worked on some in-between solution (#527) in the past, where I'm relying on the state itself for the ViewStore's state, but were the comparison is defined using a subset of KeyPath only.

Right now, the ViewState story is not formalized in TCA, and there are probably ways to improve the ergonomic indeed. I have realized a few additional experiments to #527. For example, with a @ViewProperty property wrapper you use on state's properties, you can imagine a special State shell that only exposes @ViewState properties (via dynamicMemberLookup). At runtime, you list these properties once to build your deduplication function (this can be cached for performance reasons). I didn't go further yet mostly by lack of time, and my own limitations with reflection, interactions with other built-in property wrappers, the fact that this approach could define only one distinguished ViewState per State (which is likely not problematic), and that you baked UI stuff into your deep model. As a ViewState is relatively fast to define and to implement using multi-cursor editing, I moved on for now.

[PierreCapo]

Wow, that is super interesting, thanks for pointing out the PRs your have opened, nice read 🙌

[stephencelis]

This is looking good when MyComputationalHeavyComponent relies on one variable from the store, but that doesn't seem to scale well ergonomically if MyComputationalHeavyComponent relies on multiple parameters:

struct App: View {
// ....

  var body: some View {
  
    // only redraws when a, b, c change
    WithViewStore(self.store.scope(\.a)) { viewStoreA in
       WithViewStore(self.store.scope(\.b)) { viewStoreB in
           WithViewStore(self.store.scope(\.c)) { viewStoreC in
              MyComputationalHeavyComponent(viewStore.a, viewStore.b, viewStore.c)
            }
        }
    }
  }
}

A bit similar to how Redux selectors work with objects, I would hope WithViewStore being a variadic function and so, it would accept multiple parameters to avoid nested components

Store.scope takes any transform, not just key path-promoted functions, so the following is valid:

WithViewStore(
  self.store.scope(state: { ($0.a, $0.b, $0.c) }),
  removeDuplicates: ==
) { viewStore in
  …
}

@tgrapperon's mention of ViewState is typically a nice pattern, though, since tuples can become unwieldy in Swift, and because Swift ships with only so many == overloads for tuples.

[PierreCapo]

Very clear, I'll go that way with ViewState thanks @stephencelis and @tgrapperon 👍