Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Editor: LinkControl: Prevent focus loss in edit mode toggle #19931
Block Editor: LinkControl: Prevent focus loss in edit mode toggle #19931
Changes from 2 commits
238ee29
5b72b3a
0d6bf78
eb8cac7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess as of #19831 I could simplify this using optional chaining:
What's interesting to me is looking at the other, negated instance of this condition, I sense there's going to be a very common pitfall associated with optional chaining:
gutenberg/packages/block-editor/src/components/link-control/index.js
Lines 112 to 113 in 5b72b3a
If someone treats optional chaining as a way to get to the value by any means necessary, it might be easy to overlook that negating would produce
true
if the optional chaining aborts early:😯 It's definitely not the expected result.
It seems like in the same category of issues we restrict with this ESLint rule:
https://eslint.org/docs/rules/no-unsafe-negation
I could imagine some improvement to that rule which forbids negation of optional chains.
cc @gziolo @sainthkh (more an FYI, as it was interesting to me)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another interesting pitfall: If you're expecting a boolean out of a value or function result at the end of an optional chain, you might be surprised to find that a non-boolean can be assigned if the chain aborts early, since it will evaluate to the value at the point at which it aborted.
This is similar to what can happen when using
&&
, where if the left-hand is falsy, the expression doesn't evaluate to an explicitfalse
, but rather to the left-hand value.You may have run into this one before 😄 https://codepen.io/aduth/pen/dWwzrL
It's not often a problem as long as the developer proceeds to use the value in a way which considers it as truthy or falsy, but it could be important to consider for satisfying function contracts, where we'd want to be considerate to adhere to the expected types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very interesting case, thanks for sharing. To make it more interesting, let me share a bit different example which in the different context might also produce an unexpected result:
It's always a challenge to make such checks work as intended. The only answer is to learn JavaScript deeply or cover code with tests 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I just now observe that the same
&&
applies to the current proposed implementation, at least if the expectation is that it would always assign a boolean, that's not currently happening (it can assignundefined
).