Formalizing binding / form validation

[rzulkoski]

Hello, I'm currently toying around with some different ways to enhance the @BindableState property wrapper to accept a list of validation rules that can be run automatically any time the value changes. I have my idea working to some extent in a proof-of-concept and am hoping to get some ideas on how to handle validation rules that span multiple properties.

My definition of @BindableState currently looks like this:

@dynamicMemberLookup
@propertyWrapper
public struct BindableState<Value>: ValidatableBinding {
  public var wrappedValue: Value
  public let rules: [ValidationRule<Value>]
  public private(set) var isValid: Bool = true
  public private(set) var violatedRules: [ValidationRule<Value>] = []

  public init(wrappedValue: Value, _ rules: [ValidationRule<Value>]) {
    self.wrappedValue = wrappedValue
    self.rules = rules
    self.validate()
  }

  public init(wrappedValue: Value, _ rules: ValidationRule<Value>...) {
    self.init(wrappedValue: wrappedValue, rules)
  }

  public var projectedValue: Self {
    get { self }
    set { self = newValue; self.validate() }
  }

  public subscript<Subject>(
    dynamicMember keyPath: WritableKeyPath<Value, Subject>
  ) -> BindableState<Subject> {
    get { .init(wrappedValue: self.wrappedValue[keyPath: keyPath]) }
    set { self.wrappedValue[keyPath: keyPath] = newValue.wrappedValue }
  }

  private mutating func validate() {
    var violatedRules = [ValidationRule<Value>]()
    for rule in self.rules {
      if !rule.condition.evaluate(wrappedValue) {
        violatedRules.append(rule)
      }
    }
    self.isValid = violatedRules.isEmpty
    self.violatedRules = violatedRules
  }
}

This allows me to define properties and rules like this:

struct ChangePasswordState: ValidatableState {
  @BindableState(.required) var oldPassword  = ""
  @BindableState(.required) var newPassword  = ""
  @BindableState(.required) var confirmNewPassword  = ""

  var isValid = false // Managed by an overload of the`.binding()` higher-order reducer
}

However, I'm having a bit of trouble trying to model how to attach a rule saying that the newPassword and confirmNewPassword properties need to match. Perhaps attaching this to the property wrapper is too limiting? It has been pretty nice in my testing though, as I can access the violated rules from the binding in the view which allows me to give feedback to the user:

VStack(alignment: .leading) {
  TextField("Old Password", text: viewStore.$oldPassword)
    .textFieldStyle(.roundedBorder)
    .border(viewStore.$oldPassword.isValid ? Color.gray : Color.red)
  ForEach(viewStore.$oldPassword.violatedRules) { rule in 
    Text("Some rule-specific feedback")
  }
}

Thoughts?

[stephencelis]

One thought is that property wrappers compose, so you should be able to introduce a new property wrapper for validation:

@BindableState @Validate(.required) var oldPassword = ""

Navigating through each layer may be a bit cumbersome, though, and/or require some more dynamic member lookup overloads.

[rzulkoski]

That's a good point. For some reason I had it in my head that they didn't compose. I'll explore this a bit further. Thanks @stephencelis!

[rzulkoski]

In my testing, one barrier to composing the @BindableState property wrapper with other wrappers is that BindingAction doesn't have a public initializer. Would that be something that you would consider adding to the library?

[stephencelis]

@rzulkoski BindingAction is publicly constructible using BindingAction.set.

[rzulkoski]

When I attempt to add an dynamic member lookup overload on ViewStore I get the error No exact matches in call to static method 'set'.

extension ViewStore {
  public subscript<Value>(
    dynamicMember keyPath: WritableKeyPath<State, BindableState<Validate<Value>>>
  ) -> Binding<Value> where Action: BindableAction, Action.State == State, State: ValidatableState, Value: Equatable {
    self.binding(
      get: { $0[keyPath: keyPath].wrappedValue.wrappedValue },
      send: { .binding(.set(keyPath, $0)) }
    )
  }
}

The only way I got it to work is by also adding a specialized set to BindingAction after making a public init.

