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:

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

E.g.

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

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.

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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 error (@errorx666) is asking for?

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

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

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.

This implies that in cases where I know (because of program context) that the optional property is present in my object, I won't be able to destructure?
Even though that would be valid, working JS?

interface X { a?: { b: number } };
let x: X;

if (x.a) { // or some other domain rule that guarantees me 'a' is defined
  let { a: { b } } = x; // error: "a" is optional ?
}

I don't have any use for such code, just pointing out the possible implications if it becomes an error.

Andy (Andrewkraft) (@Andy-MS)

Andy (Andrewkraft) (@Andy-MS) can we have a syntax to indicate something nullable is actually set and so the error should be ignored? See my previous comment #6784 (comment)

what about doing it same way as c# ?. operator? some random blog with explanation

var property  = some?.nested?.property?.name;
// with is equivallent to:
var property = some == null ? null
    : some.nested == null ? null
        : some.nested.property == null ? null
            : some.nested.property.name;

in ts this would be current syntax

var some: { nested?: { property?: { name: string } } } = ...;
var { nested: { property: { name } } } = some; // name has type string | undefined

transpiled into:

var property = ['nested', 'property', 'name'].reduce((obj, prop) => obj && obj[prop], some);

not sure how to handle multiple nested variables ...

What's the current status of this?

const [a, b] : string[] = [];
const d: string = b.toUpperCase();

In strict-mode should be invalid. Why only at runtime I get aTypeError: Cannot read property 'toUpperCase' of undefined ?

Thought in strict-mode it is guaranteed that values are not null or undefined implicitly :(((
I think it would be great if this can be fixed,
A proper destructuring should handle all cases recursively like an "empty array" somehow...
Maybe by recursion.

This code will dramatically fail because destructuring an undefined value seems to be allowed:

const f1 = (something: string): { foo: string } | undefined => {
  return something == 'foo' ? { foo: 'bar' } : undefined;
};

const { foo } = f1('bar');

Shouldn't TypeScript throw an error if it's the case? Happy to put my hands in TS' code if we have agreement on this expected behaviour :)

Samuel ROZE (@sroze)

Samuel ROZE (@sroze) it does error if you have strict null checks on. When you run in sloppy mode, it behaves as expected and does not error.

Ran into the same problem. Any fixes?

This works under strictNullChecks, which there's no excuse to not have on at this point

The issue is not fixed.

@sroze it does Error if you have strict null checks on. When you run in sloppy mode, it behaves as expected and does not error.

The issue is not fixed. When I try to destructure an object in an array, it doesn't throw a compile-time error, but the code explodes at runtime with a TypeError. Even with everything strict

drago1520

drago1520 you're missing noUncheckedIndexedAccess

Navigation Menu

Repository navigation

Destructuring causes error for null/undefined properties #6784

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Destructuring causes error for null/undefined properties #6784

Description

Activity

RyanCavanaugh commented on Feb 1, 2016

RyanCavanaugh commented on Feb 1, 2016

Arnavion commented on Feb 2, 2016

falsandtru commented on Feb 2, 2016

mhegazy commented on Feb 6, 2016

jods4 commented on Mar 24, 2016

10 remaining items

jods4 commented on Mar 13, 2017

CzBuCHi commented on Jun 5, 2017

danielbodart commented on Feb 14, 2018

schmaluk commented on Apr 21, 2018

sroze commented on Oct 13, 2019

kitsonk commented on Oct 14, 2019

prajun7 commented on Apr 13, 2022

RyanCavanaugh commented on Oct 23, 2025

drago1520 commented on Nov 21, 2025

RyanCavanaugh commented on Nov 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions