Replacement of Elvis Operator of Angular2 in Typescript

Repeatedly OR it with an empty object

I can't live without Elvis when writing HTML that references properties/subproperties that may or may not exist.

We can't write

this.myForm?.name?.first_name

I guess the people in charge of ES are probably spending most of their time actually writing JS, and not writing bits of front-end HTML that accesses object properties, hence their bemusement as to why anyone would need safe navigation.

They argue that "Nobody needs it", "It allows errors to be silent and could thereby bite you later" and "How would you interpret x?(y) ?"

My solution, while I wait for a future ES specification to include the Elvis operator, is as follows:

(((this.myForm || {}).name || {}).first_name )

In short, at every stage that a value could be undefined, you OR it with a {}, so that the undefined becomes an empty object. Once you put that whole thing into parentheses, you are safe to try to extract a property of it, since any property you try to extract from {} is simply undefined rather than an actual error.

It does get a bit ugly when you have multiple tiers, but in many cases it is less ugly than having to use a series of && to progressively step down through the levels of the object.

For array access, OR it with an empty array

If navigating into an array, for example if the form had many names and you wanted to select the first, the approach is similar:

((((this.myForm || {}).names || [])[0] || {}).first_name )

What happens if something in the chain is 0 or ""?

Suppose you were expecting to read a value "John" from this.myForm.names[0].first_name.

The typical situation that would normally trigger an error is where there is simply no object this.myForm. Instead of having an error, the formula I described above would work, and be interpreted as {}.first_name, which is undefined (but not an error).

Now imagine a hostile person has sneakily set this.myForm to 0 or "" or {}. Will we now see an error? No, because the values 0 or "" are considered falsy by Javascript, and {} is truthy but is itself {}, so this.myForm || {} evaluates to {}, and the remainder of the chain falls through to defaults as before, and the method still works, returning undefined rather than an error.

Example

console.log("Each example shows first the result WITH the workaround, and then WITHOUT.")

console.log("a. This should work normally.")
a = { myForm:{ names:[ { first_name:"John", surname:"Smith"}]} };
console.log(a.myForm.names[0].first_name)
console.log ((((a.myForm || {}).names || [])[0] || {}).first_name )

console.log("b. We have removed the first_name property. This still works.")
b = { myForm:{ names:[ {                    surname:"Smith"}]} };
console.log(b.myForm.names[0].first_name)
console.log ((((b.myForm || {}).names || [])[0] || {}).first_name )

console.log("c. We have removed the entire 'names' array. This is fixed by the workaround, but gives an error if run without the workaround.")
c = { myForm:{ } };
console.log ((((c.myForm || {}).names || [])[0] || {}).first_name )
console.log(c.myForm.names[0].first_name)

    console.log("d. Now the whole root object is empty. Again the workaround gets around this, but without the workaround, we get an error.")
    d = { };
    console.log ((((d.myForm || {}).names || [])[0] || {}).first_name )
    console.log(d.myForm.names[0].first_name)

Here's a solution that looks a bit more verbose:

const elvis = (...xs: (() => any|null)[]): any => {
    if(xs.length == 0) return null;
    const y = xs[0]();
    return xs.length == 1 || y == null ? y : elvis(...xs.slice(1));
};

const bla= {
    a : 'hello',
    b : null,
    c: undefined
}

console.log("a:", elvis(() => bla));
console.log("a:", elvis(() => bla, () => bla.a));
console.log("a:", elvis(() => bla, () => bla.a, () => bla.a.length));
console.log("b:", elvis(() => bla, () => bla.b, () => bla.b.length));
console.log("c:", elvis(() => bla, () => bla.c, () => bla.c.length));

Output:

> a: {a: "hello", b: null, c: undefined}
> a: hello
> a: 5
> b: null
> c: undefined

Update December 2019: TypeScript 3.7 introduced Optional Chaining which is equivalent to the safe navigation operator known in other languages. The ECMAScript proposal optional chaining has reached stage 4 and will thus be part of the specification in ES2020. See mdn: Optional chaining for more information.

Update July 2017: As JGFMK pointed out in the comments, there is an ECMAScript proposal called Optional Chaining for JavaScript. If/when the proposal reaches Stage 4, it will be added to the language specification.

There is neither a safe navigation nor elvis operator in TypeScript and, as far as I know, nothing comparable, either.

For a reference see the feature request at Suggestion: "safe navigation operator", i.e. x?.y. The explanation for not implementing it is the following (which, in my opinion, is a valid reason):

Closing this for now. Since there's not really anything TypeScript-specific that would require this at expression level, this kind of big operator change should happen at the ES spec committee rather than here.

The general tripwires for re-evaluating this would be a concrete ES proposal reaching the next stage, or a general consensus from the ES committee that this feature wouldn't happen for a long time (so that we could define our own semantics and be reasonably sure that they would "win").

Alternatives to that notation would be to use the logical AND operator, try/catch or a helper function like getSafe(() => this.myForm.name.first_name) as described in this post.