public extension BindingAction {
  static func set<Value>(
    _ keyPath: WritableKeyPath<Root, BindableState<Validate<Value>>>,
    _ value: Value
  ) -> Self where Value: Equatable, Root: ValidatableState {
    .init(
      keyPath: keyPath,
      set: { state in
        state[keyPath: keyPath].wrappedValue.wrappedValue = value
        state[keyPath: keyPath].wrappedValue.validate(state)
      },
      value: value,
      valueIsEqualTo: { $0 as? Value == value}
    )
  }
}

It's certainly possible that I'm not specializing my subscript overload on ViewStore properly. I can confirm that my way does work in the end, but perhaps there's a better way?

[igormagurean]

Any examples how @BindableState can work together with @validated? How to access validated properties in swift body, via _ or $ ..

[tgrapperon]

$ exposes the projected value which is, in the case of BindableState, the wrapped property itself: BindableState<T>. It means that you can open the BindableState using $ and drill down to its wrappedValue which is the wrapped property Validated<V>.
So it should work like this for @BindableState @Validate(.required) var oldPassword: String

• \.oldPassword: String, the value;
• \.$oldPassword: BindableState<String> the bindable validated state;
• \.$oldPassword.wrappedValue: Validated<String>, the validated string.

You should usually not rely on _, excepted in rare occasions where you want to assign a wrapped value in some initializer for example. I don't think there's another way like \.$$oldPassword for example. Composed property wrappers are nicer when you only want their side-effects, otherwise, it gets quickly cumbersome. In specific cases, you can probably implement a few dedicated overloads to make your life easier.

[NFulkerson]

First of all, lots of great ideas here. A property wrapper like @Validate would come a long way toward handling many common use cases. I am curious to know what other techniques folks are using to handle form validation in TCA apps, whether its via property wrappers or a higher order reducer or something else entirely. Complex requirements can get really sticky really fast, as you may want or need all of these things:

• run a single validator on user input (easy enough)
• run a validator on previous fields if another field receives focus, eg: raise error on an empty username field if password is focused first
• run all validators when a user interacts with a button
  • or drive a button's state on the validity of every field's state
• guarantee equality between two fields
• probably lots of other things I haven't thought to mention here!

[ArmenNik]

Hello, I'm currently toying around with some different ways to enhance the @BindableState property wrapper to accept a list of validation rules that can be run automatically any time the value changes. I have my idea working to some extent in a proof-of-concept and am hoping to get some ideas on how to handle validation rules that span multiple properties.

My definition of @BindableState currently looks like this:

@dynamicMemberLookup
@propertyWrapper
public struct BindableState<Value>: ValidatableBinding {
  public var wrappedValue: Value
  public let rules: [ValidationRule<Value>]
  public private(set) var isValid: Bool = true
  public private(set) var violatedRules: [ValidationRule<Value>] = []

  public init(wrappedValue: Value, _ rules: [ValidationRule<Value>]) {
    self.wrappedValue = wrappedValue
    self.rules = rules
    self.validate()
  }

  public init(wrappedValue: Value, _ rules: ValidationRule<Value>...) {
    self.init(wrappedValue: wrappedValue, rules)
  }

  public var projectedValue: Self {
    get { self }
    set { self = newValue; self.validate() }
  }

  public subscript<Subject>(
    dynamicMember keyPath: WritableKeyPath<Value, Subject>
  ) -> BindableState<Subject> {
    get { .init(wrappedValue: self.wrappedValue[keyPath: keyPath]) }
    set { self.wrappedValue[keyPath: keyPath] = newValue.wrappedValue }
  }

  private mutating func validate() {
    var violatedRules = [ValidationRule<Value>]()
    for rule in self.rules {
      if !rule.condition.evaluate(wrappedValue) {
        violatedRules.append(rule)
      }
    }
    self.isValid = violatedRules.isEmpty
    self.violatedRules = violatedRules
  }
}

This allows me to define properties and rules like this:

