-
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
[RNMobile] Set and reference heading anchors #27935
[RNMobile] Set and reference heading anchors #27935
Conversation
d1418d4
to
d79c73a
Compare
👋 David! May I suggest changing the "prefix" in the PR title to |
@hypest I do not have permissions to manage the reviewers list. After consideration, including four members is likely unnecessary. Would you please update the reviewers to list to be @ceyhun and @talldan please? @ceyhun would you please review that my implementation works as expected and is a sound approach? @talldan would you be willing to review my work to ensure my implementation does not disrupt any web experiences or violate any general project coding practices? |
455a9ca
to
2d4c648
Compare
@dcalhoun Thanks for the ping. I tested this and on the web I'm seeing two way to set an anchor on the heading block now: The UI for the anchor in the advanced section is added to some blocks by the
And the code that picks up that setting and adds the UI is here (added using filters): gutenberg/packages/block-editor/src/hooks/anchor.js Lines 64 to 113 in e1c3dcf
I think if you're looking to add anchor support on mobile, you'd probably want to use the same system to ensure it automatically works across all blocks that support the anchor setting. |
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.
Just saw the comment from Daniel. I guess the mobile implementation will be different from the web one, so I think it makes sense to review and test after that change. Feel free to ping me again 🙇
Aha, nice find there Daniel!
👋 @dcalhoun , just wanted to add that in terms of scope, it'd be cool if we can limit to the heading block for now, but still have an implementation that lends itself to expanding to other blocks. That said, I'm not sure if that'd be more practical or quicker than just go for all blocks as Daniel mentions, but if we can break up the scope in such a way that we land things in separate PRs it can help with moving forward in a nice pace. Thanks! |
Indeed. Thank you for reviewing, Daniel. You have opened my eyes to a much wider view of the code base and it's incredibly helpful.
@hypest whether it is more or less work to scope enabling anchors for headings will likely depend upon the response to my questions for Thomas. If we is OK with using a generic heading for the bottom sheet, then enabling anchor hook for all blocks will likely "just work out of the box." That said, I can go ahead and execute enabling anchors for Heading blocks only to sustain project momentum. |
f653167
to
61a2168
Compare
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.
Things look good from a web point of view. Happy for someone more familiar with mobile to do a test there and give the final thumbs up 👍.
</InspectorAdvancedControls> | ||
) } | ||
{ ! isWeb && props.name === 'core/heading' && ( | ||
<InspectorControls> |
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.
At some point it would be cool to look at supporting InspectorAdvancedControls
on mobile (guess it's not rendered anywhere at the moment though).
There are a few other things that tend to be rendered in this panel/slot on the web, the main other item is the Custom Class Name field (https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/hooks/custom-class-name.js):
Those things could always be prevented from rendering on mobile in the same way you have here if you want a more gradual roll-out.
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 agree. Ideally we reuse InspectorAdvancedControls
for mobile once we have a design for displaying its entirety. Thomas and I had a discussion about the "Advanced" section, but opted to target only the anchor input for the initial implementation.
) } | ||
{ ! isWeb && props.name === 'core/heading' && ( | ||
<InspectorControls> | ||
<PanelBody title={ __( 'Heading settings' ) }> |
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.
'Heading settings' might not be very scalable for the future, as other features that get added to the block inspector for Heading can't be put inside this panel. There's no way to access it from the Block's edit function.
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.
Agreed, we'll need a more scalable heading in the future. Thomas requested that we use the "Heading settings" title for the time being.
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.
Thomas requested
My comment below is actually covering the process here too, thanks!
{ textControl } | ||
</InspectorAdvancedControls> | ||
) } | ||
{ ! isWeb && props.name === 'core/heading' && ( |
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.
Is there a plan to remove the restriction to just the one block?
I'd hope that as long as TextControl
works well on mobile, it should be fairly straightforward to support this on all blocks that declare support for an HTML Anchor.
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.
Yes, I believe the plan is to implement other blocks in the future. For the time being, Thomas and Stefanos requested that we scope the work to Heading blocks.
From my testing, you are correct that wider anchor support is straightforward.
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.
requested
Just a quick note on the process, as "requested" doesn't represent it very well: The way we work, at least on the native mobile apps, we make sure people collaborate by sharing information and context to design/implement solutions, including carving out the plan to get there.
We try to keep PR scope to the minimum so we can move and land land them in small but predictable steps (even if, say, landing means merging to a feature branch). We re-evaluate our plans as we go, when new info arises, like for example when we understand scope is actually too big for a single PR.
In our case here with the anchor feature, limiting to just the "Heading" block helps us pin down the implementation on mobile, add value by shipping the feature to the users, all while we making plans for the next steps.
Hope this helps, thanks!
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.
@hypest thank you for the feedback and context.
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.
Maybe we can add a comment here linking the issue where we plan to implement InspectorAdvancedControls
and/or enable anchors for all the other blocks?
@@ -394,7 +394,7 @@ Undocumented declaration. | |||
|
|||
_Related_ | |||
|
|||
- <https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-controls-advanced/README.md> | |||
- <https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-advanced-controls/README.md> |
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.
good catch!
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.
Sorry for the late review @dcalhoun, it LGTM 👍 Tested on iOS and Android and everything is working as expected. Thanks!
{ textControl } | ||
</InspectorAdvancedControls> | ||
) } | ||
{ ! isWeb && props.name === 'core/heading' && ( |
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.
Maybe we can add a comment here linking the issue where we plan to implement InspectorAdvancedControls
and/or enable anchors for all the other blocks?
Address design feedback.
Previous approach ignored web implementation and resulted in double anchor controls for web editor. This leverages the existing anchor hook to fix the issue and share more code.
Address code review feedback.
61a2168
to
3be82b7
Compare
@ceyhun thank you for the review. I pushed a new commit to address your feedback. I believe this PR is ready to merge. I do not have the privileges required to rerun the failing CI tests or merge the PR. Would you be willing to help me do that please? |
I restarted the |
Description
Address wordpress-mobile/gutenberg-mobile#1816 by adding the ability to set and reference Heading block anchors
WordPress iOS: [Gutenberg] Set and reference heading anchors wordpress-mobile/WordPress-iOS#15567WordPress Android: [Gutenberg] Set and reference heading anchors wordpress-mobile/WordPress-Android#13705How has this been tested?
earlier step.
Outcome: Browser should scroll to Heading anchor.
Screenshots
UI Examples
Types of changes
New feature (non-breaking change which adds functionality)
Checklist