ReactiveCocoa/ReactiveCocoa — pull request #986 by jspahrsummers (2013-12-04 06:49:00+00:00)
Title: [WIP] Replace channels with "validated bindings"

**:warning: NOT READY TO MERGE :warning:**

See #960 and #951.

This horribly documented and horribly named class is kind of a throwback to ["facts and rumors"](https://github.com/ReactiveCocoa/ReactiveCocoa/pull/695), because it puts stronger emphasis on the idea of one side of the binding being more authoritative than the other.

Basically, your [view] model always has _the_ canonical data. It can provide that data—or a transformed version of it—for the view to display directly. However, when the user updates the view, the [view] model should be offered a chance to validate and/or transform the user-entered data. If validation fails, the view should revert to the last "canonical" version.

To [communicate errors](https://github.com/ReactiveCocoa/ReactiveCocoa/issues/951), like validation failures, I went with a signal generator. This will make the UI bindings pretty weird (because the validated/transformed value may not arrive in time for synchronous methods, like `-textField:shouldChangeCharactersInRange:replacementString:`), but allows the class to support non-UI use cases as well.

My hope is that maybe replacing `RACChannel` with something that's less "two dumb pipes, side-by-side" and more "a two-way binding with validation logic on one side" will make it less confusing overall.

Thoughts?

**To do:**

- [ ] Add a transactional signal generator (to merge the results of `validator`)?
- [ ] Implement and test `RACValidatedBinding`.
- [ ] Add a subclass that uses KVO/KVC/KVV for its work.
- [ ] Test that the KVO variant doesn't result in an infinite loop.
- [ ] Remove `RACChannel` classes.
- [ ] Deprecate `RACChannel` extensions for AppKit/UIKit, replace them with validated bindings.