The suggestion is to add a keyword that says "I don't need to specify this optional type parameter, I am only passing by to a later one, please resolve to whatever the fallbace default type
📃 Motivating Example
Considering the case:
import express from 'express'
interface CreateUserParams {
name: string
age: number
}
export type CreateUserRequest = express.Request<
Record<string, string>, // ❌ unrelated, but there's no way if skipping this
any, // ❌ could've specified it, but decided to not bother
CreateUserParams // ✅ actually what is needed and relevant
>
All of the type parameters of express.Request are optional. In the case when I only need to specify the third parameter, there is no way of skipping the first two. Instead, I have to go to the definition, see what the fallback type is, and provide the fallback type here explicitly; this gets words if the fallback type isn't exported.
Sometimes this can be mitigated by a better design, sometimes not.
The suggestion is to add a keyword (e.g., CSS's unset or SQL's default) that would do the lookup itself:
export type CreateUserRequest = express.Request<unset, unset, CreateUserParams>
This might be a breaking change for codebases where unset is an existing identifier. If that's a concern, consider ? as the keyword:
export type CreateUserRequest = express.Request<?, ?, CreateUserParams>
💻 Use Cases
What do you want to use this for? – Skipping optional parameters in generics defined by upstream libraries.
What shortcomings exist with current approaches? – The need to lookup the definition.
What workarounds are you using in the meantime? – I look the definition up.
🔍 Search Terms
unset type parameter default
✅ Viability Checklist
⭐ Suggestion
The suggestion is to add a keyword that says "I don't need to specify this optional type parameter, I am only passing by to a later one, please resolve to whatever the fallbace default type
📃 Motivating Example
Considering the case:
Try it.
All of the type parameters of
express.Request
are optional. In the case when I only need to specify the third parameter, there is no way of skipping the first two. Instead, I have to go to the definition, see what the fallback type is, and provide the fallback type here explicitly; this gets words if the fallback type isn't exported.Sometimes this can be mitigated by a better design, sometimes not.
The suggestion is to add a keyword (e.g., CSS's
unset
or SQL'sdefault
) that would do the lookup itself:This might be a breaking change for codebases where
unset
is an existing identifier. If that's a concern, consider?
as the keyword:💻 Use Cases