-
Notifications
You must be signed in to change notification settings - Fork 10
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
Idea: Type Unpackers for Function Parameters #22
Comments
Great idea! What about just one operator which returns a tuple of types? type ParamTypes<F extends Function> =
F extends () => any ? {} :
F extends (p0: infer P0) => any ? [P0] :
F extends (p0: infer P0, p1: infer P1) => any ? [P0, P1] :
F extends (p0: infer P0, p1: infer P1, p2: infer P2) => any ? [P0, P1, P2] :
// ...
never;
type T0 = ParamTypes<() => void>; // {}
type T1 = ParamTypes<(a: number) => void>; // [number]
type T2 = ParamTypes<(a: string, b: boolean) => void>; // [string, boolean] Then you can further access particular indexes as you please, e.g. type Third = ParamTypes<typeof f>[2]; I used |
|
@kourge That's a great point. Consistent options:
@pelotom Is there a performance concern re: unpacking the whole array by default? If people are mostly going to access a single parameter, maybe we should consider that? |
Parameters are the declared inputs of a function signature, arguments are the runtime objects passed to a function: https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter
I really doubt there's much performance difference. |
On second thought you may be right about performance being a concern... I agree it might be better to play it safe. |
@pelotm I’d be happy with N short helpers, and also providing an up-to-N batch unpacker. (With a performance warning) Then naming wise, should it be:
(Where N is a number) or should it be something else? How many N should we provide? |
(I think the final name of the short form will influence our long form name) |
I think I'd actually vote |
Implemented in #24 |
* Update Dependencies - yarn.lock * Implement ParamN & ParamTypes for #22
Is this the same as the built-in If so, does it have the same limitation (only returns the first overloaded parameters)? |
@chocolateboy I believe these are equivalent implementations. The built-in one didn't exist when we added this one, as far as I know. As such I expect it to be subject to the same limits. But you should test it and let us know! We don't use many overridden method definitions in our codebase, because the syntax could be confusing. |
Because of TypeScript 2.8 Conditional Types, we can now do the following:
Issue for discussion!
Questions:
See also
ReturnType<Func>
The text was updated successfully, but these errors were encountered: