Reusable callbacks: When destructuring, missing properties should be excluded from the infered type.

[denis-migdal]

🔍 Search Terms

• destructured function parameters.
• contextual typing (?).

Not sure if I have the correct vocabulary.

Related issues :

• Keyword for inferring a new type from destructured parameters #55908

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When inferring the type of a ({arg1, arg2}) => void callback, missing properties should be excluded from the inferred type.

Currently, TS infers it as ({arg1, arg2}: T) => void, with T being the constraint used during the inference.
I'd like the inferred type to be : ({arg1, arg2}: Pick<T, "arg1"|"arg2">) => void.

TS is able to properly infer the callback type when the whole argument is missing (i.e. () => void), so I guess my suggestion should also be technically possible ?

📃 Motivating Example

This can be useful to declare callbacks that must be compatible with a given context, while enabling their usage in other contexts, compatibles with the callbacks, not necessary with the original context.

Playground Link

type Bindings<CTX extends Record<string, any>> = {
    [K in keyof CTX]: (ctx: CTX) => void; // <- in reality the type here is a little more complex.
}

// in reality we use B & Record<Exclude<keyof B, keyof T>, never> to exclude extra-keys.
function foo<T extends Record<string, any>, B extends Bindings<NoInfer<T>>>(p: {props: T, bindings: B}) {
    return p;
}

const x = foo({
    props: {
        foo: 34, faa: "ok", fuu: "ok", fii: 42
    },
    bindings: {
        fii:() => {},                   // OK: () => void
        foo:(a) => {},                  // OK: (a: T) => void
        faa:(args: {foo:number}) => {}, // OK: ({foo: number}) => void
        fuu: ({foo}) => {}              // NOK: ({foo}: T) => void / we want ({foo: number}) => void
    }
})

// we could reuse it like :
foo({
    props: {
        ...x.props,
        fii: string // override a property with a completely different type.
    },
    bindings: {
       ...x.bindings,
       fii: () => {} // binding may need to be overridden too.
    }
})

💻 Use Cases

1. What do you want to use this for?

Writing reusable callbacks.

2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

We need to explicit the types when destructuring, e.g. faa: (args: {foo:number}) => {}).

A possible workaround could have been the following, however TS doesn't do a "per key" inference.

type Bindings<CTX extends Record<string, any>, KEYS extends Record<keyof CTX, keyof CTX>> = {
    [K in keyof CTX]: (ctx: Pick<CTX, KEYS[K]>) => void; // <- in reality the type here is a little more complex.
}

An alternative solution would be to allow TS to be more lax with ({foo}: T) => void, e.g. allowing ({foo: ...}) calls, even if the argument doesn't respect the T constrainst.

[RyanCavanaugh]

This seems like basically the same thing as #42419: presupposing that if you don't destructure a property, you necessarily didn't care about it, but I don't think this is a universal truth. The comments in there outline counterexamples to that idea.

[denis-migdal]

This issue would indeed solve mine, but I do not agree this is a duplicate, as I am at the inference level.

I have a ({foo})=> void without an explicit type annotation. And I want it to be inferred in a more "conservative" (?) way. To my knowledge, there is currently no ways to express it in TS. Pick<T, K> wouldn't work here as T is defined in the context, and as far as I know, we have no means to access it when we define the callback.

We can, however, easily opt out this suggestion by changing how the type is defined in the main function.

This is a quite different context and behavior compared to the other issue.
The other issue corresponds more to my alternative solution at the very end of mine.

(on another note, it could be nice to have a kind of guide to define tricky types / or a list of some more or less obscur patterns/tricks/advice/type design principles... some type definitions can be quite a pain).

[RyanCavanaugh]

I don't think that would be a correct or better inference, is what I'm saying.

I have a ({foo})=> void without an explicit type annotation. And I want it to be inferred in a more "conservative" (?) way.

The (?) is the problem here; the proposed inference makes the function accepting of more input values, not fewer. It makes the program more likely to have a type problem.

[denis-migdal]

the proposed inference makes the function accepting of more input values, not fewer. It makes the program more likely to have a type problem.

I don't understand how it would increase the likelihood of having a type problem.
To the contrary, it would solve type issues when trying to reuse such callbacks.

And if we do not want this behavior, we can still force the type parameter, simply by playing with the way we define the generic type parameter in the main function:

function foo<T, B extends Bindings<T>>(b: B) { return b }
function foo<T>(b: Bindings<T>) { return b }

[RyanCavanaugh]

const x = foo({
    props: {
        units: "mm" as const,
        length: 0
    },
    bindings: {
        units: () => {},
        length: ({length}) => {}
    }
});

// Unit mismatch and we just crashed our Mars probe
const inches = { units: "inches", length: 3}
x.bindings.length(inches);

[denis-migdal]

You have exactly the same issue with the code below:

bindings: {
        length: (args: {length: number}) => {}, // what I am currently doing, you'll get the same issue.
        units: () => {}, // <- you'll also have an issue here
    }

The issue doesn't come from my suggestion, but from the way you defined the type of bindings.
Obviously, you need to define the type of bindings according to the usage you want:

• callback reuse: cf my suggestion.
• direct usage: you need to force the parameter type when defining the type of the bindings parameter. This is the only way to truly prevent issues (cf (args: {length: number})).

Therefore the code base that would have an issue with my suggestion, already have an issue that can manifest anytime. The danger is already here.

I'll also argue that splitting the value and the unit is a bad idea.

For more context, here what I am doing:

const Dataset = createDatasetClass({...});

const Line = createDatasetClass({
      properties: {
           ...Dataset.properties,
           parsedData: View("data", lineParser),
      },
      bindings: {
          ...Dataset.bindings,
          parsedData: (context, value) => { // value can be automatically inferred, this is more practical than using the whole properties object.
                context.data = value;
         },
         whatever: (context, value, properties: {color: string}) => {
               // ...
         }
      }
});

const line = new Line({...});

The bindings stored as a static member is only used for reuse.
The bindings given as parameters is only used internally, inside the createDatasetClass function, with no type issues (due to the fact that we are inside a generic function) :

function createDatasetClass<...>(options: ...) {
      // here bindings is viewed as a {[K in keyof T]: (context, value: T[K], properties: T) => void}
      // so no issues internally.
      const properties = createProperties(options.properties);
      const renderer = new PropertiesRenderer(properties, options.bindings);
      return class {
           readonly static name = ...;
           readonly properties = properties;
           update() {
                renderer.render();
           }
     }
}

[RyanCavanaugh]

Just to be 100% clear: our position, which is longstanding and consistent, is that destructuring is an internal implementation detail of a function that should not change the function's external behavior or signature.