Repository navigation
Conversation
talldan
added
[Type] Enhancement
talldan
requested review from
ajitbohra,
ellatrix,
juanmaguitar,
mkaz,
nerrad and
ryanwelcher
as code owners
March 22, 2022 09:33
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
March 22, 2022 09:36
ff58d97 to
6598078
Compare
15 of 18 tasks
|
Size Change: +585 B (+0.03%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
Contributor
Author
|
Looks like there are some failing tests - some more unit tests that need various mocks in place now that they touch the preferences store. I'll update those tomorrow. |
talldan
commented
Mar 23, 2022
Contributor
Author
|
There's a discussion in #39672 (comment) about whether |
tellthemachines
left a comment
tellthemachines
left a comment
Contributor
There was a problem hiding this comment.
Tested and all works well, both migrating usage from trunk and persisting new usage ✅
possibly a bug that the order of blocks update while the inserter is open
If it is a bug, it's a very fun one 😄
Couple questions below, code looks good otherwise.
tellthemachines
previously approved these changes
Mar 25, 2022
Contributor
Author
|
Thanks for the review! I'll hold off on merging this and switch it to a draft until this conversation about adding preferences as a dependency of block-editor (#39672 (comment)) is resolved. |
talldan
marked this pull request as draft
March 25, 2022 05:14
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
April 5, 2022 06:26
dd14c00 to
35c4e0c
Compare
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
April 28, 2022 07:04
35c4e0c to
6e3679b
Compare
Contributor
Author
|
Status update on this one, this conversation is very relevant to this PR - #39795 (comment). Now that preferences are saved via the REST API, merging this would mean that every block insert would result in an API request, which is probably undesirable. I'm going to be AFK for a month so won't be able to solve this one quickly, but happy to look at it when I return. |
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
October 13, 2022 03:30
6e3679b to
6d99419
Compare
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
March 28, 2023 06:45
6d99419 to
9cc9e08
Compare
Contributor
Author
|
edit: As of mid July 2024, I've started working on this again. |
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
4 times, most recently
from
July 15, 2024 06:48
3d066cf to
6eb84df
Compare
Update tests Make updateInsertUsage a proper action that can be unit tested Fix reusable block tests Update test Try fixing private actions with new store registration Update tests Add special handling for the insertUsage migration as it was performed later than others Remove unused function Add mark next change as expensive action to preferences store Update debounce function to handle a longer debounce for expensive changes Mark the insertUsage preference change as expensive Make expensive calls use a trailing edge debounce Fix duplicate keys in tests Improve trailing edge test Fix tests, and ensure options object is optional Make updateInsertUsage a private API Make markNextChangeAsExpensive a private API Update docs Update package-lock Opt-in preferences as a core module using private apis Do not unlock what is already unlocked Remove time property from INSERT_BLOCKS and REPLACE_BLOCKS action objects Rename `match` to `variation` Rename file to create-async-debouncer Add an extra param for defining the debounce of expensive requests Add a default value of `false` for the `isExpensive` option Make `__unstableGetInsertUsage` a private selector called `getInsertUsage`. Remove `__unstableGetInsertUsageForBlock` Only run the migration when needed Keep the `insertUsage` data at a maximum of 100 records Fix linting issues Update docs
talldan
force-pushed
the
migrate/block-editor-insert-usage-to-preferences-store
branch
from
July 18, 2024 02:56
8f3f287 to
152c653
Compare
Contributor
Author
|
The changes to debouncing caused some interesting issues in e2e tests. A couple of e2e tests use the preferences API to set up a test state ( Instead I've switched to It also looks like preferences state is only ever reset at the start of running an entire test suite, not before individual files or test cases, so there can be lingering preferences state. Surprisingly it doesn't cause that many issues. 🤔 |
talldan
commented
Jul 18, 2024
Comment on lines
+42
to
+44
| await editor.setPreferences( 'core/edit-site', { | ||
| welcomeGuide: false, | ||
| } ); |
Contributor
Author
There was a problem hiding this comment.
This test actually fails in trunk if you run it locally. It only passes in CI in trunk because other tests that run before it set welcomeGuide to false 😬
I'm not sure why it started failing on CI in this PR.
Member
|
I think the mentioned end-to-end tests are flaky even on trunk. States like "Fixed Toolbar" can persist between tests, causing follow-up tests to fail. I'll try to make them more resilient separately, which should help partially unblock this. It would be nice to resume work on this PR, the |
Contributor
Author
Yeah, I'd love to get this across the line. Maybe once 6.9 stuff is out of the way I can picked it up again. |
This was referenced Oct 14, 2026
Merged
Member
|
Should we refresh this PR? But after #85036 please? |
🤖 PR meta 🤖🎉 PropsIf 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. Updated as activity occurs, without notifying anyone named here. Add the |
Member
|
@manzoorwanijk, I'll try to pick this up; it will be easier once the TS refactoring for the block editor package lands. |
Member
This is now unblocked |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #31965
What?
The block editor package maintains some block insertion data to aid the 'Most used blocks' feature in the inserter. It persists this data.
This PR migrates the data to the preferences store.
Why?
As outlined in #31965, the goal is to move persisted data out of our various stores to a centralized preferences store.
How?
This required adding the preferences store as a dependency of the block editor package.The logic in the block editor's
preferencesreducer is now moved over to a new actionupdateInsertUsagethat uses the preferences store. This new private action is dispatched in theinsertBlocksandreplaceBlocksactions.The local storage data is migrated across to live under the preferences store from the old preferences system.
The preferences store's API usually uses a
scopeparameter that's usually set to 'core/edit-post' or 'core/edit-site', to indicate which editor the data belongs to.insertUsagestats are shared across editors, so I've used the 'core' scope.Finally, this PR introduces a new private action in the preferences store,
markNextChangeAsExpensive, which can be dispatched before updating a preference to delay the regularity with which the persistence layer makes HTTP requests to update user meta. It means you can insert loads of blocks quickly, but user meta will only update after a minute has passed. Insert usage still backs up immediately to a local storage persistence layer, so there's lots of resilience.Testing Instructions
trunkopen the post editor