Single/ Maybe / Completable types


New to dart but coming from Kotlin/Java world, I miss the Single/Maybe and Completable type. I found them really useless at least to express what you really want to return Observable can be all of those types and you can’t really know what to expect if you didn’t write the code yourself ^^ (and even in that case sometimes :D)
By having those types it will make more clear what you’ll have as a result. I might be able to work on this and make a PR if it’s something you might consider 🙂

3 thoughts on “Single/ Maybe / Completable types

  1. Hey hey 🙂 Yah, I also like those types provided by RxJava! It’s something I’ve thought of before, but I think it’s interesting to think about these types, what Dart offers, and which ones really add value to the ecosystem.

    For example, I wonder if we need Single? Dart has the Future class and support baked-in at the language level. It’s not identical, but the intention is the same: Represent an async call that returns a single value or error. The Stream standard lib & RxDart also return Future in several cases: .toList, .first, .last, etc. Therefore, I think implementing a new Single type would be a bit confusing, since it would be another way to represent the same thing without the language-level support and compatibility with other libraries.

    In addition, I could see Completable being a class that simply implements Future<void> (since it’s a one-off call with no return value). Perhaps Completable is more descriptive than Future<void> once you’re used to it, but I think Future<void> is also a clear indication of an async value that will complete with no useful value and doesn’t introduce a new abstractions to understand.

    I think Maybe is where it gets interesting. This is something unique that Dart / RxDart don’t currently offer, and might be worth taking a look at. It’s kind of a union type of Future<void | T>. Perhaps it could be implemented as a Maybe<T> which extends Future?

    Anyhow, these are my thoughts on the matter! What do you think? Convinced by these arguments? Total Hogwash? Got ideas of how to implement Maybe in a solid way?

  2. Sure thing — If ya haven’t worked with Dart Future much, I’d definitely consider playing with it a bit more and seeing whatcha think. Dart’s Future is used much more broadly for Flutter development than Java’s Future is for Android development (I haven’t done as much Java server-side). This includes Widgets like FutureBuilder and many APIs that return Futures, such as Navigator.push. Furthermore, you get language-level support for working with Futures using async and inside async* functions.

    In addition, you often need to convert between Single and Observable in RxJava as well. For example, operators like toList() return a Single<List<T>> whereas Dart Streams / RxDart toList() returns a Future<List<T>>. You may also need to convert a Single to an Observable via mySingle.toObservable(), for example if you want to concat the Single to the end of another observable. In Dart, this is myFuture.asStream().

    I guess I feel like if we introduce Single it would be a poor imitation of what Future has to offer, but please feel free to play around and see if ya come up with something interesting! These are just my thoughts.

  3. Future is nice replacement indeed, at least until you need to chain it with observables, e.g. .andThen() from RxJava. How do you suggest to do so?