-
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
Edit Site: Refactor to remove usage of edited entity state #66922
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. |
__( 'Delete template part: %s' ), | ||
decodeEntities( template.title ) | ||
); | ||
commands.push( { |
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 command comes with its own challenges: Knowing where to redirect the editor after deletion (an information we don't have in the editor package for now), so I'm removing it because it felt to me like a really not that useful command and if we were to implement it, it would be good to support it in all editors.
The good thing with this PR is that "edit template" and "go back" commands work both in the site and post editors. |
Size Change: +558 B (+0.03%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
Flaky tests detected in a9f5a13. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11794122186
|
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.
The changes look good, and Commands are working as before ✅
Also, since the Site Editor router is URL query-based, is there a plan to ship a helper hook to avoid prop-drilling in some cases?
I actually think prop drilling is fine :P but yeah depending how it goes, I feel like the site editor will be just a small wrapper of components that would consume params from. |
In my opinion, it depends on the drilling level :) |
Related #66921
What?
As the site editor is growing to become a multi page app, it doesn't really make sense to have an edited post type and context state in it.
That state is forcing us today to have a two synchronization mechanism between the url and the state causing some issues related to performance and some hidden bugs at times.
Ideally the routes would just pass the post type, post id to the editor component. The current PR helps to go in that direction by moving some generic commands into the editor package.
Testing Instructions