Interstellar 2.0

[JensRavens]

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). Should flatMap be map? #15
• Support Signal<Void>. This might require to get rid of sending the initial signal value on subscribe. What's the right way to have a signal take no input #13
• Add a way to unsubscribe from a signal using a subscribtion-object. No Unsubscribing from Signals #12

[anaglik]

Hi
Congratulations on the library. Interstellar looks great! Could you say more than less when do you plan to release v. 2.0 ?

[JensRavens]

Thank you @anaglik,
currently I'm thinking about putting these features into v1.4 and then do the deprecation of Signal<T> in 2.0, just to have a smoother upgrade experience. This also involves the discussion about #27.

[anaglik]

Great, it sounds good,
I am mostly interested in #12 but all chances are very welcome.

[ashfurrow]

@JensRavens Do you have any ideas or specifics on how one could contribute to v2? I see there's a branch and I'm wondering what next steps the community could help you take – we're happy to help with such a useful library!

[JensRavens]

Hey Ash,

nice to see you here! I've been pretty much heads down in ruby over the last few weeks, but I'll have some more time for Swift now.

Currently I hope to get some feedback over the design decisions of v2. Dropping Signal in favor of Observable is a needed, but rather drastically.

Also I'm really unsure how to handle Observables on subscribe and if they should keep notifying the observer on subscribe. This is helpful in most circumstances but can possible introduce unintentional memory leaks. Making that optional could possible make the whole thing pretty bloated (and the main advantage of this library is it's small size and easy usage). Same for unsubscribing.

So mostly I'm looking for a wishlist of features from the library's users how Interstellar should work in the next version.

[Erkened]

@JensRavens Would you consider adding UI Bindings in a separate, dependent project (InterstellarUI for example) so that those among us who'd like to subscribe to events from UITextFields, UIButtons etc. are able to do so?

[JensRavens]

Yep. My first reflex was to add it as a cocoapods subspec. But as I'm planning to use Interstellar also on Server Side Linux apps, it might be best to move it out of the core (there's already a divide between Interstellar Core and the Warpdrive extensions).

[ashfurrow]

@JensRavens Cool, I'll take a look at the v2 branch and provide some feedback – does here work? For code-level feedback, a PR from that branch into master makes sense, but it might be early for that. Do you consider the v2 branch at all ready for testing in production?

For UI bindings, I think moving to another repo makes sense. RxSwift has RxCocoa as a second podspec in the repo, and it works okay for them (but I think it's a little messy). Totally a personal preference though.

[JensRavens]

@ashfurrow It's should be pretty stable, but expect some changes during the next weeks (making the subscribers subclasses of an abstract base class is not what I would like to do in the long term, but that shouldn't affect the public api).

For the UI-bindings: I've already came up with a nice name: Holodeck (which completes Interstellar and Warpdrive).

[Erkened]

@JensRavens Holodeck is a cool name, I like it :)
Keep us posted when you create this project. I have a couple of UI bindings I'll submit then. And I'll try to have a look at the v2 branch when I get some free time.

[robertjpayne]

@JensRavens care to elaborate a bit more on:

Also I'm really unsure how to handle Observables on subscribe and if they should keep notifying the observer on subscribe

Love the simplicity of Interstellar over RAC/RxSwift.

[anaglik]

@JensRavens Could you comment on following suggestions/questions ?

1. What do you think about adding "Unsubscribable" protocol with unsubscribe method and then make ObserverToken implement it ? It may simplify storing tokens in Array (e.g [Unsubscribable]). Currently I don't have "nice" solution for that.
2. You mentioned that you are thinking about depreciation of Signal. Are there any plans to add similar set of functions from Signal to Observable ? Currently I am migrating to v2. and noticed lack of e.g merge or few versions of flatMap.

[JensRavens]

@anaglik
For the token part:
ObserverToken currently is a class and the only class that can be returned by the subscribe method. What would be the advantage of having it as a protocol? [ObserverToken<String>] looks fine to me.

Observables by now should support everything that was supported by signal - and more (merging is currently discussed in #39). The old version of flatmap was never a real flatmap, therefore it has been renamed to then to show the similarities to javascript's promises. It's not directly implemented on observable, but as an extension of Observable<Result<T>>.

[anaglik]

@JensRavens

1. In my case I would like to store ObserverTokens of different types in one array (something like [ObserverTokens<Any>]). I could't find elegant way to do that without protocol.
2. You are absolutely right about old version of flatMap. Nonetheless, I couldn't find good replacement for flatMap<U>(f: (T, (Result<U>->Void))->Void) -> Signal<U> but I will definitely look at then.

Thanks for quick reply!

[ashfurrow]

I've had this situation too, where I want an array of indiscriminate observer tokens to unsubscribe from later.

[JensRavens]

Here's a short update: v2 is now fully tested and documented and I think it's ready for production (I think @ashfurrow is already using it). If there are no objections I'll release it just in time on friday for my Interstellar workshop in Zürich.

Here's a the list of awesome new stuff:

• Signal<T> was split up into Observable<T> which can contain (but doesn't have to) a Result<T>. Observable<Result<T>> get's some superpowers due to protocol extensions which replaces the flatmap function (now called then) (Should flatMap be map? #15).
• There's a new way to manually unsubscribe from an Observable<T> (More complex unsubscription in v2 #40).
• Warpdrive has been ported to Linux thanks to the release of the Dispatch library.
• BYOR™-Technology (Bring Your Own Resulttype) allows you to use Result<T>s from other libraries or your own code as long as they conform to the new ResultType protocol.
• Observable<T> does have options to configure its updating behaviour:
  • .NoInitialValue does not save the current value and therefore allows Void-values (What's the right way to have a signal take no input #13)
  • .Once will call subscribers exactly once and then automatically unsubscribe them (effectively making it a Promise<T> and fixing a lot of retain cycles)

[anaglik]

@JensRavens When do you plan to move v2 into master?

[JensRavens]

Finally published v2 today! 🎉