Updating View States in Action Blocks

[ravilich86]

First of all, thank you for lowering the Swift version requirement to 5.9. This really helped, and I greatly appreciate your attention to users' needs.

Description

I've encountered an issue with updating view states in action blocks when using the custom alert from your library. There's a difference in behavior between the standard alert and the customAlert provided by your library.

Steps to Reproduce

1. Create a view with a state variable for password and a binding for alert presentation.
2. Implement an alert using the standard SwiftUI alert modifier.
3. Implement the same alert using the customAlert modifier from your library.
4. Observe the behavior of the "Remove" button's disabled state in both cases.

Expected Behavior

The "Remove" button should be enabled/disabled based on the password length, updating in real-time as the user types.

Actual Behavior

The "Remove" button's state doesn't update when using customAlert, while it works correctly with the standard alert.

Code Examples

Working example with standard alert:

.alert("Account removing", isPresented: $shouldRemove) {
    SecureField("Current password", text: $password)
        .padding(.top, 10)
    Button("Cancel", role: .cancel) {}
    Button("Remove", role: .destructive) {}
        .disabled(password.count < 6)
}

Not working example with customAlert:

.customAlert("Account removing", isPresented: $shouldRemove) {
    SecureField("Current password", text: $password)
        .padding(.top, 10)
} actions: {
    Button("Cancel", role: .cancel) {}
    Button("Remove", role: .destructive) {}
        .disabled(password.count < 6)
}

I also tried placing the buttons in the alert body, but it didn't help:

.customAlert("Account removing", isPresented: $shouldRemove) {
    SecureField("Current password", text: $password)
        .padding(.top, 10)
    Button("Cancel", role: .cancel) {}
    Button("Remove", role: .destructive) {}
        .disabled(password.count < 6)
}

Questions

1. Is this related to the internal workings of the library?
2. Am I missing something in my implementation?
3. Is there a way to achieve the same behavior as in the standard alert?

Any help or clarification on this issue would be greatly appreciated. Thank you for your time and assistance!

Environment

• iOS version: 17.6.1
• Swift version: 5.9
• Xcode version: 15.2
• Library version: 3.8.0

[ravilich86]

I've found a similar issue (#15) that seems to describe the same problem I'm experiencing. My use case is identical to the one described there. It appears that this issue was resolved in version 3.5.0 of the library.

[ravilich86]

I've just checked the demo application, and I noticed that the button there also remains inactive. This seems to confirm that the behavior is consistent across the library implementation.

Given this observation, I was wondering if it would be possible to modify this behavior to allow for dynamic button state updates within the alert? This functionality would be incredibly helpful for user input validation and improving overall user experience.

If such a change is feasible, I would be extremely grateful. It would significantly enhance the flexibility and usability of the customAlert in various scenarios.

Thank you for considering this request. I really appreciate your time and effort in maintaining and improving this library.

[divadretlaw]

Thank you very much for reporting this issue.

In order to fix #22 I had to restructure how propagating the view state to the window works and while I tested that I refactored it after but I haven't tested it with the refactored version.

I pushed a new version to WindowKit so fetching the latest packages should fix it, already but I will also release a new CustomAlert version where the minimum required version includes the fix.

Thank you with providing the examples, they help a lot and make fixing things easier.

[divadretlaw]

Should be fixed (again) in 3.8.1