How to make bindings work with ViewState?

[tgrapperon]

In the current (and former) implementation of bindings in TCA, the ViewStore's state needs to be of the same type as the store's State [Edit: this is not exact - See @stephencelis answer below]. I'm opening this discussion to explore alternative ways to still use TCA bindings when using a ViewState.
(That is some equatable type, derived from the store's State, and which is used to scope the store and instantiate a chiseled ViewStore that works on the bare minimum needed for the view).

Right now, I'm seeing three possibilities:

Extracting a dedicated Store

One can derive an equatable writable sub-state from the state and scope the store. We need to pull back accordingly in the reducer (and the binding() call goes there instead)
The inconvenient part is the boilerplate needed to install a read-write sub-state of the state.
Using something like #451 may help, though (I still need to open source the protocolized version)
We are also potentially using two ViewStores at the same time in the same view, which could probably be confusing.

Use the whole state with custom deduplication.

By using something like the DeduplicationScope exposed in #527, one can easily chisel a removeDuplicate function for any State by simply specifying a list of relevant KeyPath. However, This is error-prone, as one can easily forget to update the list when adding new properties to the state. But the ViewStore work with the same state as the Reducer and bindings are working out of the box.

Use something to “relocate” the BindableState<Value>

One can use some additional property wrapper to store the link with the State for example. One can implement the ViewStateBinding property wrapper for example:

@propertyWrapper
public struct ViewStateBinding<State, Value> {
  let keyPath: WritableKeyPath<State, BindableState<Value>>
  let bindableState: BindableState<Value>
  init(_ state: State, _ keyPath: WritableKeyPath<State, BindableState<Value>>) {
    self.keyPath = keyPath
    self.bindableState = state[keyPath: keyPath]
  }
  public var wrappedValue: Value { bindableState.wrappedValue }
  public var projectedValue: ViewStateBinding<State, Value> { self }
}

extension ViewStateBinding: Equatable where Value: Equatable {}
extension ViewStateBinding: Hashable where Value: Hashable {}

extension ViewStore {
  public subscript<Source, Value>(
    dynamicMember keyPath: KeyPath<State, ViewStateBinding<Source, Value>>
  ) -> Binding<Value>
  where Action: BindableAction, Action.State == Source, Value: Equatable  {
    let sourceKeyPath = self.state[keyPath: keyPath].keyPath
    return self.binding(
      get: { $0[keyPath: keyPath].wrappedValue },
      send: { .binding(.set(sourceKeyPath, $0)) }
    )
  }
}

We can use this property wrapper as:

struct State {
  @BindableState var string
}

struct ViewState: Equatable {
  @ViewStateBinding<State, String> var string: String
  init(_ state: State) {
    self._string = ViewStateBinding(state, \.$string)
  }
}

The ViewStore's override allows them to work the same at call sites: viewStore.$string.
I'm not particularly happy with their declaration, though: we need to qualify the generics when we declare them, and we have to initialize their private storage with self._string. This is not very elegant, but this is a first draft, and it is very possible that better solutions exist. This can maybe be partially type-erased.
We are de facto linking two KeyPath, so the machinery developed in #451 may be reused at some point.

Are you seeing other alternatives, or some ways to improve the property wrapper solution?

[stephencelis]

@tgrapperon Thanks for starting the discussion! It is actually totally possible for ViewState and ViewAction to work with binding helpers, previously and currently with the new helpers, and is why BindingAction.pullback exists. We unfortunately don't have a lot of documentation, though, so the "how to" is a bit elusive. It currently involves a few steps:

• Making sure ViewState annotates its fields with BindableState
• Making sure ViewAction conforms to BindableAction and has a case(BindableAction<ViewState>)
• Making sure State has a WritableKeyPath to ViewState by defining a computed property with get and set (set only needs to work for bindable state, technically)
• Using BindingAction.pullback with that key path wherever you transform ViewAction into Action.

Here's an example in the Tic Tac Toe demo, which heavily adopts view state:

https://github.com/pointfreeco/swift-composable-architecture/compare/tic-tac-toe-bindings

[stephencelis]

I've added some basic documentation here: #771

[tgrapperon]

Too bad we can't annotate individual enum cases with some kind of property wrapper. We would need some intermediary type between enum & structs for actions, with the exhaustiveness checks and ease of declaration on one side, and a little more room to encode different behaviors on the other side (binding, embedding, collection-embedding, internal, auto-cancellable, background, etc.). With ResultBuilders, it may be possible to conveniently instantiate some predefined container types of a fixed size. I'll play with the idea to see if exhaustiveness checks can be restored at build time.

[tgrapperon]

I've added some basic documentation here: #771

Thanks!

[tkoehlerlg]

Hey @stephencelis,
Could you add a documentation for this with the new Composable Logic? Like how to maintain @BindableState while using observe with a ViewState in WithViewStore.

Thank you for your help!
Torben

[stephencelis]

@tkoehlerlg I think all the docs should be updated...did we miss something? If you're having trouble, want to start a new Q&A discussion with your code?

[tgrapperon]

I've realized that we can define a convenient ViewStore method to instantiate bindings when using a ViewState in a more convenient way: We tap the ViewState in the getter, but we directly send to the State'. To make it short, with instantiate the binding with both KeyPaths (from the State and the ViewState), and we don't have to modify anything else.

The immediate advantage is that it works out of the box when using a ViewState (or not, so the transition easier):

• We don't need to annotate ViewState properties with @BindableState;
• We don't need to bubble up the ViewState type into the domain's Action;
• We don't need to pullback the binding;
• We still need to annotate bindable State properties with @BindableState, and still have the same safeguards against unaccounted state mutations.

One inconvenient is that is introduces a degree of freedom where we can mismatch State and ViewState properties, but this is the same risk as using .binding(get:send:). It also only concerns bindings where the ViewState is merely shadowing the State's bindable properties, and exposes the same values.

I don't know how to name this method, nor if the ViewState's KeyPath should go in first position or not. I'm proposing the latter as an example:

public extension ViewStore {
  func binding<ParentState, Value>(
    _ parentKeyPath: WritableKeyPath<ParentState, BindableState<Value>>,
    as keyPath: KeyPath<State, Value>
  ) -> Binding<Value>
    where Action: BindableAction, Action.State == ParentState, Value: Equatable {
    binding(
      get: { $0[keyPath: keyPath] },
      send: { .binding(.set(parentKeyPath, $0)) }
    )
  }
}

Using this method, one can instantiate a binding using

viewStore.binding(\.$property, as:\.viewStateProperty) // vs. viewStore.binding(\.$property) without a ViewState

with \.$property a State KeyPath, and \.viewStateProperty a ViewState KeyPath.

When switching from Store<State, _> to Store<ViewState, _> for performance reasons, we simply have to append , as: \.viewStateProperty to existing bindings.

What are you thinking about this? Do you see a better way to name/arrange things?

[JackYoustra]

I've missed this for a while and wish I'd seen it earlier. Is there any chance it could be included in the library?

[tgrapperon]

Always in the spirit of making TCA bindings work in foreign domains, I would like to mention the bimap method that transforms a Binding<T> into a Binding<U> by providing the from/to transforms T <-> U:

public extension Binding {
  func bimap<T>(get: @escaping (Value) -> T, set: @escaping (T) -> Value) -> Binding<T> {
    .init {
      get(wrappedValue)
    } set: { newValue in
      withTransaction(transaction) {
        wrappedValue = set(newValue)
      }
    }
  }
}

This function is particularly convenient when the state's type is different from the binding's expected type. For example, when the state exposes a String?, and the control expects a String, or a two-cases enum vs a Bool, or some hex color string vs a CGColor, etc.

One classical approach is to define a computed property in State to handle the conversions in both directions. Unfortunately, such a computed property can't be decorated with the property wrapper@BindableState, and thus can't be bound using tools provided by TCA. With the bimap function, one can defer the transformation to the moment the binding is formed, and still use TCA bindings in the exact same way.

For example, if @BindableState var hexColor: String is a hexadecimal color in State, fromHex: (String) -> CGColor a function that instantiates a CGColor from a hex string, and toHex: (CGColor) -> String a function that converts a CGColor to an acceptable hex string, we can create a Binding<CGColor> suitable for ColorPicker using:

viewStore.binding(\.$hexColor).bimap (get: fromHex, set: toHex)

One drawback is that it's a tiny bit of logic happening inside the View's body, hence difficult to test. However, the work that happens in the bimap blocks is merely a translation from one type to another, and the mappings should be able to be unit-tested in a classical fashion.

One can also define

public extension Binding {
  func emptyIfNil<T>() -> Binding<T> where Value == T?, T: RangeReplaceableCollection {
    bimap(get: { $0 ?? T() }, set: { $0.isEmpty ? .none : $0 })
  }

  func nilIfEmpty() -> Binding<Value?> where Value: RangeReplaceableCollection {
    bimap(get: { $0.isEmpty ? .none : $0 }, set: { $0 ?? Value() })
  }
}

which can be convenient to bridge String? <-> String for example.

This can probably be reformulated in a more general framework. Please let me know if you have any idea/comment!