Destructuring syntax

[webdif]

How about:

const obj = {
  foo: {
    bar: {
      baz: 42,
    },
  },
};

// const baz = obj?.foo?.bar?.baz; 
const { baz } = obj?.foo?.bar?;

It would be a ? operator, so it's certainly out of scope.
But it would be very nice and intuitive to have such a syntax in my humble opinion, so here's the issue.

[RusinovAnton]

Lets go wild

const { foo: ?{ bar: ?{ baz } } } = obj?.;

[webdif]

Oh, I just stumbled upon this: #6
But answers are not satisfactory, with even worse syntax…

[claudepache]

But it would be very nice and intuitive to have such a syntax in my humble opinion, so here's the issue.

Is it intuitive?

let obj = null;
let baz = 2;
({ baz } = obj?.foo?.bar?);
console.log(baz);

Should it log 2 or undefined?

IOW, is it optional assignment of a value:

let _ =  obj?.foo?.bar;
if (_ != null)
   ({ baz } = _);

or assignment of an optional value:

({ baz } = obj?.foo?.bar ?? { });
// or
({ foo: { bar: { baz } = { } } = { } } = obj || { });

?

[webdif]

I think it would be assignment of an optional value, and it should log undefined.

I did not know about ??, but I think this is pretty nice:

const { baz } = obj?.foo?.bar ?? { };

It's not as handy as:

const { baz } = obj?.foo?.bar?;

But it's clean, short enough, and baz is not repeated twice 👍

[Whobeu]

Coming from 12 years of C# I am used to its newer "??" and Safe Navigation "Object?" syntax. While I agree that some of the destructuring examples can create some non-intuitive code, the power unleashed to the programmer is quite interesting.

Of course such arguments over language changes are not unique to JS. Python had a recent furor over proposed syntax changes to allow Assignment Expressions (seems kind of silly with all the furor over that one) resulting in the creator stepping down. Perl has had ongoing arguments for years over Smartmatch "~~" and still calls it experimental.

[zfrisch]

({ baz } = obj?.foo?.bar ?? { });

Just to clarify, this is basically giving us a default value outside from undefined? So if for any reason this object (obj.foo.bar) isn't defined entirely and optional chaining falls through, it'll return an empty object?

[dusave]

@zfrisch theoretically, yes. However, ?? is part of a different proposal which is only loosely tied to this one. As it stands today, that is the behavior.

[armanozak]

‪I like that syntax a lot and actually think it will lead to an optional destructuring syntax like the following in near future:

‪const {foo ?: {bar ?: {baz}}} = obj?

IMHO, this is safe, readable, and inline with the optional chaining syntax.

[littledan]

You can do something similar using destructuring defaults: https://mobile.twitter.com/mfpiccolo/status/1080193719637143552

I am not convinced it would be helpful to add this feature. It seems like a lot of extra stuff just for null handling and the intersection of these two features. I think it would make code more confusing.

[armanozak]

Is optional chaining not all about null/undefined handling? After all, we could already do sth. like that:

const prop = ((foo || {}).bar || {}).baz;

P.S. Altough I do understand what you mean by destructuring defaults, I could not understand why you referred to that tweet. It has nothing about destructuring defaults. It is just another syntax proposal for optional destructuring. If you mean you find the syntax proposed in the tweet is confusing, I agree. But I also believe we can have a better syntax.

[littledan]

I mean, defaults handle undefined and not null. Anyway, I wonder if ?? will handle many of the use cases in this feature request, for when you do want null support.

[TylerBarnes]

const {
  foo?: {
    bar?: { baz }
  }
} = obj;

would be so nice!

[mitchellsimoens]

Optional chaining is syntactical sugar, yes. You can get the same result as the snippet @armanozak posted:

const prop = ((foo || {}).bar || {}).baz;

But the optional chaining syntax is much more readable. That snippet is "ugly" and the more nested the uglier it gets because you have to start wrapping things in parentheses more and more.

So while default values in destructuring can get you the end result:

const { foo: { bar: { baz } = { } } = { } } = obj || { };

It's not as readable as optional destructure chaining could be:

const {
  foo?: {
    bar?: { baz }
  }
} = obj;

I know... some people are likely thinking "where will it end?!" but you have others saying "why pick and choose what you throw sugar on?" Destructuring is sugar over chaining so if chaining has sugar to handle undefined properties, why shouldn't destructuring?

[TylerBarnes]

Definitely. To add to that, sugar that makes code easier to read, write, and reason about is inherently valuable due to time savings and reduced mental load.

[rijnhard]

So I thought this could be used to replace deep object merging, but it can't.
So in use case I find it a bit limited,

• for extraction a single value from an object const { baz } = obj?.foo?.bar?; already works fine.
• for defaulting multiple fields inside deep objects (Example B), something like lodash.merge works better, and I'd be hard pressed to say Example A works at all, it only has a sweet spot, on of extracting a few variables.

// Example A
const {
  foo?: {
    bar?: { baz }
  }
} = obj;

// Example B
function myfunc(options = {}) {
    options = _.merge({
        foo: {
            bar: {
                baz: true
            }
        },
        x: {
            y: {
                z: true,
                y: true
            },
            z: false
        },
    });
    // carry on
}

Although this argument is compelling

I know... some people are likely thinking "where will it end?!" but you have others saying "why pick and choose what you throw sugar on?" Destructuring is sugar over chaining so if chaining has sugar to handle undefined properties, why shouldn't destructuring?

The counter argument is everything we say yes to, means something else we say no to, we just may not know what is yet.

Adding simple things with limited value now, then we block ourselves from future functionality and it's hard to imagine because we don't know what that is.

My vote:

// YES, for clear value
const { baz } = obj?.foo?.bar?;

// NO, for no clear value
const {
  foo?: {
    bar?: { baz }
  }
} = obj;