Lwc: add support for optional chaining in JS and templates

[caridy]

Add support for new syntax foo?.bar in JS
Add support for new syntax {foo?.bar} in HTML

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

Current Status: Stage 3

[rtm]

You are supporting foo?[bar] and foo?() too, I assume, at least in JS?

[caridy]

@rtm yes, in JS yes... although that's not the syntax, it is foo?.[bar] and foo?.() for function calls. you can look at the proposal for more details.

In the template, no, we don't allow function calls or dynamic properties.

[noobtiger]

It just reached stage 4 https://twitter.com/robpalmer2/status/1202312626891452416

[Jerrkawz]

@caridy We are excited to use this for the RRH related list effort as we have some use cases that require it. Just want to make sure this is know:

We have a component that needs to pass data down into a child component which will then use it as an input to a wire.

<c-child recordTypeId={wiredRecord.data.recordTypeId}/>

We can't use a getter to safety check this since it would not be analyzable by the ADG. And we don't want to fuzzy up the public facing api of the child component by requiring an entire record to be passed in. I assume when we can do:

<c-child recordTypeId={wiredRecord?.data?.recordTypeId}/>

The adg will be able to resolve this and everything will be wonderful.
@kevinv11n @shesmer @ebcraig FYI

[StefanFrederiksen]

What's the status on this?

I can't find any news on this since the Stage 4 announcement and it's been almost half a year.

[pmdartus]

This feature is currently in the backlog and we don't have any plan to work on it in the near future.
/cc @Gr8Gatsby

[rtm]

This is an excellent example of the folly of an architectural approach involving a proprietary parser, and not coincidentally a key reason why LWCs, for all the stellar design work that went into it, will never be more than a niche player in an open ecosystem, adopted only by Salesforce developers and then reluctantly.

[diervo]

@rtm that statement is fundamentally misleading, incorrect and certainly its a criticism of arguable value.

First of all this has nothing to do with "proprietary parsing". We support out ot the box a particular ECMAScript version based on the standards that are implemented on the browsers as we see fit per our customers need.

We only add new features when they reach stage 4 and have been implemented in all the latests browsers we support, and we normally let it bake for a release or so to avoid bugs. We do this because it will be dangerous to our customers and the ecosystem to write things that won't work in all the environments OOTB or we have to be adding polyfills left and right as a regular practice.

Optional chaining and nullish coalescing literally just landed on the spec and have barely been implemented everywhere - NodeJs LTS (12.x) does not yet have it for example.

In any framework on your choice you will have to run babel, or Typescript to support this feature as of the time of this writing, and guess what!!! You can do the same thing in LWC! Because is just HTML, and JS! You can use the same OSS tools (babel, typescript, parse5) and the same bundling, TS, or whatever other pre-parser you desire.

@StefanFrederiksen support of both nullish coalescing and optional chaining in JS will land next release and its actually been assigned to me os of our last planning (Pierre was slightly incorrect :) ). In the meantime you can do as any other framework and run your own transpilation on top of the one we provide. As per HTML we need to make sure that we can still optimize it correctly and doesn't introduce any footgun ergonomically.

As a platform, we have to be opinionated and careful to guarantee that all the features we introduce still align with our goals of statically analyzability, enterprise scale, and long term support.

We strive to be the best framework for the enterprise, which by definition has a different set of goals as "pick-your-framework-of-the-day" goals. If that means being a niche player, so be it.

@rtm I'm having trouble finding constructive feedback or any meaningful take away from your comment, but it seems that it's just a negative rant and a complain for the sake of complaining. If you have any meaningful and reasonable feedback to how to improve our ecosystem we are certainly welcome to it.

[StefanFrederiksen]

@diervo Awesome, good to hear that it hasn't actually been scrapped because it's such a nice QoL feature to have as a developer.

Also thank you for clarifying that it's still possible to do now, even if it is with the use of external tools.

What would be the verdict of allowing this in markup as mentioned by @Jerrkawz?

A use case where displaying something only if the property and multiple layers exist would make development somewhat faster, than wrapping it in a getter property.

Something like the following should be quite clear.
<template if:true={property?.with?.nesting}> ... </template>

Also on a small little tangent, why are Call Expressions (I think that's what the LWC told me it was called, basically anything JavaScript in the markup) disallowed in the first place?

[diervo]

Yes once we have it in JS, it is likely that we will open it too on the HTML.

However it's likely that for if statements we still want to restrict for force you to still write a getter in JS for the same reason as what you ask for the call expressions:

We can optimize a lot of things on the compiler if we keep the template syntax as simple, constraint and stateless as possible. The moment we allow you to write arbitrary Javascript on HTML, its game over.

It's a fine line between ergonomics and performance, but both features (optional chaining and call expressions) have been requested multiple times, so we will give it another though with the team see what can we do there.

[rtm]

@diervo My apologies for a poor choice of a platform for my "rant". I will take it elsewhere, such as a Medium post.

[gonardfreeman]

This feature is currently in the backlog and we don't have any plan to work on it in the near future.
/cc @Gr8Gatsby

B

Yes once we have it in JS, it is likely that we will open it too on the HTML.

However it's likely that for if statements we still want to restrict for force you to still write a getter in JS for the same reason as what you ask for the call expressions:

We can optimize a lot of things on the compiler if we keep the template syntax as simple, constraint and stateless as possible. The moment we allow you to write arbitrary Javascript on HTML, its game over.

It's a fine line between ergonomics and performance, but both features (optional chaining and call expressions) have been requested multiple times, so we will give it another though with the team see what can we do there.

I'd like to get rid of those long getters with this one aka
get formatOptions() { return this.oApi && this.oApi.options && this.oApi.options.format; }
tranforms into:
get formatOptions() { return this.oApi?.options?.format; }

[diervo]

We will update this in a couple of weeks, which will land on the next Salesforce release.

[Katulka]

What's the latest on this, I don't recall seeing it in the Winter 21 release notes. Would love to see this available in LWC.

[gonardfreeman]

What's the latest on this, I don't recall seeing it in the Winter 21 release notes. Would love to see this available in LWC.

We've got new error here.

LWC1002: Error in module resolution: Unexpected token: punc (.)

So I hope it is in work progress right now.

[diervo]

Unfortunately I don't believe this was merged for the Winter release which is being deployed right now (Oct/Nov 2020) because it was too late to land changes of this magnitude (we had to change a lot of other code on platform).

The good news is that is already merged for next release with some extra additions.

Also we are launching something new on December that you all will appreciate, stay tuned to twitter :)