Alert with TextField or SecureTextField

[trispo]

Hi,

is it possible to create an AlertState with state for a TextField and/or a SecureField?

Thx
@trispo

[tw0po1nt]

@mbrandonw Would love to see this added to a future version. Any idea if this is on the roadmap at all? I bet you if this were added as a proper issue, you could get someone to help out with it 😀

[mbrandonw]

If anyone wants to take a stab at this feature then please do share what you come up with!

[acosmicflamingo]

I've tried tackling this for the last few days and have found that in order for anyone to take this task on, a few fundamental questions need to be answered. Before we go to that, let's work from what we'd ideally want, and derive the fundamentals from there.

Ideally, a user would want to create an AlertState object in this fashion:

let alert = AlertState {
  TextState("Fact about \(count)")
} actions: {
  ButtonState(role: .destructive) {
    TextState("OK")
  }
  TextFieldState(initialText: "LOL", action: .getFact) {
    TextState("Get another fact")
  }
  ButtonState(role: .cancel) {
    TextState("LOL")
  }
} message: {
  TextState(fact.description)
}

Based on that, we know that AlertState initializer should accept an array of ButtonState and TextFieldState objects. That alone means there needs to be something that ties ButtonState and AlertState together, and protocols seems like the perfect thing for it. Starting in iOS 16, runtime support for parameterized protocol types was supported, which means that we could add this kind of property to AlertState:

public struct AlertState<Action> {
  public var actions: [any ActionState<Action>] = []
}

But, it seems like a bad idea to now make AlertState require iOS 16.0 just to use TextFieldState, so we have two options for creating an actions array of ButtonState and TextFieldState objects: using enums, or type-erasure. The latter seems a bit silly to start out with because it would seem useful to know what types we're dealing with, so let's go with enums:

public enum AnyActionState<Action> {
  case .button(ButtonState<Action>)
  case .textField(TextFieldState<Action>)
}

Of course, we don't want public API to now require users wrap objects like ButtonState and TextFieldState with enums; so conforming ButtonState and TextFieldState to ActionState protocol would allow us to keep the API we want:

public struct AlertState<Action> {
  public var actions: [AnyActionState<Action>] = []
  /* ... */
  public init(
    actions: [any ActionState<Action>]
  ) {
    buttons.compactMap {
      switch $0 {
      case let buttonState as ButtonState<Action>:
        .button(buttonState)

      case let textFieldState as TextFieldState<Action>:
        .textField(textFieldState)

      default:
        nil
      }
    }
  }
}

Unfortunately, this change now means we have to reassess what it means to map AlertState from one domain to another. This was easy before, when we had an array of one type. It does seem like adding a map function to ActionState protocol would be the solution, but we can't assume that map would have the same parameters. Depending on how TextFieldState is designed, it may not be enough to map TextFieldState<Action> to TextFieldState<NewAction> using transform: (Action) -> NewAction. This is especially the case if TextFieldState were to utilize case paths of type AnyCasePath<Action, String>. Perhaps we could make it easier on ourselves if we instead have two arrays [ButtonState<Action>] and [TextFieldState<Action>]. That would perhaps make things a bit easier, although now we lose the order of the ActionState objects, and creating a new array to keep track of the order now seems to be over-engineering what we're trying to achieve here.

Instead of putting much of the focus on how AlertState will comprise these new ActionState objects, perhaps we can focus on TextFieldState, which is what we originally want to create. Here is where we have to answer some fundamental questions:

1. What is TextFieldState's function? Is it meant to actually hold the latest text that was entered, making something like this possible: print("Text in text field:", textFieldState.text)? How would it be stored?

public struct TextFieldState<Action> {
  // Option 1
  //   - Mutated outside of object
  public var text: String
  
  // Option 2
  public var action: Action
  public var actionCasePath: AnyCasePath<Action, String>
  public var text: String {
    // It's possible to use an AnyCasePath<Action, String> to populate action
    // with the text:
    //
    //   let text = textField.text ?? ""   <= actual text field view
    //   textFieldState.action = textFieldState.actionCasePath.embed(text)
    //
    // However, it seems impossible to now extract this 
    // text from action
    action.???
  }
  
