-
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
Fix Synced Patterns non-overridden content being editable in write mode #66949
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3071,6 +3071,10 @@ export const getBlockEditingMode = createRegistrySelector( | |
return 'disabled'; | ||
} | ||
|
||
if ( state?.patternBlockEditingModes?.has( clientId ) ) { | ||
return state?.patternBlockEditingModes.get( clientId ); | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I find odd is that the denormalization only applies in the case of the "pattern block editing modes", why not just make a global state.blockEditingModes ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see you mentioned in the description that you have follow-up for "zoom-out" editing modes too. I think we should ideally just have the selector return directly the state value in the end, but I'm ok with going in steps. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One challenge is going to be that the selector depends on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, it's a tricky one. In the case of switching from design to write mode, we don't need to recalculate every pattern block, so storing it separately is useful in that case, we can retain the info across editor mode switches. Similarly, we need to retain back compat for the block editing modes that might be set via There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. oh yes, I mistakenly used the same name, we do need this to be separate from the original There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
My other PR does handle this by dispatching an action for switching editor mode to ensure the reducer re-runs: but it still reads the mode from the preferences store: I'm not sure if this is the best approach. The reducer also needs access to the |
||
|
||
const editorMode = __unstableGetEditorMode( state ); | ||
if ( editorMode === 'navigation' ) { | ||
const sectionRootClientId = getSectionRootClientId( state ); | ||
|
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 this is the kind of code that deserves some unit testing?
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 can do, though I think the other PR (#66919) shows that unit testing only the reducer or only the selectors isn't a great approach. That PR is a refactor, the store as a whole should be working the same, but I'll have to rewrite all the tests, which is a lot of work and could introduce some margin of error.
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 should also add some e2e tests.