Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unified event handling model #1873

Closed
DartBot opened this issue Feb 27, 2012 · 17 comments

Comments

@DartBot
Copy link

commented Feb 27, 2012

This issue was originally filed by @seaneagan


Dart needs a unified approach to handling asynchronous events including:

ui events (dart:html)
async operation completion (Future/Completer in dart:core)
Message sending and receiving (dart:isolates)

Strawman proposal at:

https://docs.google.com/document/d/17crOxOmR5AYwultXbNcfdbvD4ACBw5a9QbvO90FVgtk/edit

@iposva-google

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2012

cc @sigmundch.
cc @madsager.
cc @vsmenon.
cc @kasperl.
Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

@sigmundch

This comment has been minimized.

Copy link
Member

commented May 14, 2012

Added Isolates label.

@sethladd

This comment has been minimized.

Copy link
Member

commented Jun 12, 2012

Comments from a recent Code Lab:

"Contrast: WebSocketConnection "ws.onClosed=(int, String){}" syntax is very different from the WebSocket "ws.on.close.add((e){})" syntax. That's weird and surprising."

@nex3

This comment has been minimized.

Copy link
Member

commented Jul 25, 2012

The events in dart:io should also be unified in this way.

It would be good if whatever event model we ended up using supported multiple listeners per event. See also issue #4202.

@DartBot

This comment has been minimized.

Copy link
Author

commented Jul 26, 2012

This comment was originally written by kaisellgren@gmail.com


I just had a need for firing events in my classes to let other code know about "events". I also ended up writing an ObservableList class that utilizes my event library, but I'd really like to see native support for events Dart so that any class can just fire an event, etc. This could be implemented on a very base class or be a mixin called Observable that you just mix into whatever classes you want to.

@DartBot

This comment has been minimized.

Copy link
Author

commented Aug 10, 2012

This comment was originally written by rtimon...@gmail.com


http://ricardo.cc/2012/08/09/Its-time-for-a-native-EventEmitter.html

Explains nicely in what kind of mess you can end up with if you don't provide native language event support, or a canonical complete implementation in the base library.

@sigmundch

This comment has been minimized.

Copy link
Member

commented Sep 4, 2012

Added Library-Isolates label.

@sigmundch

This comment has been minimized.

Copy link
Member

commented Sep 4, 2012

Removed Isolates label.

@alan-knight

This comment has been minimized.

Copy link
Member

commented Sep 5, 2012

Changed the title to: "Unified event handling model".

@DartBot

This comment has been minimized.

Copy link
Author

commented Nov 2, 2012

This comment was originally written by prujo...@gmail.com


Since events, messages, async operations, network I/O, iterators, etc. can all be considered either terminating or non-terminating sequences of data, I propose that they all be unified under the same Observable model.

Examples:

Observable
  .fromList([1,2,3,4])
  .observe((next) => print('$next'), () => print('finished!'));

Observable
  .fromEvent(element.on.click)
  .observe((next) => print('you clicked me'), (){}, (e) => print('error!'));

// composability
Observable
  .fromEvent(element.on.click)
  .throttle(50) // only pass data if 50ms has passed
  .transform((event) => 'you clicked something')
  .observe((next) => print(next));

// combinators
Observable
  .merge([observer1, observer2, observer3])
  .observe((next) => print('merged data from list of observers: $next'));

Benefits:

  • unified
  • familiar
  • composable
  • extensible (combinators, parallel operators later...)

See http://pub.dartlang.org/packages/reactive as a reference project.

@dgrove

This comment has been minimized.

Copy link
Member

commented Jan 11, 2013

Added Library-Isolate label.

@dgrove

This comment has been minimized.

Copy link
Member

commented Jan 11, 2013

Removed Library-Isolates label.

@DartBot

This comment has been minimized.

Copy link
Author

commented Jan 31, 2013

This comment was originally written by jon...@gmail.com


I agree with this change request. I want my class to be able to alert other classes that some state has changed.

@DartBot

This comment has been minimized.

Copy link
Author

commented Jan 31, 2013

This comment was originally written by er...@codesmithtools.com


The new Stream API in Dart is going to be their unified eventing pattern. It still has some rough edges, but it is completely composable and gives all the desired features listed in this issue. I just created a package that makes exposing custom events as streams really easy. I am guessing that the Dart team will have similar functionality built into the SDK soon. Here is my pub package:

http://pub.dartlang.org/packages/event_stream

Here is an example of how to create a custom event:

class ClassWithEvents implements NotifyPropertyChanged {
  String _someProperty;

  final EventStream<PropertyChangedEventArgs> _onPropertyChangedEvent = new EventStream<PropertyChangedEventArgs>();
  Stream<PropertyChangedEventArgs> get onPropertyChanged => _onPropertyChangedEvent.stream;

  final EventStream _onClosedEvent = new EventStream();
  Stream get onClosed => _onClosedEvent.stream;

  String get someProperty => _someProperty;
  set someProperty(String value) {
    _onPropertyChangedEvent.signal(new PropertyChangedEventArgs('someProperty', value));
    _someProperty = value;
  }

  close() {
    _onClosedEvent.signal();
  }
}

main() {
  var c = new ClassWithEvents();
  c.onPropertyChanged.listen((PropertyChangedEventArgs<String> args) => print('changed: name=${args.propertyName} value=${args.value}'));
  c.onClosed.listen((_) => print('closed'));
  c.someProperty = "test";
  c.close();
}

@DartBot

This comment has been minimized.

Copy link
Author

commented Jan 31, 2013

This comment was originally written by jonapu...@gmail.com


Just checked out the event_stream package. It definitely helps simplify things.

@sethladd

This comment has been minimized.

Copy link
Member

commented Mar 5, 2013

Hi Florian, I think we can close this, yes?


cc @floitschG.
Removed Library-Isolate label.

@floitschG

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2013

Yes.


Added Fixed label.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.