Simple and lightweight Functional Reactive Coding in Swift for the rest of us

This issue is collecting all feature requests that require a breaking change to the public API of this library. Please discuss features in the corresponding issues (linked in the description):

• Split up Signal<T> and Result<T>. This also adds support for non-failing signals and fixes the naming of some methods (flatMap becomes then, so flatMap is free to do a real flat-mapping). #15
• Support Signal<Void>. This might require to get rid of sending the initial signal value on subscribe. #13
• Add a way to unsubscribe from a signal using a subscribtion-object. #12

flatMap should have a function signature of Signal a -> (a -> Signal b) -> Signal b, but it is currently Signal a -> (a -> b) -> Signal b which is a functor mapping, not flatMapping.

This pull requests migrates the project to be compatible with Swift 4. Though the codebase is now compatible to be marked with the Swift 4 build setting, the compiler flag is set to Swift 3.2 for now so that backwards compatibility may be maintained with Xcode 8.3

As Xcode 9 has the nice new feature to mirror the xcodeproj directory structure to that of the on-disk structure, the directory structure has changed a bit (this was also necessary as Xcode 9 saw dead file references when opening the existing project).

Currently, the module structure mimics the conceptual structure of the podspec:

Source code for Interstellar lives in Sources/Interstellar and since Warpdrive is really an extension for Interstellar, the code lives at Sources/Interstellar/Warpdrive

There is no mechanism to unsubscribe from signals. Thus over the lifetime of the application callbacks to subscription blocks referencing deallocated objects will be sent. The amount of unnecessary callbacks will steadily increase while the application is used. This will finally lead to performance issues, especially in the case when Signals are used to update UI elements in view controllers.

^=~~Drops support for Swift 3.2/3.3~~

Additionally updates the Package.swift manifest to version 4.0 of swift-tools

Hey @JensRavens

What do you think about making this change now?

If you're amenable, could we publish a new version? I imagine it may need to be a 3.0.0 as it will break backwards compatibility with Xcode 8.

This is a cosmetic change that disambiguates the Error case of the Result enum from the error value. Success and failure are better antonyms than success and error.

(Unit tests & README also updated)

This is a first-pass, happy to amend based on any feedback. Changed the existing tests to support the new behaviour. If this looks good to you, I'll update the documentation, too.

Fixes #40.

Thanks for publishing this great library!

I really loved it, but I quickly faced a problem (for me at least). I am trying to implement a "service-oriented architecture", which is basically just a bunch of services that are instantiated then bound together through observables to make the whole thing "tick". They should not know about each other, except for the Observable being passed in from the binding object. Doing this makes it impossible to clean up the observer, since unsubscribe requires access to the Observable.

Pondering on this a bit, I thought of this, and would like to hear your thoughts about it. It could use a bit of type-erasure, and other tune ups, but was wondering if you're interested in this direction:

final class Subscription<T> {

    private weak var observable: Observable<T>?
    private let token: ObserverToken

    init(observable: Observable<T>, token: ObserverToken) {
        self.observable = observable
        self.token = token
    }

    deinit {
        observable?.unsubscribe(token)
    }
}

extension ObserverToken {

    func subscription<T>(from observable: Observable<T>) -> Subscription<T> {
        return Subscription(observable: observable, token: self)
    }
}

The current subscription/unsubscription mechanism in v2 relies on having both the Observable and the ObserverToken, which complicates things slightly. For use in a table view cell, for example, we need to unsubscribe during prepareForReuse(), and afterward set the observable and the token to be nil. This requires some awkwardness, either with:

if let observerToken = observerToken, observable = observable {
    observable.unsubscribe(observerToken)
}
self.observerToken = nil
self.observable = nil

Or something with tuples:

var subscription: (ObserverToken, Observable<Whatever>)?

...

if let subscription = subscription {
    subscription.1.unsubscrive(subscription.0)
}
subscription = nil

Neither is particularly awesome. I'd like to consider using a more complex ObserverToken that has a weak or unowned reference to the observable it's bound to, so we don't need to hang on to both observable and observer token. Any thoughts? Happy to send a PR if you like the idea.

Hey, I was curious on what the intended/expected minimum OS X target is.

The README says the requirements are iOS 7.0+ / Mac OS X 10.9+ / Ubuntu 14.10 but when I use Carthage fetch and install Interstellar it results in a framework with minimum deployment target of OS X 10.11

I tried to change the Interstellar.xcodeproj to set a deployment target of 10.10, it builds fine... but I'm wondering whether its just an issue with the .xcodeproj and it should work fine or if the documentation is out of date. Any guidance would be helpful, thanks.

First of all - i am loving the simplicity of interstellar! ty for putting it online.

In my projects i added an extension for Signals. I often use this in case of 1 Signal with a Tuple of values.

