Use optional chaining, optional catch binding.

[sainthkh]

Description

Now that docgen parser has been changed to babel (#21853), we can freely use ES2020 features! 🎉

How has this been tested?

npm run docs:build doesn't fail.

Screenshots

N/A

Types of changes

Bug fix.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• [N/A] My code follows the accessibility standards.
• [N/A] My code has proper inline documentation.
• [N/A] I've included developer documentation if appropriate.
• [N/A] I've updated all React Native files affected by any refactorings/renamings in this PR.

[aduth]

I recall reflecting on this at #19931 (comment) , and observing that this sort of change will be a very common pitfall, and not an equivalent behavior to what would have existed previously.

Which is: If wrapperNode.current is undefined, then the negation would yield a value of true, which is not what we expect.

I'd recommend to just leave this change out.

I think we could use it here though, in the same file:

gutenberg/packages/block-editor/src/components/link-control/index.js

Lines 330 to 331 in 2cf0a3d

	!! wrapperNode.current &&
	wrapperNode.current.contains( document.activeElement );

[sainthkh]

! wrapperNode.current?.contains()
=== ! (wrapperNode.current && wrapperNode.current.contains())
!== wrapperNode.current && ! wrapperNode.current.contains().

As you said in the comment, we need a rule, no-optional-chaining-with-negation.

EDIT: opened an issue. #21984

[aduth]

It's only going to become a problem at the point when this file is properly type-checked, but: isEndingEditWithFocus is going to assume to be assigned a boolean value, which we were doing prior to these changes, but with these changes, it may also be assigned as undefined if wrapperNode.current is absent.

const wrapperNode = { current: undefined };
const current = wrapperNode.current?.contains( document.activeElement );
console.log( typeof current );
// "undefined"

Technically it still works because it's falsey, but the previous !! existed for this purpose to always coerce it to a boolean.

Suggested change

	isEndingEditWithFocus.current = wrapperNode.current?.contains(
	isEndingEditWithFocus.current = !! wrapperNode.current?.contains(

(Boolean( /* ... */ ) works as well for coercion, if wanting to be more explicit)

Aside: I think this is going to be another common pitfall with using optional chaining, where it will be easy to assign a falsey value where we might actually want a strictly-false (boolean) value, especially when the end of the chain is a function which we know to return a boolean (like Element#contains).

[sainthkh]

I committed your suggestion.

By the way, how about adding these findings to the JavaScript section of our coding guideline?

I simply thought optional chaining is just a good way to remove && and check validness of variables. But there are many pitfalls we have to avoid. These things are important but cannot be easily found in other documentations.

I think it's good for us and other future developers.

[aduth]

@sainthkh For sure, I think it makes sense to be be documenting these. I'd actually planned to bring some of these up in next week's JavaScript chat, moreso as observations of common issues people may encounter, but documentation is a good action item. I think we're still so early on in its usage that we're still at a point of identifying these issues. That said, the coding guidelines are always a "working document" and be revised over time.

As with the other discussion, I think we'll ultimately want to come to rely on our tooling:

• Need an ESLint rule that restricts optional chaining with negation. #21984 is a good example where ESLint can alert us against potential errors.
• This is a good example where TypeScript type checking can alert us about assigning an invalid type (a non-boolean)†

† Aside: I actually tried to test this in code by adding @ts-check to the top of the file, and it didn't exactly work as I expected. Not sure if it's an issue with JavaScript typing, with typing of useRef, or other. Maybe something we need to figure out in the future, or if it's an upstream issue, to wait for a fix.

[aduth]

I created a pull request at #22029 to document the two gotchas observed here.