search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.12k stars 1.57k forks source link

Proposal: Adopt Observable spec for streams in Dart 3 #35500

Open lukepighetti opened 5 years ago

lukepighetti commented 5 years ago

Proposal: Adopt the Observable spec for streams in Dart, remove the old streams spec.

1. Dart's streams forces RxDart to not be ReactiveX

RxDart is a unique ReactiveX package because they have decided to defer to the Dart stream spec even though it forces them to deviate from the Observable spec.

https://github.com/ReactiveX/rxdart/issues/95 https://github.com/ReactiveX/rxdart/issues/89 https://github.com/ReactiveX/rxdart/issues/186

2. BLoC has made Observables a core dependency for Flutter projects

Due to the weight of Flutter recommending BLoC and BehaviorSubjects and ValueObservables, rxdart is now standard fare for people using BLoC, which is now standard fare for state management in Flutter.

https://github.com/filiph/state_experiments/blob/master/shared/lib/src/bloc_complex/cart/cart_bloc.dart

3. Flutter is the driving force for Dart

Flutter is now the driving force for Dart. The tail wags the dog. See Stack Overflow insights https://insights.stackoverflow.com/trends?tags=flutter%2Cdart

Proposal

I propose that Dart replace the stream spec with the observable spec and allow RxDart to provide pipes to expand the capabilities of native Dart observables. This will allow ReactiveX developers to more easily switch to Dart, and provide a huge value add as the only language (?) that has native Observables. It will further cement Dart as being a modern object oriented language that leverages modern event based / reactive architectures which supports Flutter's mission.

natebosch commented 5 years ago

What advantages does the Observable spec have over Stream? Is it primarily because it's what people already know?

vsmenon commented 5 years ago

Removing / replacing the current Streams API is almost certainly too big a breaking change for both Dart and Flutter at this point.

Is there a reason the Rx Observable spec cannot be implemented faithfully as a library for those who want it?

zoechi commented 5 years ago

Is there a reason the Rx Observable spec cannot be implemented faithfully as a library for those who want it?

It's even more cumbersome to have 2 different implementations for basically the same thing than having one implementation that doesn't fully match everyones expectation. https://pub.dartlang.org/packages/rxdart bridges the gap as good as possible.

I wouldn't see this as a problem, and the more of the discussed features get added to Dart (extention methods, non-nullable types, union types, ... the more similar to other implementations rxdart will become anyway.

lukepighetti commented 5 years ago

When I made this proposal I did so recognizing that the chance of it being accepted was extremely low but I did feel it was appropriate to put it on the radar. Cheers. :)

Standaa commented 5 years ago

What advantages does the Observable spec have over Stream? Is it primarily because it's what people already know?

I am personally coming from RxJs, and currently porting some Angular typescript code to Angular Dart. I have lost a couple hours today, just going through the API, which looks closer to pre RxJS5. I find it extremely frustrating that I have to look for each class method to understand how to achieve something. There are only a handful of documents, the examples provided don't showcase error handling, and as a result I have to deep dive into an API which I could have been familiar with.

Developers will argue that there is just a learning curve, but it all adds up. You have to learn a new framework, a new language, new patterns and even a new version of the library you already know ?

Make it easy for people to switch. Make it easy for them to port their libraries and code. That's the only way Dart can become a vibrant ecosystem.