Add refactor convertToOptionalChainExpression

[jessetrinity]

closes #35018

Adds a refactor to convert && binary expressions to optional chain expressions.

Supported conversions:

//before
[|a && a.b && a.b.c|];
//after
a?.b?.c;

//before
[|a && a.b && a.b.c()|];
//after
a?.b?.c();

We offer the refactor to convert ternary expressions to nullish coalescing expressions if the type of c is not one of null, unknown, undefined, or any:

//before
[|a.b ? a.b.c : "false"|];
//after
a.b?.c ?? "false";

An explicit request ("invoked") for a 0-length span will check the largest containing binary expression for a refactor:

// before
a && a.b && [||]a.b.c;

// is equivalent to
[|a && a.b && a.b.c|];

// after
a?.b?.c;

[sandersn]

Still need to think through the main binary expression loop in getInfo, here are the comments I've got so far.

[andrewbranch]

Most of your test cases are expression statements, but expression statements that don’t immediately contain call expressions are somewhat rare. If the idea is to automatically find a suitable expression node from a zero-width span, I think you could try just walking up ancestors until you see something that’s unlikely to be part of an expression you can transform, like a statement. For example, say you have

return foo(a && a.b && a.b/*|*/.c);

You start on an Identifier, and walk up because an Identifier is obviously part of something you could transform. One parent up is a PropertyAccessExpression, which could also be part of a candidate, so you keep walking. Another PropertyAccessExpression, keep going. A BinaryExpression with an && token, keep going, while saving this node as a candidate expression. Now, since you have a candidate BinaryExpression, I think you’d want to continue only if the next parent is also a candidate BinaryExpression. It’s not, so you use the BinaryExpression as the potential node to transform.

I’m probably oversimplifying this in my head, but I think you at least want to make sure the refactor works for

• return statement expressions
• call arguments
• variable initializers

in addition to ExpressionStatements.

[sandersn]

Sorry, I didn't have enough time to look at the refactor again, but I did review the tests and I think I found a mistake in the emit.

[sandersn]

Some comments on the new syntactic code, plus a suggestion for how to handle a && a.b && a.b().

[andrewbranch]

You should also node = skipParentheses(node) at the top here

[jessetrinity]

What would be an example we care to test, something like a && (a).b?

[andrewbranch]

Yep, foo && (foo.bar === 1) seems more realistic since the precedence between different binary operators can be hard to remember, but I think if you put skipParentheses in the right places, you can trivially handle foo && (((foo).bar) === 1) 😁

[andrewbranch]

I think there’s possibly a less efficient but more easily understandable way to write this function by going depth-first, grabbing the left-most name of both the chain and the subchain right away, and walking up their parents. But I couldn’t write an elegant example in a few minutes, so maybe it wouldn’t be as good as I think it would.

[andrewbranch]

I guess the easiest to understand way to break it down, in my mind, would be to have a function that returns the array ["a", "b", "c", "d"] for the PropertyAccessExpression a.b.c.d (it could return strings or Identifiers, either way), then

function chainStartsWith(chain: EntityNameExpression, subchain: EntityNameExpression) {
  const subchainIdentifiers = getIdentifiersInEntityName(subchain);
  const chainIdentifiers = getIdentifiersInEntityName(chain);
  return every(subchain, (identifier, index) => {
    return identifier.getText() === chainIdentifiers[index]?.getText();
  });
}

This would be a bit more eager than what you have, and would allocate some arrays you don’t strictly need, but is easier to follow to me.

[andrewbranch]

In this example I also presuppose the types EntityNameExpression to guarantee that you have a string of dot-separated identifiers, because it makes this function easier to reason about and there are already isEntityNameExpression functions you can use, but if you wanted to nitpick on efficiency, you could check on the fly in getIdentifiersInEntityName, returning undefined if you discover that you don’t actually have an EntityNameExpression.

[jessetrinity]

Would this make other cases we care about easier to implement (maybe optional element access) in addition to making it easier to read? It does feel quite awkward to go through the entirety of both access chains to build the arrays if we would terminate on the first check we would have made otherwise. On the other hand, really long access chains in binary expressions are probably not common anyway?

[andrewbranch]

I think expanding to optional element access should be pretty easy either way.

[sandersn]

Just a couple of tiny style suggestions left.

[sandersn]

Would this work as well? Seems easier to read than double !

Suggested change

	return chainStartsWith(chain, subchain) ? subchain : undefined;
	return (isIdentifier(subchain) || isPropertyAccessExpression(subchain)) && chainStartsWith(chain, subchain) ? subchain : undefined;

[sandersn]

maybe just change the name to finalExpression here too?

[sandersn]

🎉