Support optional chaining

[vjpr]

When could we expect optional chaining support.

It will be released soon with babel@7.

babel/babylon#545

[7ynk3r]

this is super important to make the code more readable. i'd love to have this.

[eshikerya]

this feature is really important for project i am working for. waiting for implementation!

[suparngp]

This is really important for dealing with JSON responses without having to write a plethora of null checks. +1

[alangpierce]

Note that optional chaining is still a stage 1 proposal and has gone through a number of changes since the Babel plugin was implemented. It's very likely that there will be changes to both the syntax and the behavior before the final JS feature is released.

See various other discussions:
https://github.com/tc39/proposal-optional-chaining
https://github.com/rwaldron/tc39-notes
microsoft/TypeScript#16

[nodkz]

Can be a simple case of optional chaining (optional static property access) implemented today under option's flag esproposal or experemental?

I say about simple property reading from nested objects a?.b?.c, which will be an amazing improvement in the code for React components. Eg when reading graphql responses.

And leave dynamic and function/method calls uncovered while it in stage-1.

cc @calebmer @mroch

[zanettin]

which will be an amazing improvement in the code for React components. Eg when reading graphql responses.

would love to see that! we could remove tons of code and checks if flow also supports this syntax. thanks @nodkz and @alangpierce for having an eye on that.

[cloudkite]

looks like this will be in the next version 🎉763ffb5

[niieani]

@cloudkite looks like only parsing will be supported. Type support isn't landing, as the feature has been marked as experimental.

[fishythefish]

I've added (most) type support for optional chaining in 0.71.0 (gated behind the esproposal.optional_chaining flag). The exception is that you'll get a Flow error if you try to call a member expression where the call and/or member is part of an optional chain. Once I get optional chaining to play nice with our implementation of methods, I'll remove this restriction.

[houshuang]

This is amazing, I've been waiting for this.

In the following situation it complains about dash.exampleLogs[x] on line 319 because dash.exampleLogs might be undefined, however given that this code will only run if line 318 is true, shouldn't Flow realize that this cannot be undefined in this context?

Cannot get dash.exampleLogs[x] because an indexer property is missing in undefined [1].

     frog/imports/ui/Preview/ShowDashExample.js
     316│               const dash = aTdashs[this.state.example];
     317│               let data;
     318│               if (dash?.exampleLogs?.[x].type === 'state') {
     319│                 data = dash.exampleLogs[x].state;
     320│               } else if (dash.prepareDataForDisplay) {
     321│                 data = dash.prepareDataForDisplay(
     322│                   dash.initData,

     frog-utils/dist/types.js.flow
 [1] 157│     | {
     158│         type: 'logs',
     159│         title: string,
     160│         path: string,
     161│         activityMerge?: Object,
     162│         instances?: number
     163│       }
     164│     | { title: string, type: 'state', activityMerge?: Object, state: any }
     165│   )[]

[fishythefish]

@houshuang We could potentially do that, but Flow doesn't currently perform that refinement.