Maybe you see some use case for this.

extension Signal {
  func update(f: T? -> T){
    // internally:  self.update(f(self.value?.value))
    self.update(f(self.peek()))
  }
}

Hi, I'm huge fan of the project. It is really well done and using it is a breeze.

Today, Apple released Xcode 10.2 with Swift 5 and now we have Result type built into the language. How do you think it influences the project? Should it replace Interstellar's Result type or would you like to keep them both by conforming to ResultType protocol?

I don't think it's possible to "silently" update an observable's value. Such a use-case kinda popped-up for me today...

Do you think it makes sense to add it to Interstellar's API?

I am wrapping URLSessionDataTask instances in Observable instances via code similar to that listed below (I have removed the use of generics and replaced them with concrete types to, hopefully, make the example more clear).

// Where the conversion of the datatask to the signal occurs.
func toObservable(url: URL, dataTaskToConvert: (URL, (Result<Data>) -> Void)) -> Observable<Result<Data>> {

    let signal = Observable<Result<Data>>()

    let value: URLSessionDataTask? = dataTaskToConvert(url) { result in
        signal.update(result)
    }
    return signal
}

// Example API for consumer to make network requests without ugly callbacks.
func fetch(url: URL) ->  Observable<Result<Data>> {
    return toObservable(url: url, dataTaskToConvert: fetch)
}

// DataTask response handling is transformed to use an API with Interstellar's Result type like so:
func fetch(url: URL, completion: @escaping (Result<Data>) -> Void) -> URLSessionDataTask {
    let task = sharedUrlSession.dataTask(with: url) { data, response, error in
        if let data = data {
            completion(Result.success(data))
            return
        }

        if let error = error {
            completion(Result.error(error))
            return
        }

        let sdkError = SDKError.invalidHTTPResponse(response: response)
        completion(Result.error(sdkError))
    }

    task.resume()
    return task
}

Unfortunately, I haven't figured out a way to expose the underlying URLSessionDataTask to the client to cancel the request in a clean fashion. I think ideally, there would be somesort of method on the observable to stop the signal. My workaround currently is to return tuple of (URLSessionDataTask, Observable<Result<Data>>) rather than just the Observable so that the client can take advantage of the Observable API provided by Interstellar while also having the ability to cancel the request. However, I find the tuple API ugly to use, as client code would look like the following:

// must access the tuple element at index `1` (or named parameter)
fetch(url: someURL).1.then { data in
 // do stuff with data
}.error { 
    // handle error.
}

I am relatively new to the reactive style of programming, so I am currently unable to figure out what a good strategy for disposing the observable and it's underlying might be. I looked into the section on Disposables in the README for ReactiveKit, but I'm not sure how the same concept would integrate with Interstellar.

Is there a way you might recommend cancelling the URLSessionDataTask? I would be very happy to work on a pull request (with a small bit of guidance to kick me off in the right direction) if you think this feature might be useful.

Debounce seems to deliver the first skipped call to update, instead of the last call to update.

I think this happens because the skipped calls to update are scheduled to be evaluated again 1) without previous skipped calls being cancelled, and 2) are scheduled to be evaluated again very close to each other temporally. Observable.delay uses DispatchQueue.asyncAfter which isn't very precise, so whichever one fires first (usually the first one scheduled in my search-as-you-type use case) will set the new lastCalled value and ignore the others.

// skip result if there was a newer result
if currentTime.compare(lastCalled!) == .orderedDescending {
    let s = Observable<T>()
    s.delay(seconds - timeSinceLastCall!).subscribe(updateIfNeeded(observable))
    s.update(value)
}

In function subscribe

    public func subscribe(f: Result<T> -> Void) -> Signal<T> {
        if let value = value {
            f(value)
        }
        mutex.lock {
            callbacks.append(f)
        }
        return self
    }

https://github.com/JensRavens/Interstellar/blob/master/Sources/Signal.swift#L145-L153

it seems to me, there's a potential data race: access to value should be protected by the mutex.

Proposed solution:

    public func subscribe(f: Result<T> -> Void) -> Signal<T> {
        var v: Result<T>?
        mutex.lock {
            v = self.value
            callbacks.append(f)
        }
        if let value = v {
            f(value)
        }
        return self
    }

Still, this is not a reliable solution: it's not guaranteed, that function f will be invoked before any other mapping function which is invoked due to an update. These kind of issues can be solved only with introducing an "execution context" (for example a dispatch queue) which defines where the mapping function will be executed:

    public func subscribe(ec: ExecutionContext = <default>, f: Result<T> -> Void) -> Signal<T> {
        mutex.lock {
            if let value = self.value {
                ec.execAsync { f(value) }
            }
            callbacks.append(f)
        }
        return self
    }