  // Option 3
  //  - Allows us to extract action, but this becomes useless
  //    when trying to map TextFieldState<Action> to
  //    TextFieldState<NewAction> since there's no easy way
  //    to map AnyCasePath<Action, String> to AnyCasePath<NewAction, String>
  //    without using something like AnyCasePath<NewAction, Action>,
  //    which definitely seems promising for mapping, instead of
  //    using (Action) -> NewAction closure that ButtonState uses
  public var actionCasePath: AnyCasePath<Action, String>
  public var text: String
  public var action: Action {
    actionCasePath.embed(text)
  }
}

I'm not even bringing up how this makes conforming to Equatable and Sendable protocol that much more difficult.

2. What do we lose by simply treating TextFieldState as a proxy that forwards actions to the model? Certainly looks easier, and could be why Stephen's original prototype went this route. Unfortunately, I'm also hitting the same issue with not knowing how to map TextFieldState<Action> to TextFieldState<NewAction>.
3. Once a user taps "OK", how do we get access to text field's text? Should its action be fired every time text is mutated? How do we differentiate between a user mutating text field and when a user has finally selected a confirm button that closes the alert?
4. Do we even want to bind text field's state to our model when we only want to act on whatever text field's state was after the alert is closed?

These are all the kind of questions that have made pushing a functioning PR a lot harder than I was hoping. Maybe others have some ideas and suggestions that can pave the path forward, but as of now I think I've hit a wall and can't progress further without coming up with a different way of approaching the problem.

[mbrandonw]

While it would be great to have support for TextFieldState and SecureFieldState, I do hope people know that our lack of support does not block one from using these APIs in a TCA app. You simply need to hold onto extra state in your domain and derive a binding to it in the view. It should work the exact same way it does for vanilla SwiftUI.

// TCA
@Reducer struct Feature {
  struct State {
    var isAlertPresented = false
    var name = ""
    // ...
  }
  // ...
}
struct FeatureView: View {
  @Bindable var store: StoreOf<Feature>
  var body: some View {
    Text("Name is: \(store.name)")
      .alert("Enter your name", isPresented: $store.isAlertPresented) {
        TextField("Enter your name", text: $store.name)
        Button("OK") { store.send(.okButtonTapped) }
      }
  }
}

// Vanilla SwiftUI
struct FeatureView: View {
  @State var isAlertPresented = false
  @State var name = ""
  var body: some View {
    Text("Name is: \(name)")
      .alert("Enter your name", isPresented: $isAlertPresented) {
        TextField("Enter your name", text: $name)
        Button("OK") { /* ... */ }
      }
  }
}

It may not be as testable as if we had full support for text fields in AlertState, but I also don't think there is that much to test.

So, I hope no one thinks that they are being held back from SwiftUI features because of TCA. At the end of the day we want everything from SwiftUI to be available to you.

[acosmicflamingo]

I'll have to try and see if the same approach can be done with UIKit. I've been using present(item) API and based on your answer, I'm now going to have to add if statements in the present closure checking something like this using static variables of AlertState types:
if alertState.title == .editSongName.title.

Thinking of how to go about with this did make me realize something; we are making an assumption that an alert should be able to show buttons and text fields in any order and maybe that is our problem here. I've always seen alerts show the text fields first, and then buttons after. Perhaps this means we don't need enum or protocols, and we can simply just add a new textFields property of type [TextFieldState]! Should I continue to try and pursue this? Or do you all feel that an alert should be able to present a text field and buttons in any order?

[acosmicflamingo]

Funny enough, I found that my own code was programmatically inserting text fields after UIAlertController(store:) was called, and yet they were always before the buttons when the alert was actually presented. This means it seems like there's nothing wrong with taking this kind of approach:

public struct AlertState<Action> {
  public var buttons: [ButtonState<Action>]
  public var textFields: [TextFieldState<Action>]
  
  public init(actions: [any ActionState<Action>]) {
    self.buttons = actions.compactMap({ $0 as? ButtonState<Action> })
    self.textFields = actions.compactMap({ $0 as? TextFieldState<Action> })
  }
}

That would make it possible for me to then update the UIAlertController initializer to configure text fields in this manner:

