Enhancing AlertState Ergonomics: Some Considerations

[RoBo-Inc]

The Problem

@Presents var alert: AlertState<Action.Alert>?
Well... it looks weird. Action.Alert --> Alert.Action would feel more natural:
@Presents var alert: AlertState<Alert.Action>?

When working with enum Destination, we tend to define it outside enum Action. For example:

    @ObservableState
    struct State: Equatable {
        @Presents var destination: Destination.State?
    }
    
    enum Action {
        case buttonTapped
        case destination(PresentationAction<Destination.Action>)
    }
    
    @Reducer
    enum Destination {
        case modal(Modal)
    }

But actions for an alert we define inside enum Action. For example:

    enum Action {
        case buttonTapped
        case alert(PresentationAction<Alert>)
        
        @CasePathable
        enum Alert {
            case stopButtonTapped
            case deleteButtonTapped
        }
    }

So, some inconsistency here. Which, by the way, causes the "wrong" order from 1.

And there's more.
enum Alert doesn't actually contain alerts. It rather contains actions 😳
It can be a bit confusing.

As for alerts themselves, there is the concept of AlertState. For example:

extension AlertState where Action == DownloadComponent.Action.Alert {
    static let stop: Self = .init {
        TextState("Do you want to stop the downloading?")
    } actions: {
        ButtonState(role: .cancel) { TextState("Nevermind") }
        ButtonState(role: .destructive, action: .send(.stopButtonTapped)) { TextState("Stop") }
    }
    
    static let delete: Self = .init {
        TextState("Do you want to delete the downloaded data from your offline storage?")
    } actions: {
        ButtonState(role: .cancel) { TextState("Nevermind") }
        ButtonState(role: .destructive, action: .send(.deleteButtonTapped)) { TextState("Delete") }
    }
    
    static func ok(message: String) -> Self {
        .init {
            TextState(message)
        } actions: {
            ButtonState(role: .cancel) { TextState("Ok") }
        }
    }
}

It feels a bit boilerplaty and introduces some library-specific, rather internal, terms (TextState, ButtonState), which might be unnecessarily intimidating. Plain strings would feel much friendlier.

The Solution

Now, I’d like to propose a (fully backward-compatible) solution for all the issues above ☺️

    @ObservableState
    struct State: Identifiable, Equatable {
        @Presents var alert: AlertState<Alert.Action>?
    }
    
    enum Action {
        case buttonTapped
        case alert(PresentationAction<Alert.Action>)
    }
    
    enum Alert: CaseIterable {
        case stopDownloading
        case deleteDownloaded
        case urlNotProvided
        
        @CasePathable
        enum Action: Sendable {
            case stopButtonTapped
            case deleteButtonTapped
        }
    }

It looks symmetric, consistent and straightforward. It's also convenient to see all alerts and all alert actions in one place.
But of course, that's not enough, as we still need to provide all the detailed information—titles, labels, messages, etc.

extension DownloadComponent.Alert: AlertStateConvertible {
    var title: String {
        switch self {
        case .stopDownloading: "Do you want to stop the downloading?"
        case .deleteDownloaded: "Do you want to delete the downloaded data from your offline storage?"
        case .urlNotProvided: "url is not provided"
        }
    }
    
    var dismissLabel: String? {
        self =~ [.stopDownloading, .deleteDownloaded] ? "Nevermind" : "Ok"
    }
}

extension DownloadComponent.Alert.Action: AlertAction {
    var buttonLabel: String {
        switch self {
        case .stopButtonTapped: "Stop"
        case .deleteButtonTapped: "Delete"
        }
    }
    
    var isDestructive: Bool {
        self =~ [.stopButtonTapped, .deleteButtonTapped]
    }
}

Yep, all the magic happens in those two new protocols: AlertStateConvertible and AlertAction. And even more important - in their default implementation extensions. These default extensions should cover most of real-world use-cases.
For more complex (and rare) cases - we can fill all the protocol requirements manually. For example: relations between alerts and actions. But, as I already have mentioned, in many cases it can be determined automatically by the protocol default implementations.
And of course, in exceptional situations, we can always use the old approach for more granular control.

The complete source code is available at this link. Feel free to use it in your projects, if you like the proposed approach.
But of course it would be super cool if we could move that code into the PointFree library itself (swift-navigation library I guess 🙄). It's up to Brandon and Stephen 🫣

More Exemples

Meanwhile I can provide a few more examples here.

    @ObservableState
    struct State: Equatablee {
        @Presents var pictureDetail: PictureDetail.State?
        @Presents var alert: AlertState<Alert.Action>?
    }
    
    enum Action {
        case pictureDetail(PresentationAction<PictureDetail.Action>)
        case alert(PresentationAction<Alert.Action>)
    }
    
    struct Alert: AlertStateConvertible {
        let title: String
        let message: String?
        
        init(_ error: some Error) {
            title = "⚠️ \(type(of: error))"
            message = error.localizedDescription
        }
    }

• if a screen only have one alert, we can use a struct instead of enum
• if there is no actions (only a single dismiss button) we can omit enum Action entirely (the Action type will be defaulted to Never)

You can find one more example at this link. It's a fully functional toy app. By comparing the very last two commits you can see the difference in code between the two approaches.

Thank you for attention. Looking forward to feedbacks 🤗

[mbrandonw]

Hi @RoBo-Inc, for points 1 through 3, there is nothing stopping you from doing this if you wish:

@Reducer
struct Modal {
  @ObservableState
  struct State: Equatable {
    @Presents var alert: AlertState<AlertAction>?
  }

  enum Action {
    case alert(PresentationAction<AlertAction>)
    …
  }

  enum AlertAction {
    case closeModal
    case doSmthElse
  }

  …
}

We do not require that the enum for alert actions exist inside Action. It's just a pattern we follow. But if you wish to change things that is fine.

It feels a bit boilerplaty and introduces some library-specific, rather internal, terms (TextState, ButtonState), which might be unnecessarily intimidating. Plain strings would feel much friendlier.

While strings would be friendlier, it would also lose out on the ability to specify localization keys, accessibility, styling modifiers, etc. And it's worth noting that SwiftUI does not even allow bare strings:

.alert(isPresented: .constant(false), error: SomeError()) { _ in
  "OK"  // 🛑
} message: { _ in
  "Message"  // 🛑
}

You can find one more example at this link. It's a fully functional toy app. By comparing the very last two commits you can see the difference in code between the two approaches.

Looking at the diff, it is not clear to me that is one approach is obviously better than the other. It really seems like a personal preference. Your approach may have gotten rid of TextState and ButtonState, but it also spread the details of the alert across multiple properties instead of having everything in one place.

Luckily everything you want can be accomplished outside of our libraries and so you can definitely pursue this style if it speaks to you. But we are not likely to bring any of these changes into the libraries unless concrete benefits can be demonstrated.

[RoBo-Inc]

Yeah, fair enough. Thanks 🙏