-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
ref(types): Avoid some any
type casting around wrap
code
#14463
Conversation
size-limit report 📦
|
❌ 1 Tests Failed:
View the full list of 1 ❄️ flaky tests
To view more test analytics, go to the Test Analytics Dashboard |
@@ -31,6 +31,21 @@ export function ignoreNextOnError(): void { | |||
}); | |||
} | |||
|
|||
// eslint-disable-next-line @typescript-eslint/ban-types | |||
type WrappableFunction = Function; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an alias to avoid having ban-types eslint disable everywhere
// eslint-disable-next-line @typescript-eslint/ban-types | ||
type WrappableFunction = Function; | ||
|
||
export function wrap<T extends WrappableFunction>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ensures we have proper type inferrence, so e.g.
const a = wrap(1);
// a is correctly inferred as `1` now
|
||
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, no-prototype-builtins | ||
if (!proto || !proto.hasOwnProperty || !proto.hasOwnProperty('addEventListener')) { | ||
if (!proto || Object.prototype.hasOwnProperty.call(proto, 'addEventListener')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a reason not to use Object.prototype.hasOwnProperty
here, but use the prototype method itself? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the difference between the two? shouldn't this be equal since we pass proto
as the this
arg? I guess the only apparent reason to me would be saving a couple of bytes. But if using Object.prototype.hasOwnProperty
is more correct, we should go for it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there is https://eslint.org/docs/latest/rules/no-prototype-builtins which is "fixed" by this, not sure how important this is though 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, so there does seem to be a difference there 🤔 changing this changes the browser integration tests, target
of the mechanism becomes Window
or Node
instead of EventTarget
🤔 not sure why, but I guess I'll leave this as it was then!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL, thanks! No objections to leaving it as-is :D
@@ -17,14 +17,14 @@ export function domainify<A extends unknown[], R>(fn: (...args: A) => R): (...ar | |||
* @returns wrapped function | |||
*/ | |||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | |||
export function proxyFunction<A extends any[], R, F extends (...args: A) => R>( | |||
export function proxyFunction<F extends (...args: any[]) => unknown>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sadly this somehow still has to be any
, not quite sure why but didn't feel like investing more time into this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM! I like the type refactors. Had a concern with the GCP package type changes there. Can we extract these to their own PR (potentially when working on v9) and merge the browser/core changes in first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
h: unfortunately, these types are public API because wrapHttpFunction
, wrapCloudEventFunction
and wrapEventFunction
are exported and reference the types in their signature. Maybe we do this change in v9 instead?
@@ -56,16 +64,6 @@ describe('internal wrap()', () => { | |||
expect(wrap(wrapped)).toBe(wrapped); | |||
}); | |||
|
|||
it('calls "before" function when invoking wrapped function', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: why did we remove this test? (I guess it's redundant but just wanted to double-check)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the before
option from the function, it was not used anymore :)
|
||
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, no-prototype-builtins | ||
if (!proto || !proto.hasOwnProperty || !proto.hasOwnProperty('addEventListener')) { | ||
if (!proto || Object.prototype.hasOwnProperty.call(proto, 'addEventListener')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the difference between the two? shouldn't this be equal since we pass proto
as the this
arg? I guess the only apparent reason to me would be saving a couple of bytes. But if using Object.prototype.hasOwnProperty
is more correct, we should go for it!
I extracted the gcp stuff out into #14476 👍 |
We use a heavy dose of
any
, that I would like to reduce.So I started out to look into
wrap()
, which made heave use of this, and tried to rewrite it to avoidany
as much as possible. This required some changes around it, but should now have much better type inferrence etc. than before, and be more "realistic" in what it tells you.While at this, I also removed the
before
argument that we were not using anymore -wrap
is not exported anymore, so this is purely internal.