Skip to content
This repository was archived by the owner on Sep 16, 2022. It is now read-only.

Dart2: (keypress) expects (Event e) not (KeyEvent e) #915

Closed
matanlurey opened this issue Feb 22, 2018 · 6 comments
Closed

Dart2: (keypress) expects (Event e) not (KeyEvent e) #915

matanlurey opened this issue Feb 22, 2018 · 6 comments

Comments

@matanlurey
Copy link
Contributor

This fails at the DDC with errors enabled:

https://github.com/dart-lang/angular/blob/f55fea736cb25040be640e75541acfbcd34e0329/_tests/test/core/change_detection/detect_host_changes_test.dart#L67

... I'm not sure why, yet. The temporary fix is to type this Event.

@leonsenft
Copy link
Contributor

@matanlurey What's the actual error?

@matanlurey
Copy link
Contributor Author

"Expected KeyEvent e got Event e"

@leonsenft
Copy link
Contributor

leonsenft commented Feb 23, 2018

So the issue arises from the following generated line:

_el_0.addEventListener('keypress', eventHandler1(_SomeDirective_0_5.handleKeyPress));

Element.addEventListener() expects a listener of type void Function(Event), which prevents a user from writing a handler with a specialized event type. Normally you'd write one that accepts Event, then cast (if you're certain of the type) or promote the event. For example, if you're listening to the click event, you know the event type will be ClickEvent.

I tried to do this work for the user if they specified a type with the following code:

https://github.com/dart-lang/angular/blob/f55fea736cb25040be640e75541acfbcd34e0329/angular/lib/src/core/linker/app_view.dart#L629-L634

My thinking is that when this function is invoked directly as a parameter of EventTarget.addEventListener(), the parameter type requires E to be Event, thus F is restricted to a type that's assignable to Event. We then cast this Event to F in the returned closure which itself has type void Function(Event).

Is there a mistake in my reasoning? Is inference not intended to be capable of handling this? I looked at the output of DDC and found this.

this[_el_0][$addEventListener](
  'keypress',
  this.eventHandler1(
    html.Event,
    html.Event,
    EventTovoid()._check(dart.dload(this[_SomeDirective_0_5], 'handleKeyPress')),
  ),
);

By the looks of the parameters (which I assume are the generic type arguments), inference has typed eventHandler1<E, F extends E> as eventHandler<Event, Event>. This is why we see the error cast fail from (KeyEvent) => void to (Event) => void, since the parameter isn't expecting a void Function(KeyEvent) as it should, but rather a void Function(Event).

So is this a DDC bug, or am I misunderstanding the type system? @vsmenon

@vsmenon
Copy link
Contributor

vsmenon commented Feb 23, 2018

@leonsenft The inference will only work if we know the static type of _SomeDirective_0_5.handleKeyPress. The dload in the generated code means that it doesn't. What's the static type of _SomeDirective_0_5?

@leonsenft
Copy link
Contributor

Of course! The field has type dynamic. I'm wondering why this is the case, since a directive's type should be well known (you have to provide it in the metadata directly). I'll double check if all directives have dynamic types, or if this is just a special case since the directive is being provided by the component hosting it.

Thanks!

@matanlurey
Copy link
Contributor Author

I am going to assume this is a bug (?) in the compiler, and assign to you for now.

alorenzen pushed a commit that referenced this issue Feb 23, 2018
…ease(s).

Filed/updated a number of cleanup/refactor bugs while doing this:
* #908
* #916
* #915
* #844
* #914
* dart-lang/sdk#32284

Closes #913.

PiperOrigin-RevId: 186683475
alorenzen pushed a commit that referenced this issue Feb 24, 2018
…ease(s).

Filed/updated a number of cleanup/refactor bugs while doing this:
* #908
* #916
* #915
* #844
* #914
* dart-lang/sdk#32284

Closes #913.

PiperOrigin-RevId: 186683475
alorenzen pushed a commit that referenced this issue Feb 24, 2018
alorenzen pushed a commit that referenced this issue Feb 24, 2018
…ease(s).

Filed/updated a number of cleanup/refactor bugs while doing this:
* #908
* #916
* #915
* #844
* #914
* dart-lang/sdk#32284

Closes #913.

PiperOrigin-RevId: 186683475
alorenzen pushed a commit that referenced this issue Feb 24, 2018
alorenzen pushed a commit that referenced this issue Feb 24, 2018
…ease(s).

Filed/updated a number of cleanup/refactor bugs while doing this:
* #908
* #916
* #915
* #844
* #914
* dart-lang/sdk#32284

Closes #913.

PiperOrigin-RevId: 186683475
alorenzen pushed a commit that referenced this issue Feb 24, 2018
matanlurey added a commit that referenced this issue Feb 25, 2018
…ease(s).

Filed/updated a number of cleanup/refactor bugs while doing this:
* #908
* #916
* #915
* #844
* #914
* dart-lang/sdk#32284

Closes #913.

PiperOrigin-RevId: 186683475
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants