Interface: don't persist default complementary area on load#67515
Interface: don't persist default complementary area on load#67515ellatrix wants to merge 1 commit into
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. |
| } else if ( isSmall ) { | ||
| disableComplementaryArea( ...args ); | ||
| } | ||
| } |
There was a problem hiding this comment.
I saw this is originally from #22381, @jorgefilipecosta
There was a problem hiding this comment.
Looking at this again, I wonder if it's a good idea for the component to have this kind of logic.
It'd probably simplify things if the component only had to be aware of whether it was active or not, and instead the editor packages controlled showing it by default.
I guess it's a stable API now so it's probably not something that can be simplified.
| */ | ||
| export const enableComplementaryArea = | ||
| ( scope, area ) => | ||
| ( scope, area, { persist = true } = {} ) => |
There was a problem hiding this comment.
Alternatively we could add a private action if we don't want to expose this option.
|
Size Change: +69 B (0%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
| const isComplementaryAreaVisible = registry | ||
| .select( preferencesStore ) | ||
| .get( scope, 'isComplementaryAreaVisible' ); | ||
| if ( persist ) { |
There was a problem hiding this comment.
I think a problem is the preferences store won't be set to the correct value for isComplementaryAreaVisible when persist is false. Users who visit for the first time continue to have undefined as the isComplementaryAreaVisible preference, so the isActiveByDefault isn't being respected. The getActiveComplementaryArea selector seems to return the preference store value in an early return, so I think it won't be returning the intended value.
IIRC, the main use case for isActiveByDefault is for those first time visitors.
Revisiting this, I'm wondering why a default preference value for isComplementaryAreaVisible isn't being set that corresponds to isActiveByDefault:
gutenberg/packages/edit-site/src/index.js
Lines 64 to 77 in fa636dc
That seems like it'd work well for the first time visitors and it doesn't trigger any API requests. The name of the default area still has to be set in the interface store.
Another curiosity is the way the interface package has a setDefaultComplementaryArea action, but it seems unused from what I can tell. Probably for back compat. Makes me wonder if it can be used for this. 🤷
What?
Related: #40923
The interface package currently seems to persist enabling/disabling the default complementary area on load. This shouldn't happen unless there was a user action. Simply being the default is not a user action.
Why?
There should be no such requests on editor load.
How?
Add an option to not persist.
Testing Instructions
It is best tested using the e2e test. When opening the editor page without any preferences set, there should be no POST request to
/wp/v2/users/me