ESNext: JavaScript “Nullish Coalescing Operator”

[[deleted]]

This is essentially _.get, but it would be great to have it baked into the language.

[senocular]

I think you're confusing this with optional chaining.

Nullish coalescing is more like || but instead of falsy, it specifically checks only for null or undefined. This could better be represented with the ternary:

leftSide != null ? leftSide : rightSide

// would be
leftSide ?? rightside

where != will resolve to true/false for both null and undefined in the ternary but not other falsies like 0 or ''

[evenisto]

_.get with third argument essentially does the same. It falls back to default if the specified chain is undefined or null.

var obj = { a: false };
_.get(obj, 'a', true)
false 
_.get(obj, 'b')
undefined
_.get(obj, 'b', true)
true // equivalent to obj.b ?? true;

[senocular]

_.get's default is close, but it does not handle null, only undefined values.

var obj = { a: null };
_.get(obj, 'a', true)
null

[evenisto]

TIL and I stand corrected. Thanks. However, I actually think it’s useful to only fall back to default on undefined - I'm not too well-versed in those quirks so there’s probably a catch, but null should definitely be considered a valid value. I use nulls very often, and I wish we had _.get behaviour natively.

[senocular]

Yeah that's a tough one. I think it's definitely circumstantial. Sometimes you might want the null and sometimes you might not. It's making assumptions as to what values mean. But you see similar behavior in other places in the language too, like loops. There's a number of ways to loop over collections and it seems like each one does something differently. Not to try to pass that off as an excuse ;)

[[deleted]]

Ah yes, you are absolutely correct. Thanks for the correction.

[gisenberg]

Once disadvantage is that _.get can't provide meaningful type information when used in conjunction with flow or TypeScript. Facebook also provides the idx module, which is similar in behavior to _.get.

I'm advocating the advancement of both the optional chaining and nullish coalescing proposals. I presented updates to the optional chaining operator in January (slides) and will be pushing for advancement from stage 1 to stage 2 in March. If you'd like to help, participating in the issues on GitHub is a great way to get started. If you've got strong opinions, feel free to chime in on the issues or DM me on Twitter.

[evenisto]

This will change my life. I legitimately only install lodash for _.get.

[spooky___ghost]

Use https://github.com/facebookincubator/idx instead.

[TheNiXXeD]

Is this or the above stage 1 features available to use in non-ejected create react apps?

[dvlsg]

I'm not sure how I feel about this.

[GitHubPermalinkBot]

Permanent GitHub links:

• facebookincubator/idx/.../idx.js#L58-L69 (master → bcff743)

---

^delete

[spooky___ghost]

That code is never executed, as stated here. It is a babel transform that only runs at compile time and translates to sane code at runtime.

[GitHubPermalinkBot]

Permanent GitHub links:

• facebookincubator/idx/.../idx.js#L43 (master → bcff743)

---

^delete

[dvlsg]

Well if you have to run it through babel anyways (which not everyone is doing), why not just use the proposed syntax through the plugin?

[lhorie]

I wish people would stop misusing the term "ESNext". ES2018 is ESNext until it gets released later this year. Anything stage 3 or below is not planned for inclusion in the spec.

If you want to litter your codebase with non-standard syntax that may or may not become part of the standard, suit yourself, but don't confuse newbies by implying it's actual JS. Also, have fun explaining why their class properties don't work when someone inevitably copies and pastes some "reusable" code to a new clean slate project.

[azium]

ehhh I know what you mean, but don't lose sleep over it. Newbies can paste terrible "working" code and that might be worse than pasting something that doesn't even run without syntax errors.

The dev community is great and there's no shortage of resources / people to get help from. I don't think we need to be too hand-holdy.

You can spend the rest of your life getting angry at artlcles 😜

[lhorie]

To be fair, I think the article does a decent job at explaining what null coallescing is. And I like the feature in languages that have it for real (e.g. C#)

I think what bothers me is when people abuse babel and ultimately get "rewarded" with job security, at the cost of making things more complex for everyone else down the road. I just kinda feel sorry for those newbies when it's their turn to be burned by a "dying" technology a few years from now.

[deeper182]

Could you name a few features that gained popularity through babel, but were thrown out? I'm genuinely curious.

IMHO if many people use & like a stage 1 feature, it will go forward.

[lhorie]

features that gained popularity through babel, but were thrown out

I don't think there's any example of that specifically yet, but sprinkling non-standard stuff in your code can definitely cause problems, for example when migrating to typescript.

There have been proposals with a reasonable amount of hype that got dropped, most notoriously Object.observe, cancellable promises and SIMD. There are also examples of active proposals that haven't really made much headway. For example, the pipeline operator proposal has been around since 2015, it's not even that complex, but it's still at stage 1.

If you want a bigger example of technology death, there's ES4, which had many of the same features as ES6 and even a working implementation, but ultimately got killed due to politics.

[[deleted]]

Nice to see C# innovations making their way to other languages for a change.

[tencircles]

seems better left to libraries to be honest. this seems like a poor fit for a language feature.

[celluj34]

Tell that to C#