optional chaining in javascript

[siegfrieddb]

https://github.com/tc39/proposal-optional-chaining

[oriadam]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

[kiding]

Implemented in Safari TP 91.

[karlhorky]

Also works with Chrome Canary when started with a flag: https://mobile.twitter.com/karlhorky/status/1170286896058109952

Full list of implementation tracking: tc39/proposal-optional-chaining#115

[Schweinepriester]

Coming with Firefox 74:

The Optional chaining operator has been implemented (bug 1566143).

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/74

---

Also:

Via MDN already on caniuse: https://caniuse.com/#feat=mdn-javascript_operators_optional_chaining

Alternatively: https://kangax.github.io/compat-table/es2016plus/#test-optional_chaining_operator_(?.)

[LarsDenBakker]

Whats the way forward here? Its shown on caniuse.com but not available here for programmatic use cases.

[Fyrd]

Available as mentioned by @Schweinepriester

@LarsDenBakker since the data comes from https://github.com/mdn/browser-compat-data I'd suggest looking into accessing that data if you need it programmatically.

[kiding]

At first I was a bit confused why this issue got closed, but it started to make sense.

Caniuse is not quite the right place to hold such granular data—Especially for ECMAScript, Version X as a whole would be great; but for individual proposal/function entry, compat-table or MDN is probably more suitable.

Since there are a lot of newly opened issues in the same line as this, it’d be great this could be made somewhat clear in one way or another as we move forward. That assumes I didn’t misunderstand the intention, so any thought is appreciated!

[mreinstein]

@Fyrd @kiding I can definitely appreciate the motivation behind closing this particular issue; there are hundreds of individual js features that one could test for; it doesn't make sense to track them all individually in this database.

I'd like to describe one use case I have for this particular test though.

Currently in my codebase I generate 2 builds; 1 for older browsers that lack module support, and 1 for newer browsers that natively support modules. I then feature test the current browser and deliver the appropriate bundle (commonly known as the module/nomodule approach.)

This approach has worked great for several years. I've been able to ship code that uses advanced javascript features that works in browsers going all the way back to ie10!

However, times have changed. We no longer need to support ie at my job (YES!) and that means almost 100% of our expected customers have all the es6 niceities and a lot more. I want to change the bundling approach from detecting es module support to use optional chaining/nullish coalescing instead. If the browser supports it natively, deliver a bundle with NO babel used. If it's the small minority of browsers that lack optional chaining/nullish coalescing, serve the babel-ified build.

if we were to add those 2 particular features to this database, the downstream tools that rely on caniuse-db (most notably browserslist) I can change my browserslist config to be something like:

supports es20-optional-chaining
supports es20-nullish-coalescing

[karlhorky]

the downstream tools that rely on caniuse-db [such as] browserslist [would gain new capabilities]

That would be cool for sure!

But in case it's decided in the end that caniuse-db is not the place for this, then maybe these types of approaches to extend browserslist would be an option:

browserslist/browserslist#522