-
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
Off Canvas Navigation Editor: Add Convert To Links Modal #45984
Conversation
It was easier to nuke the commit history than to manually sync a bunch of commits, so this is all the commits in the branch squashed
Open in CodeSandbox Web Editor | VS Code | VS Code Insiders |
Size Change: -1.47 kB (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
It was easier to nuke the commit history than to manually sync a bunch of commits, so this is all the commits in the branch squashed
47d7381
to
5bd0cfc
Compare
Thanks for working on this. When I convert to links, none of the links have pencil icons next to them, so I can't edit them, unlike in trunk. |
…ordPress/gutenberg into add/navigation-off-canvas-edit
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.
Thank you for working on this.
Some things I noticed...
packages/edit-site/src/components/sidebar-edit-mode/navigation-item-editor/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/off-canvas-editor/block-edit-button.js
Show resolved
Hide resolved
packages/block-editor/src/components/off-canvas-editor/block-edit-button.js
Outdated
Show resolved
Hide resolved
Conflicts: packages/block-editor/src/components/off-canvas-editor/block-edit-button.js
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 merged in trunk because rebasing was difficult and it's easier to undo a merge commit if something didn't go as expected. That being said, this is testing well for me.
I think since this PR was opened, there were changes to showing only a submenu for the page list block, and that case isn't handled by this change.
I think we can add a follow-up to fix that and get this one merged.
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 don't feel this is ready to merge so prematurely submitting this blocking review. Will follow up with specifics
const { getSettings } = select( blockEditorStore ); | ||
|
||
return { | ||
pages: getSettings().__experimentalFetchPageEntities( { |
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'll need to test whether __experimentalFetchPageEntities
is defined before attempting to utilise 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.
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.
Thank you for continuing to iterate on this 🙏
My main concerns are that
- it doesn't work in the Post Editor
- we're tightly coupling components making future refactoring much harder
Let's try and address those before we merge this. Sorry to be a blocker here but I think it's important.
Much appreciated 🙇
storedSettings, | ||
blockPatterns, | ||
blockPatternCategories, | ||
fetchPagesEntities, |
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 there's a chance this might cause a perf problem because fetchPagesEntities
is always a new function reference?
I'm hoping the fact that useSelect
has []
as deps means it will only run once and thus fetchPagesEntities
will remain a consistent reference but if that's not true then it will cause problems as the useMemo
will be invalidated for the entire editor settings.
const { getSettings } = select( blockEditorStore ); | ||
|
||
return { | ||
pages: getSettings().__experimentalFetchPageEntities( { |
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.
</Modal> | ||
); | ||
}; | ||
|
||
export default forwardRef( function BlockEditButton( |
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.
In general I feel the BlockEditButton
is now doing too much and has awareness of too many concepts.
Ideally these components need to stay as close to those in the canonical <ListView>
as possible. This will make our lives much easier if we try to normalise them in the future.
To this end I think we should consider
- moving
<ConvertToLinksModal>
modal to it's own file - extracting all pages logic to a custom hook
- passing the requisite callbacks down into
BlockEditButton
as required.
We'll still be coupling concepts like Pages to the block editor package (not good) but at least it will be easier to extract and refactor in future.
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.
Please take a look at the refactored version and let me know what you think. Moving usePageData
and ConvertToLinksModal
to their own files and lifting the onClick
handler made the button small enough to make it irrelevant.
// Performance of Navigation Links is not good past this value. | ||
const MAX_PAGE_COUNT = 100; | ||
|
||
const usePageData = () => { |
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.
Let's move this to its own file.
}; | ||
|
||
// copied from convert-to-links-modal.js | ||
const convertSelectedBlockToNavigationLinks = |
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.
Let's move this to it's own file. All the more reason to do so in order to keep in sync with convert-to-links-modal.js
}, [ pages ] ); | ||
}; | ||
|
||
// copied from convert-to-links-modal.js |
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.
Please can we have the full file path? 🙏
replaceBlock( clientId, navigationLinks ); | ||
}; | ||
|
||
const ConvertToLinksModal = ( { onClose, clientId, pages } ) => { |
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.
If this is copied from somewhere can we have a comment to specific exactly where? 🙏
if ( allowConvertToLinks ) { | ||
setConvertModalOpen( ! convertModalOpen ); | ||
} else { | ||
selectBlock( clientId ); | ||
} |
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 don't think this component should know anything about this concept. Lets lift this up and pass down as a prop. Perhaps if the onClick
prop is defined then call that, else default to selectBlock
?
{ convertModalOpen && ( | ||
<ConvertToLinksModal | ||
onClose={ () => setConvertModalOpen( false ) } | ||
clientId={ clientId } | ||
pages={ pages } | ||
/> | ||
) } |
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 could be lifted up. I don't think it needs to "live" with the edit button.
@georgeh I think we should consider a simpler approach. I've outlined the reasons why I think that one might be preferable in the PR description. Let us know what you think? 🙇 |
I think that now #46352 is merged we can close this. Feel free to reopen if you think we still need it. |
What?
Screen.Recording.2022-11-22.at.7.26.33.PM.mov
Why?
When editing navigation, editing a page list will prompt converting to links. This is revisiting the work from #45575 and addresses #45442
How?
Testing Instructions
Screenshots or screencast