Skip to content

fix(fromEvent): improve typings for JQueryStyleEventEmitter #5584

New issue

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

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

Already on GitHub? # to your account

Closed
wants to merge 0 commits into from
Closed

fix(fromEvent): improve typings for JQueryStyleEventEmitter #5584

wants to merge 0 commits into from

Conversation

evertbouw
Copy link
Contributor

Description:

The handler in JQueryStyleEventEmitter is typed as a Function, meaning it takes no arguments. Overwriting this requires a pretty awkward cast.

Related issue (if exists):

#4496

@@ -20,8 +20,8 @@ export interface NodeCompatibleEventEmitter {
}

export interface JQueryStyleEventEmitter {
on: (eventName: string, handler: Function) => void;
off: (eventName: string, handler: Function) => void;
on: (eventName: string, handler: NodeEventHandler) => void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NodeEventHandler appears to be from @typings/node. @cartant, am I wrong in saying that this would make us dependent on @typings/node?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since that was already used in this file I thought I'd use it again. The important part is that it's (...args: any[]) => void, could create a local type for that.

Copy link
Collaborator

@cartant cartant Jul 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... this would make us dependent on @typings/node?

Nah, this looks okay. The NodeEventHandler is declared in this file. I suppose this is okay, but I thought jQuery events used a single object parameter - more like the DOM event handlers - rather than multiple parameters. It has been some time since I've used jQuery, so IDK.

Whatever the situation, Function is wrong, here, as it's pretty much totally useless, these days, being declared like this:

interface Function {
    /**
     * Returns the name of the function. Function names are read-only and can not be changed.
     */
    readonly name: string;
}

@benlesh
Copy link
Member

benlesh commented Sep 1, 2020

I'd feel a whole lot better about this change with some sort of dtslint tests or something.

@evertbouw
Copy link
Contributor Author

I've not written those before, does this work?

@cartant
Copy link
Collaborator

cartant commented Sep 12, 2020

@evertbouw Regarding the dtslint tests, once #5724 is merged, you'll find a spec-dtslint/observables/fromEvent-spec.ts file. It contains the type tests. Note that the code is not executed; the dtslint expectations - $ExpectType ... - are performed using a TSLint rule. To run the tests, use the npm run dtslint command.

The PR with the tests has been merged. If you rebase your PR and run them, we'll see where we're at, I suppose.

@cartant
Copy link
Collaborator

cartant commented Sep 12, 2020

As I mentioned here, I think the jQuery handler type could/should be changed to better reflect the actual jQuery typings - i.e. be more like EventHandlerBase, but without the this/context.

Relevant types: EventHandlerBase and on.

However, this is jQuery, so it's not something about which I'm especially passionate.


I've tweaked the jQuery types - in #5726 - in the dtslint test and I've commented out the jQuery test - as it fails with the more accurate jQuery types. After it's merged and after you rebase, you should be able to uncomment it and it should pass.

@evertbouw
Copy link
Contributor Author

Rebased and uncommented the test

@cartant
Copy link
Collaborator

cartant commented Mar 6, 2021

It seems these changes were somehow (inadvertently?) included in this PR: #5783

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants