-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit Action state-property convenience initialisers #455
Conversation
It is valid to conditionally unwrap an optional state property, but also want to accept input of a different type. This change adds another convenience initialiser to `Action` that conditionally unwraps, but also preserves the `input` value passed to `apply()`. The new overload uses the parameter label `unwrapping` in order to distinguish it from the version of the initialiser that is generic over `T`. Unfortunately, even if you use a property of optional values, the compiler still selects the more-generic version that accepts any `T` unless a different parameter label is used.
Whenever an action initialiser is intended to conditionally unwrap an optional, it is now labelled as such to avoid ambiguity (both for readers and for the compiler).
Do you find yourself actually wanting to do this? TBH I haven't used |
In the codebase I'm working on, this is a recurring issue in our interactive view models (e.g. forms), requiring us to specify the closure input type explicitly to get the unwrapping overload. |
The discussion on slack that these changes arose out of was specifically about using a The main advantage of this change is the increased composability (wrapping/unwrapping, custom validation logic, input type) and progressive disclosure (start with a simple Void action, add state, then validation). |
Sounds good. This just needs a changelog entry. 👍 |
This could probably use some documentation with examples at some point, but for now the changelog is updated 👍 |
There are currently two options for using some property as state for an
Action
:Action.init(state:enabledIf:executing:)
(the most complicated);Void
input types, which are nice but sacrifice the ability to use a custom input type.This change rounds out the set of convenience initialisers for maximum flexibility:
Void
input type, without having to worry aboutenabledIf
;In order to unambiguously differentiate between the optional and non-optional variants in all cases, all the optional versions now use
unwrapping
as the parameter label for the state-property:I'm pretty happy with the
unwrapping
label, as it feels much more self-documenting, and should hopefully make this series of convenience initialisers easier to navigate.