Refactor Link UI controls with better props#71515
Conversation
- Change canCreatePage to canAddPage for consistency - Change blockEditingMode to canAddBlock for consistency - Update LinkUITools to use new prop names - Remove conditional rendering logic from renderControlBottom
|
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. |
|
Size Change: +13 B (0%) Total Size: 1.93 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 5e2d857. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17490182227
|
| focusAddPageButton, | ||
| canCreatePage, | ||
| blockEditingMode, | ||
| canAddPage, |
There was a problem hiding this comment.
Consistency with the other one and to distinguish it from the idea of permissions being the only thing that that is regulating the display.
scruffian
left a comment
There was a problem hiding this comment.
Looks good. Not sure about the change in the prop name.
Cherry-picked from #71137
The main purpose is to make it clearer what factors govern the rendering of the Add block and Add page buttons. The component itself shouldn't decide this, it should be simple.
Previously there was a mix where
<LinkUITools>did some of the decision logic internally (i.e. viablockEditingMode) prop and some of it was passed in as props (i.e.canCreatePage).This change standardises the approach.