struct ChangePasswordState: ValidatableState {
  @BindableState(.required) var oldPassword  = ""
  @BindableState(.required) var newPassword  = ""
  @BindableState(.required) var confirmNewPassword  = ""

  var isValid = false // Managed by an overload of the`.binding()` higher-order reducer
}

However, I'm having a bit of trouble trying to model how to attach a rule saying that the newPassword and confirmNewPassword properties need to match. Perhaps attaching this to the property wrapper is too limiting? It has been pretty nice in my testing though, as I can access the violated rules from the binding in the view which allows me to give feedback to the user:

VStack(alignment: .leading) {
  TextField("Old Password", text: viewStore.$oldPassword)
    .textFieldStyle(.roundedBorder)
    .border(viewStore.$oldPassword.isValid ? Color.gray : Color.red)
  ForEach(viewStore.$oldPassword.violatedRules) { rule in 
    Text("Some rule-specific feedback")
  }
}

Thoughts?

Hi can you please share ValidatableBinding protocol implementation

[rzulkoski]

Hi @ArmenNik, I kept running into roadblocks and abandoned this idea. I hope you have better luck if you attempt it!

[NFulkerson]

I know this discussion is older, but I realized I never shared what I came up with when I was thinking about this same thing. It has a caveat, though. I'm pretty sure I'm doing something we are told explicitly not to do--using an action to share some behavior with other actions. With a bit of extra thought and work, I think this could become a higher-order reducer, and with a bit more work maybe even be extrapolated out into a dependency to run the actual validation logic.

Suppose I have a simple registration form for a booking. I have shortened it for brevity's sake:

public struct BookingFeature: Reducer {
  public struct State: Equatable {
     @BindableState public var firstName: String = ""
     @BindableState public var lastName: String = ""
     @BindableState public var phoneNumber: String = ""
     @BindableState public var email: String = ""
  }
  public struct FieldError: Equatable {
      public var firstName: [ValidationError] = []
      public var lastName: [ValidationError] = []
      public var phoneNumber: [ValidationError] = []
      public var email: [ValidationError] = []

     var isEmpty: Bool {
        [firstName, lastName, phoneNumber, email].allSatisfy { $0.isEmpty }
      }
  } 
  
  public enum Action: BindableAction, Equatable {
    case binding(BindingAction<BookingFeature.State>)
    case validate(PartialKeyPath<BookingFeature.State>)
    case validateForm
    case continueTapped
  }

  public var body: some Reducer<State, Action> {
     BindingReducer()
     Reduce { state, action in
       switch action {
        case let .binding(path):
          return Effect(value: BookingFeature.Action.validate(path.keyPath))
            .debounce(id: path.keyPath, for: 0.2, scheduler: mainQueue)
            .animation()

         case .validate(\.$firstName):
           state.errors.firstName = state.firstName.validName()
           return .none
          //... pattern match on other keypaths we want to validate
         case .continueTapped:
           return .concatenate(
             Effect.merge(
                Effect(value: BookingFeature.Action.validate(\.$firstName),
                // ... other fields
             ),
            Effect(value: .validateForm)
           )
       }
     }
  }
}

What this does is take advantage of our binding action to run additional logic, in this case a debounced effect that sends back a validation action on the keypath. We can then create an action that leverages a partial keypath, allowing us to run individual validation logic on the fields we are interested in. Finally, if a user attempts to continue along in the form, we can merge these actions and run validators against the entire form, then run logic to make sure the form is in a good state before continuing.

There are some problems, though. Maybe the most prominent is that we're sending a validate action on every run of the binding action, though it is debounced. If we have fields that are optional, then we're sending an extra action for no reason. You could match the key paths you want to run validation on, but that creates boilerplate. A property wrapper like @Validatable or @BindableState(.required) might help there.

The other primary issue is that we could be blocking the main thread with long-running effects, as some validation logic might not be trivial. This is where I think creating a dependency could be beneficial -- call out to the dependency sending the value and/or keypath you want validated, along with the ruleset it must pass. Then the dependency can run the validation logic and return an asynchronous effect that returns feedback to the user or system.