extension UIAlertController {
  public convenience init<Action>(
      state: AlertState<Action>,
      handler: @escaping (_ action: Action?) -> Void = { (_: Never?) in }
    ) {
      self.init(
        title: String(state: state.title),
        message: state.message.map { String(state: $0) },
        preferredStyle: .alert
      )
      for button in state.buttons {
        addAction(UIAlertAction(button, action: handler))
      }
      // var count = 0
      for textField in state.textFields {
        // Written based on false assumptions
        // addTextField { textFieldView in
        //   let text = textFieldView.text ?? ""
        //   textField.withAction(handler, text: text)
        // }
        // self.textFields?[count].text = textField.initialText
        // self.textFields?[count].placeholder = textField.placeholderText
        // count += 1
        
        // How addTextField should actually be used
        // addTextField {
        //   $0.text = textField.initialText
        //   $0.placeholder = textField.placeholderText
        // }
      }
    }
  }
}

Edit: whoops; looks like addTextField {} is meant for configuring and is only called once. Need to figure out how I'll be able to forward text changes back to model.

[randomeizer]

To be honest, while AlertState is handy, I've always felt that it's essentially the state describing the UI, vs the usual in TCA where the UI presents the state.

I prefer to use the View.alert(item: Binding<...>, ...) overloads in the SwiftUINavigation library, here:

https://github.com/pointfreeco/swift-navigation/blob/main/Sources/SwiftUINavigation/Alert.swift

They let you provide an optional piece of state representing the details of the alert explicitly, and provides closure hooks for using that non-optional state as actions/title/message for the alert. So, you could define something like (untested, missing protocols, etc):

// TCA
@Reducer struct Feature {
  @Reducer struct Authenticate {
    struct State: Equatable {
      var username: String 
      var password: String
      var errorMessage: String?
    }
    public enum Action {
      case logInButtonTapped(String username, String password)
      case cancelButtonTapped
    }
    // ..
  }

  struct State {
    var authenticate: Authenticate?
    // ...
  }
  // ...
}
struct FeatureView: View {
  @Bindable var store: StoreOf<Feature>
  var body: some View {
    Text("Name is: \(store.name)")
      .alert(item: $store.authenticate) { _ in
        "Please authenticate."
      } actions: { authStore in
        TextField("Username", text: $authStore.username)
        SecureField("Password", text: $authStore.password)
        Button("Log In") { authStore.send(.logInButtonTapped(authStore.username, authStore.password)) }
        Button("Cancel") { authStore.send(.cancelButtonTapped) }
      } message: {
        $0.errorMessage ?? "Enter your details."
      }
  }
}

[acosmicflamingo]

I don't think UIKit has anything analogous to that; it only has a helper that accepts an AlertState object as a parameter: https://github.com/pointfreeco/swift-navigation/blob/main/Sources/UIKitNavigation/Navigation/UIAlertController.swift. Now, I could instead use present(item:) from here and derive the UIAlertController I want, but is there a clean way to do this when my alerts may be modeled like this?

public enum Destination {
  case alert(AlertState<Alert>)
  public enum Alert: Equatable {
    case errorOccurred
    case saveLoop(SaveLoop)

    public enum SaveLoop: Equatable {
      case updateLoopText(String)
      case gotItButtonTapped
      case goToSettingsButtonTapped 
    }
  }
}

I guess I'd have to do this:

present(
  item: alertBinding,
  content: { alertStore in
    let alertController = UIAlertController(store: alertStore)
    if alertStore.withState(\.title) == TextState("Edit loop title"),
       store.mediaPlayer.loopingState.is(\.enabled),
       let loop = store.mediaPlayer.loop
    {
      alertController.addTextField()
      alertController.textFields?[0].text = loop.name
      alertController.textFields?[0].placeholder = "Loop title"
      let submitAction = UIAlertAction(
        title: "Save",
        style: .default
      ) { [weak alertController, weak self] _ in
        guard
          let self,
          let alertController,
          let loopName = alertController.textFields?[0].text
        else { return }

        store.send(.destination(.presented(.alert(
          .saveLoop(.updateLoopText(loopName))
        ))))
      }
      alertController.addAction(submitAction)
    }
    return alertController
  }
)

[acosmicflamingo]

In SwiftUI, how do those bindings work with the text field? Am I correct that if I started typing in the "username" text field but hit "Cancel" instead of "Ok", that state.username has been mutated? Shouldn't mutation only occur when user hits okay? Is text field smart enough to undo the mutation when user cancels the alert?

[lukaskubanek]

To be honest, while AlertState is handy, I've always felt that it's essentially the state describing the UI, vs the usual in TCA where the UI presents the state.

