josephduffy / partial Goto Github PK

Each of the test files are large, causing them to be hard to read, refactor, and sometimes slow down Xcode.

Some sort of code generation tool could be used to improve the creation/updating of these files. I have tried Sourcery, but it does not seem to help the issues (it seems to mainly work on types, rather than generate files with large amounts of repetition with minor differences).

Using functions to test specific cases (such as all cases for when a value is not set) is feasible, but can make tracking down failing tests more cumbersome.

Quick/Nimble add overhead to testing (both as a developer checking out and overhead when running).

I personally don't use them on other projects and would like to remove them from this.

Is your feature request related to a problem? Please describe.

Yet to actually use the library, but reading through the documentation for PartialBuilder in the "Building complex types" section it occurred to me that it should be possible to improve this:

struct Root {
    let size1: CGSize
    let size2: CGSize
}

let rootBuilder = PartialBuilder<Root>()
let size1Builder = PartialBuilder<CGSize>()
let size2Builder = PartialBuilder<CGSize>()

let size1Subscription = size1Builder.subscribeToAllChanges { _, size1Builder in
    try? rootBuilder.setValue(size1Builder, for: \.size1)
}
let size2Subscription = size2Builder.subscribeToAllChanges { _, size2Builder in
    try? rootBuilder.setValue(size2Builder, for: \.size2)
}

Describe the solution you'd like

It should be possible to build some infrastructure to be able to write something like this instead:

struct Root {
    let size1: CGSize
    let size2: CGSize
}

let rootBuilder = PartialBuilder<Root>()
let size1Builder = rootBuilder.builder(for: \.size1)
let size2Builder = rootBuilder.builder(for: \.size2)

Internally, the builder(for:) method would wire up the subscription for you.

Potential downside is that you can't 'unsubscribe' from changes, but I'm not sure how often that would be an issue? I'm guessing that most Partial* values just get disposed once the real value is built anyway.

A couple of options for this:

1. Have a SubPartialBuilder (terrible class name, sorry) with an extra method for unsubscribing/etc if that's an issue? Eg:

// assuming that `builder(for:)` returns a `SubPartialBuilder`...
size2Builder.cancelSubscription() // or `.detach()` ?

Alternately to avoid needing SubPartialBuilder, this method could get added to the PartialBuilder interface and simply does nothing for top-level builders. Not sure if I like that.

2. PartialBuilder keeps track of the subscriptions it creates via builder(for:) internally, and provides a method to unwatch a given keypath. Eg:

rootBuilder:cancelSubscriptions(for: \.size2)

The upside is, you don't need any additional classes or protocols. The downside is, you can't cancel the specific sub-PartialBuilder.

On balance, I prefer option 1. And thinking about it, I'd lean towards adding detach() to PartialBuilder, rather than adding a SubPartialBuilder subclass. But I could see arguments for both sides.

Describe alternatives you've considered

The original suggestion works, just requires more work from developers, increasing the possiblity of missing steps.