Implement a generic AsyncButton with support for throwing closures

[Supereg]

Implement a generic AsyncButton with support for throwing closures

♻️ Current situation & Problem

Currently, Spezi Views (nor SwiftUI) provide a way to easily manage buttons with asynchronous action closures. We have several use cases where a reusable button with an async (throwing) action closure would be helpful (e.g. SpeziAccount for Login/Signup/Password Reset buttons).

💡 Proposed solution

This PR introduces a the new, reusable component AsyncButton that allows to supply async and async throwing action closures. It handles disabling the button and rendering of a processing indicator automatically. To deal with thrown errors of the action closure, we reuse the ViewState abstraction already available in SpeziViews. This can easily be combined with the viewStateAlert(state:) modifier to display a simple error alert.

⚙️ Release Notes

• Added a AsyncButton component for async and async throwing action closures.
• Added the processingDebounceDuration EnvironmentKey for a generalized configuration of debounce durations.
• Added the processingOverlay(isProcessing:overlay) modifier to easily replace a view with a processing indicator.

➕ Additional Information

Related PRs

This PR refines the AsyncDataEntrySubmitButton implementation currently used in the upcoming SpeziAccount PR StanfordSpezi/SpeziAccount#7 and moves it to SpeziViews.

Testing

Additional UI tests were added.

Reviewer Nudging

Ideally, have a look at the added UI tests and then at the AsyncButton implementation itself. It might be helpful to play around with the Previews of AsyncButton as well.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[Supereg]

@PSchmiedmayer SpeziViews seems to have an outdated list of required status checks in the branch protection rule.

[PSchmiedmayer]

Nice, this is a great addition! 🚀
Love the usage of environment values to configure the behaviour, really follows the trend of the latest SwiftUI APIs out there.

Only had a few smaller comments. Feel free to make the conversations as resolved when they are addressed and merge the PR after that 🚀

[PSchmiedmayer]

Fixed the merge check requirements @Supereg 👍

[Supereg]

Fixed the merge check requirements @Supereg 👍

The Upload Coverage Report action is still referencing the old one. If you could update that as well 😇

[codecov]

Codecov Report

Merging #8 (11beb6d) into main (bae5330) will decrease coverage by 1.36%.
The diff coverage is 72.23%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   78.11%   76.74%   -1.36%     
==========================================
  Files          19       22       +3     
  Lines         612      748     +136     
==========================================
+ Hits          478      574      +96     
- Misses        134      174      +40     

Impacted Files	Coverage Δ
...eziViews/Environment/DefaultErrorDescription.swift	100.00% <ø> (ø)
...Views/Environment/ProcessingDebounceDuration.swift	50.00% <50.00%> (ø)
Sources/SpeziViews/Views/Button/AsyncButton.swift	70.80% <70.80%> (ø)
...es/SpeziViews/ViewModifier/ProcessingOverlay.swift	76.48% <76.48%> (ø)
Sources/SpeziViews/Model/ViewState.swift	97.83% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bae5330...11beb6d. Read the comment docs.

[Supereg]

@PSchmiedmayer Do you remember how we fixed the issue of a 0% code coverage 🙈

EDIT: nevermind. Codecov was still outdated.

[Supereg]

Was there an easy way to exclude PreviewProviders from code coverage reporting?

[PSchmiedmayer]

Not really, that is an unfortunate thing that Xcode does not really support. I have tried a lot of things with a dedicated TEST build configuration in the Template App but this wasn't ideal either and results in large build times when switching between DEBUG and TEST builds ...
I can merge the PR like this.

Regarding code coverage: Sometimes Xcode is flaky with the test reporting. If that happens, I have made a good experience adding the target to the build scheme for tests (e.g. SpeziViews in this case):

And then explicitly adding it in the coverage report settings:

[Supereg]

Thanks for the tipps regarding code coverage. feel free to merge 👍