-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Ensure that openref is defined before accessing to .current #62508
Ensure that openref is defined before accessing to .current #62508
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
c069148
to
d99d934
Compare
If this PR makes sense, it would be great if it could be backported to WordPress 6.6 🙇 |
@@ -40,7 +40,7 @@ export function useInBetweenInserter() { | |||
} | |||
|
|||
function onMouseMove( event ) { | |||
if ( openRef.current ) { | |||
if ( openRef === undefined || openRef.current ) { |
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 think this would work too.
if ( openRef === undefined || openRef.current ) { | |
if ( openRef?.current ) { |
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.
It was my first commit :D
However, with this code, the function will not return at line 44, but will continue with the logic.
BTW, I don't have a strong opinion! What do you think?
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.
These are different checks:
- The proposed logic in the PR is bail on
openRef === undefined
OR ifopenRef.current
is truthy, which I'm not sure is correct. - @cbravobernal's suggestion bails on openRef truthy, but
openRef === undefined
keeps going.
@gigitux Could you explain why the handler should bail on openRef === undefined
?
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.
It was my first commit :D
However, with this code, the function will not return at line 44, but will continue with the logic.
BTW, I don't have a strong opinion! What do you think?
Agh, we made the same mistake then 😆
Return means not showing the in-between inserter. openRef seems to be a reference of where the next block should be insterted.
So, if the reference of the next position to be insterted does not exist (is undefined), the indicator should be hidden.
PD: I cannot get openRef.current
to return true while testing on a post editor.
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.
@vcanales Good point! Thanks for clarifying this! My first intuition was the right one. Sometimes overthinking isn't a good idea 😅
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.
Oh now I understand, thanks for the explanation @cbravobernal
@gigitux I think openRef === undefined || openRef.current
is the correct check, since we don't want to show the inserter when the next ref is undefined.
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.
This is from where I understood that returning is hiding the inserter btw:
gutenberg/packages/block-editor/src/components/block-list/use-in-between-inserter.js
Line 132 in 2d34e2a
// Don't show the inserter when hovering above (conflicts with |
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.
Could I ask you to also add a comment to the handler explaining its flow a little bit?
@cbravobernal's comment explains part of why we're returning early, but I still find it hard to grasp at a glance by just looking at the code
Return means not showing the in-between inserter. openRef seems to be a reference of where the next block should be insterted.
So, if the reference of the next position to be insterted does not exist (is undefined), the indicator should be hidden.
8dd228f
to
d99d934
Compare
Some clarifications: it looks like this handler is used to render the inserter between blocks. This is the default behavior: Screen.Capture.on.2024-06-12.at.15-35-01.mp4This is the behavior if I define the openRef as true. The inserter between blocks isn't rendered: Screen.Capture.on.2024-06-12.at.15-35-27.mp4Now, this hook works only if the component is inside the I added a comment with this commit 2ea0e3e, but I'm open to feedback. Thanks for the review and help! 🙇 |
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.
Looks good. Thanks for illustrating and documenting too!
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.
Thanks for the clarification @gigitux !
…s#62508) * Ensure that openref is defined before accessing to .current * add comment Co-authored-by: gigitux <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: vcanales <[email protected]>
* Ensure that openref is defined before accessing to .current * add comment Co-authored-by: gigitux <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: vcanales <[email protected]>
* Ensure that openref is defined before accessing to .current * add comment Co-authored-by: gigitux <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: vcanales <[email protected]>
I just cherry-picked this PR to the wp/6.6-beta-3 branch to get it included in the next release: 49cc18e |
* Ensure that openref is defined before accessing to .current * add comment Co-authored-by: gigitux <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: vcanales <[email protected]>
What?
This PR improves a check to ensure that JS errors aren't triggered. You can see more details at: woocommerce/woocommerce#48308
Why?
By default, InsertionPointOpenRef is defined as an empty context in Gutenberg. You can find the context definition here.
When Gutenberg is used as a framework, the BlockTools component (that defined the context) may not be utilized in some projects (e.g., Customize Your Store project). In such cases, JavaScript will throw an error at the following line: use-in-between-inserter.js#L43.
To prevent this error, we need to update the check for InsertionPointOpenRef to handle scenarios where the context isn't defined. This PR will ensure that the context is defined, avoiding runtime errors.