Safe navigation operator (?.)

[HamedFathi]

🙋 Feature Request

Recently, Optional Chaining for JavaScript went to stage 3. Seems we will achieve this feature in JS and TS soon.

Milestone: Typescript 3.7
Suggestion: "safe navigation operator", i.e. x?.y

Angular 2+ supports this feature long time ago as The safe navigation operator ( ? ) and null property paths

<p>The item name is: {{item?.name}}</p>

Is it possible to support this operator in Aurelia vNext template engine too?

🤔 Expected Behavior

Skip rendering if the item is null or undefined.

😯 Current Behavior

We don't have this operator now.

💻 Examples

<p>The item name is: ${item?.name}</p>

[3cp]

Even aurelia v1 has this feature implicitly built-in in expression. We don’t need the syntax, because our expression always does the check to avoid runtime exception.

[fkleuver]

We don’t need the syntax, because our expression always does the check to avoid runtime exception.

This syntax is coming to the ES spec and our intent with the expression syntax is to stay as close to native as possible. With this syntax, there is a clean and easy way to get this kind of safety whilst also being able to opt out of it (by not using the syntax).

So while we don't need the syntax, I still think we should have it, because it improves consistency.

[3cp]

It will be a not obvious breaking change for Aurelia 2 from v1. So some decision has to be made.

[davismj]

Doesn't sound breaking to me. If I understand Fred, the only difference is that the Expression parser will now understand {prop1?.prop2}, which would have failed to parse in au1.

[HamedFathi]

@fkleuver

I think you should consider ?? too.

Current Stage: Stage 3
Nullish Coalescing for JavaScript

Milestone: Typescript 3.7
Nullish coalescing operator (??)

[fkleuver]

@davismj No, my idea is to switch the behavior to null-coalescing operator and then to have the vCurrent compat package turn on a flag where the old behavior is retained, but with the new behavior it would be a breaking change. And it is a good one imo, because:

1. It could easily be toggled for those who don't want to spend the migration effort (or those who simply don't like the syntax)
2. It gives people a way to let the framework actually throw if they want to be aware of when stuff is null when it shouldn't be
3. It makes the new syntax more consistent with real javascript

@HamedFathi Yep, agree, will get that in too

[rmja]

Please, don't introduce the ?. syntax in views. It will introduce unnecessary null reference errors without any possible gain. Other view "languages" like vCurrent, handlebars, and Razor all swallows null references making the ?. implicit.

[davismj]

@rmja while I personally appreciate the flexible syntax, I've squashed LOTS of bugs that have to do with properties being uninitialized. While some would prefer the flexibility and say the responsibility falls on the developer, others prefer a more explicit syntax, which would warn them when they've introduced a potential bug into the system.

As long as the more flexible syntax is easily toggled, I think the introduction will be a welcome change.

[fkleuver]

@rmja As I explained in the previous comment, it would be a toggle, a strictness option. I would probably use ?. in my views (and I'm sure so would many others) so as to be aware of when an object is null when it shouldn't be.

If we forced this on everyone, this in itself would be a massive breaking change for no good reason. Of course we'll avoid anything like that. So, no one would be forced to use the syntax so at the very least migration from v1 stays as painless as possible

[CuddleBunny]

Rather than a feature flag or compatibility package for the operator itself why not flag the strictness of template evaluations and the behavior of null in general? Perhaps something along the lines of "template strict evaluation" and "template render null as default"?

Default: ${test.name} and ${test?.name} should both behave the same with the latter being the preferred convention because it better conveys the actual behavior. In vCurrent the latter throws a parser error.

Strict: the first would throw ReferenceError: test is not defined and the latter would defer to another setting that specifies whether or not to allow null through or also throw. Turning on strict and disallowing null template evals would then force us to write ${test?.name || ''} or even ${test?.name ?? ''}.

[fkleuver]

Agree @CuddleBunny
This is pretty much what I meant to say, but you phrased it more clearly.

[ghiscoding]

Side note, TypeScript 3.7.2 with Optional Chaining and Nullish Coalescing is now live and is the final release version. You can get it from NPM and read the Microsoft Blog Post.

Finally we'll get some cleaner code, hopefully Aurelia will start using it..
Cheers

[davismj]

Aurelia taught TypeScript everything it knows about optional chaining.

[Vheissu]

Closing this as supported for optional syntax and bullish coalescing has been merged in thanks to the work of @fkleuver