I prefer to use the View.alert(item: Binding<...>, …) overloads in the SwiftUINavigation library (…)

This is exactly what has been bothering me about AlertState as well. Thanks for bringing this up!

I usually only expose an alert enum that describes the kind of the content and optionally contains params as associated values of the cases (e.g. title of the thing to be deleted). Then, I have a way to convert that enum to an AlertState in the view layer by switching on it and plugging in the UI-facing strings. This can be then used with the AlertState-focused .alert(…) modifier while keeping the reducer layer simpler and better testable (no need to care about the exact strings).

I haven’t had a use case for including text fields in alerts so far, but using the generic .alert(…) modifier and storing the state in a dedicated reducer looks like an interesting approach.

[randomeizer]

@acosmicflamingo Yes, because it's via a Binding, the username/password state is updated in real time. I like to think of the state as representing the UI, rather than the "business" state of the application. In simple apps, that could be one and the same, but once you get to anything with larger amounts of data, it's not really going to work.

All that being said, the Authenticate struct above doesn't represent the actual authenticated user, it just repesents what the user is entering for those fields. When the "Log In" button triggers the action, it poses a copy of the current state to the reducer, which would then go and validate/etc, abs store the authenticated user somewhere else.

So, having the value contain the real time contents of the field is fine, imho.

[randomeizer]

@lukaskubanek Yeah, I haven't needed any input fields in my alerts either, I constructed that one as an example. I've used the simpler enum approach as well.

[acosmicflamingo]

After messing around with this more in UIKit, I have come to appreciate what you all are suggesting about using some extra state in the view domain to support adding text fields in alerts.

It turns out that UIAlertController doesn't have a very clean way of sending actions every time the text field's editChanged action occurs. One can't rely on using UITextFieldDelegate either (I think I remember having to use addAction(target:selector:) because there were instances that the delegate didn't fire when textField.text was programmatically mutated). The best path forward would be using addAction(target:selector), although it unfortunately doesn't support being able to modify the function's parameters (e.g. func textFieldDidChange(_ textField: UITextField)). We can now try and map text field states with their respective view using tags and whatnot, but we're now in hacky territory and one begins to wonder if it's even worth trying to add TextFieldState support to AlertState.

One other approach (for UIKit developers) could be adding a UIBinding<String> property in TextFieldState that can now sync the text field state with what's currently in the text field. This already is not great because AlertState is used in SwiftUI, so we'd have to add some #if canImport(UIKit) pragmas. Even then, how would I be able to pass the UIBinding instance to the TextFieldState initializer when I'm creating the states within my reducer? This is what has led me to realize that the best path forward is definitely adding some logic in my view domain to handle text fields.

Going with that approach, I can easily create a UIBinding<String> instance that will bind to the UIAlertController's respective text field. This makes it pretty easy to then access and pass to the store via an action when a user taps the alert button:

class MyViewController: UIViewController {
  public func viewDidLoad() {
    super.viewDidLoad()
    
    present(
      item: $store.scope(
        state: \.destination?.alert,
        action: \.destination.alert
      )
    ) { [weak store] alertStore in
      let alertState = alertStore.withState({ $0 })
      let alertController = UIAlertController(store: alertStore)
      with(alertController, Styling.uiAlertController.A11y.configure)
      switch alertState {
      case .updateLoopName:
        guard let loopName = store?.mediaPlayer.loop?.name
        else { return alertController }
        let loopTitleBinding = UIBinding(wrappedValue: loopName)
        alertController.addTextField {
          $0.placeholder = "Loop title"
          $0.bind(text: loopTitleBinding)
        }
        let saveButtonState = ButtonState<Home.Destination.Alert> {
          TextState("Save")
        }
        let saveAction = UIAlertAction(
          saveButtonState,
          action: { [weak alertStore] _ in
            let loopTitle = loopTitleBinding.wrappedValue
            alertStore?.send(.saveLoop(.updateLoopName(loopTitle)))
          }
        )
        alertController.addAction(saveAction)

      default:
        break
      }
      return alertController
    }
  }
}

This approach is great too because the swift-navigation API no longer has to think about all these corner cases to make TextFieldState usable and easy to work with.

Thank you everyone for dealing with my spam and providing your insight! I have once again managed to dodge for another day having to learn the perfect, definitely-ready-for-production, get-all-the-attention SwiftUI framework 😜