-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Open convert to links modal on select of a page item #48723
Conversation
Size Change: +136 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
c6786e3
to
af57fe2
Compare
af57fe2
to
e9bcf96
Compare
Is there any way that we can pass the information needed for |
I wonder if we can have an |
@ajlende not really. I tried before this approach using the onChange prop of the innerblocks and simulate a fake change via setAttributes see f596d2e but it's clunky to say the least. Because we don't render the page list items individually I can't pass a handler for some of the stuff they do. However I think the approach here is quite OK. What is wrong with relying on the dragged state of an inner block? |
I don't like that we have to rely on a It feels too much like a hack, I guess. |
I don't feel it is a hack to have a block act on how its children change in UI state. I feel more like the animation API is lacking a good enough implementation so that it can be canceled. I think the To that effect - no pun intended - maybe so that we're both happy half way I should just copy the modal and the conversion function into the page list item too (for now) and move the logic to the page list item block out of the page list block. That way, we wouldn't care about parents and children, and would render the modal in the page list item block. I'll try this in a new commit to see how complicated it would be. The modal would still not be self contained because we need to render it when either one of isSelected or isDragged are true, not following some event, but following a state change. |
Absolutely - I even tried to make it happen, doesn't work yet :D EDIT: Now I see what you mean @jasmussen - after the conversion. That is a problem in |
Agreed. |
Looking good @draganescu! Should the modal appear on item drop rather then drag? Shouldn't block releasing this but might be a follow up refinement if we think it makes sense. |
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 still find it wrong that we have these hasSelectedInnerBlock
and hasDraggedInnerBlock
functions, but it may be a limitation of the system we have for passing data down to inner blocks.
Approving because there is good value being added in this change, and doing it in what I would consider to be the "right" way would likely involve modifying the system for inner blocks.
}; | ||
}, | ||
[ clientId ] | ||
); | ||
|
||
const innerBlocksProps = useInnerBlocksProps( blockProps, { |
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.
@draganescu and I looked into passing the convertToNavigationLinks
function down into the child block where the modal could be opened from there, but we couldn't find where the props ended up since they didn't get added to the edit
props.
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 option could have been creating a context just for this scenario that the data needed in the child could have access to, but that also seems a little convoluted.
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.
Do you think it's worth looking into modifying the system for inner blocks?
I'm tentatively removing backport label for this PR. While it's an excellent enhancement, I don't think we have enough time to properly test and follow up with any fixes if required during this release cycle. |
* | ||
* @return {boolean} Whether the block has an inner block dragged | ||
*/ | ||
export function hasDraggedInnerBlock( state, clientId, deep = false ) { |
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.
We can also do this inline in the useSelect
callback and avoid introducing a new selector for just one use case.
Here's a similar example:
gutenberg/packages/edit-site/src/components/save-button/index.js
Lines 23 to 25 in d19dbd6
isSaving: dirtyEntityRecords.some( ( record ) => | |
isSavingEntityRecord( record.kind, record.name, record.key ) | |
), |
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 want this new selector, it's as useful as hasSelectedInnerBlock
and this is a perfect opportunity to introduce it via using it.
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 sharing my personal preference of avoiding adding selector to packages scope, when I can :)
What?
When users interact with the Page List Items in the Navigation List View, we should invoke the "convert to links" modal, to make it clear that these items can't be edited.
Questions
cc @SaxonF @richtabor
Fixes #47064
Why?
To make it clear that these items can't be edited, and allow users to do so.
How?
By using the onChange prop of
innerBlocks
in the page list template and simulating a change viasetAttributtes
. A cleaner way may exist.Testing Instructions
Testing Instructions for Keyboard
As above.
Screenshots or screencast
convert-on-interaction.mp4