Skip to content
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

Merge thoughtbot/Bindings as a subtree of CombineViewModel #8

Merged
merged 28 commits into from
Aug 24, 2020

Conversation

sharplet
Copy link
Contributor

@sharplet sharplet commented Aug 16, 2020

I propose we merge https://github.com/thoughtbot/Bindings directly into CombineViewModel, merging their histories. The benefits to reusing the BindingOwner protocol should be clearly illustrated in #9.

Why combine the histories of these two repositories instead of simply depending on Bindings?

  1. In my mind the main benefit will be in maintenance. It's strictly simpler to maintain a single project instead of multiple.
  2. I think CombineViewModel is more likely to succeed as a holistic approach to implementing MVVM in UIKit. That holistic vision makes the role of Bindings itself much clearer in my mind: it's a pattern for triggering updates to your UI based on the output of reactive streams.
  3. A clearer vision will hopefully help to increase adoption — i.e., if it's easier to understand the purpose of the library and how to use it, and easier to get started, people are more likely to try!

You may be wondering, "What about SwiftUI?" I feel pretty confident it will be the future of app development on Apple platforms, but it's not there yet. However, one of my goals in building this package atop Combine's ObservableObject protocol is that view models you develop with CombineViewModel should slot directly into SwiftUI apps, potentially without even modifying the view model code. I'd love for this package to become a bridge to introducing SwiftUI in existing UIKit and AppKit codebases, be leveraging the same tools at the data and controller (a.k.a. view model) layers.


sharplet and others added 21 commits September 1, 2019 17:24
The standard library includes this curious operator declaration:

    infix operator ~> : DefaultPrecedence

However there are no protocols are free functions that provide any
definition or hint at its intended semantics.

In light of this, it makes a lot of sense for both operators to exist in
the same precedence group. DefaultPrecedence is at a slightly higher
precedence than BindingPrecedence was, now binding more tightly than
the ternary operator. This feels reasonable, as now it's possible to,
e.g., switch between two different binding statements in a ternary
expression.
`Cancellable.store(in:)` is overloaded for two kinds of collection:
either any `RangeReplaceableCollection`, or `Set`. Given that `Set` is
more specific, prefer it over `Array`.
Extracts a `_getBox()` helper method that initialises an empty
`Subscriptions` box if necessary and then returns a reference. This is
used to streamline the implementation of _read/set/_modify accessors.
These are also marked inlinable.
Use _read/set/_modify for associated-object-based subscriptions
@sharplet sharplet marked this pull request as ready for review August 16, 2020 22:13
Bindings provides the `BindingOwner` protocol, which implicitly extends
all conformers with a `Subscriptions` collection. This makes it
possible, in a generic context, to scope a given binding to the lifetime
of the object that owns the binding.

By inheriting `ViewModelObserver` from `BindingOwner`, all observers
gain the benefit of this automatic collection of subscriptions. As a
side effect, we can update all our examples to remove the explicit
declaration of a `subscriptions` property.
@sharplet sharplet merged commit 19fd07a into main Aug 24, 2020
@sharplet sharplet deleted the merge-bindings branch August 24, 2020 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant