Revisit Action state-property convenience initialisers

[sharplet]

There are currently two options for using some property as state for an Action:

• Use the designated initialiser Action.init(state:enabledIf:executing:) (the most complicated);
• Use the various convenience initialisers defined for 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:

• You can now use a state-property with a non-Void input type, without having to worry about enabledIf;
• You can use a conditionally-unwrapped optional state-property in the same way.

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:

let model: MutableProperty<MyModel?>

let share = Action<UIViewController, Never, AnyError>(unwrapping: model) { model, viewController in
  return viewController.share(model)
}

// later...

button.reactive.pressed = CocoaAction(viewModel.share) { [unowned self] _ in self }

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.

• Updated CHANGELOG.md.

[mdiep]

You can now use a state-property with a non-Void input type

Do you find yourself actually wanting to do this?

TBH I haven't used Action much (although I did use RACCommand). I'd envisioned that state would actually be the better model, since it's fully reactive. But I'm curious about how you're using it and would love to hear more.

[andersio]

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.

[sharplet]

You can now use a state-property with a non-Void input type

Do you find yourself actually wanting to do this?

The discussion on slack that these changes arose out of was specifically about using a UIViewController as the input to an action: I've experienced lots of cases where an asynchronous operation involves presenting some kind of modal UI, and it's a pretty common pattern in UIKit.

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).

[mdiep]

Sounds good. This just needs a changelog entry. 👍

[sharplet]

This could probably use some documentation with examples at some point, but for now the changelog is updated 👍