Destructuring causes error for null/undefined properties

The following code:

interface Foo {
    x: number;
}

interface Bar {
    foo?: Foo;
}

function test( { foo: { x } }: Bar ) {
    alert( x );
}

test( {} ); // TypeError: Cannot read property 'x' of undefined

transpiles to:

function test(_a) {
    var x = _a.foo.x;
    alert(x);
}

instead of the (arguably) preferable:

function test(_a) {
    var x;
    if (_a.foo) x = _a.foo.x;
    alert(x);
}

The transpiled code does not check for the presence of optional property foo in the Bar interface. This leads to an error at invocation.

I can see three possible solutions:

1. Always check for member existence when transpiling destructuring statements.
2. Check for member existence only when an element is optional in the interface or type declaration.
3. New syntax for destructuring that can indicate members should be checked.

E.g.

function test( { foo?: { x } }: Bar ) {}

[RyanCavanaugh]

This is just the ES6 destructuring behavior; we don't use type system data to change the runtime behavior.

That said, it's a bad idea to use a property of an optional property as part of a destructuring, and we should probably consider this an error.

I agree that it should be an error if not handled elsewhere.

Destructuring assignment is a great way to clear out boilerplate code, which makes it easier to focus on domain-specific logic. It feels crippled without support for optional parameters (which are a TypeScript feature, not an ES feature).

I feel like if we extend destructuring with optional annotations - in a manner entirely consistent with conditional function parameters - it greatly enhances the utility and applicability of destructuring.

Strawman:

interface AjaxOptions {
    timeout?: number,
    onComplete?: () => void;
    onSuccess?: () => void;
    onError?: () => void;
}

type AjaxParams = { url: string, method?: string, body?: string, data: string, options?: AjaxOptions }; 

function send( { url, method = 'GET', data?, options?: { timeout, onComplete, onSuccess, onError } }: AjaxParams ) {
    // do stuff
}

The code in the body of the example can now check whether timeout is defined without worrying whether options is defined. This reduces developer effort, makes the code less error prone (especially if refactoring a property into or out of the options object), and clarifies the function by removing boilerplate code.

Basically, use the same ? syntax optional parameters use, but for properties. This cascades downward, so child properties of optional properties are themselves implicitly optional. (Or make it an error to have a non-optional descendant of an optional property.)

Using the destructuring assignment expression itself here instead of the metadata means that you must opt-in to this behavior. It is not inferred from the type definition.

[RyanCavanaugh]

Accepting PRs. Any property destructuring must be non-optional or have a default

[Arnavion]

@RyanCavanaugh Just to be clear, are you accepting PRs to make { foo: { x } }: Bar (where Bar.foo is optional) an error? Or to add support for { foo?: { x } }: Bar with the emit @errorx666 is asking for?

Edit: Never mind, I see from the linked issue that it's the former.

[falsandtru]

I already said about this problem in #6125. This issue is duplicate.

[mhegazy]

we are accepting PRs for flagging destructuring into a optional property as an error. We still do not want to do any type directed emit.