Premium Analytics: register widget-modules entity in the init module - #50048
Premium Analytics: register widget-modules entity in the init module#50048Nikschavan wants to merge 5 commits into
Conversation
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
There was a problem hiding this comment.
Pull request overview
This PR moves the one-time widgetModule core-data entity registration out of the dashboard route lifecycle and into the Premium Analytics page init module so it runs once at app boot, while also centralizing the jetpack/v4 REST namespace literal in the data package to avoid duplication.
Changes:
- Register the
widgetModuleroot entity frompackages/initduringinit()(idempotency-guarded). - Remove entity registration from the dashboard route
beforeLoad, leaving it focused on connection/sync guards and date seeding. - Define and export
DASHBOARD_REST_NAMESPACEfrompackages/dataand re-export it from the dashboard hooks constants.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| projects/packages/premium-analytics/routes/dashboard/route.ts | Removes per-navigation entity registration and updates route doc-comment accordingly. |
| projects/packages/premium-analytics/routes/dashboard/hooks/constants.ts | Re-exports DASHBOARD_REST_NAMESPACE from the data package to avoid duplicating the literal. |
| projects/packages/premium-analytics/packages/init/src/index.ts | Registers the widget-modules entity once at boot from init(). |
| projects/packages/premium-analytics/packages/init/package.json | Adds dependencies needed for boot-time registration (core-data, i18n, data). |
| projects/packages/premium-analytics/packages/data/src/index.ts | Re-exports DASHBOARD_REST_NAMESPACE from the data package entrypoint. |
| projects/packages/premium-analytics/packages/data/src/api/constants.ts | Introduces DASHBOARD_REST_NAMESPACE constant as the JS source of truth for jetpack/v4. |
| projects/packages/premium-analytics/changelog/add-pa-widget-modules-init | Adds changelog entry for the behavior-preserving bootstrap move. |
e19a0d0 to
9b543c4
Compare
ef956ca to
78c91c3
Compare
78c91c3 to
5012ecc
Compare
retrofox
left a comment
There was a problem hiding this comment.
I'm having issues with the boot package. It never loads the dashboard init module, so it doesn't register the entity; as a result, all widgets show the uploading state.
Does it work for you?
Move the one-time core-data widgetModule entity registration out of the dashboard route's beforeLoad and into the page init module, so it runs once at app boot instead of on every navigation/preload. The jetpack/v4 REST namespace now has a single source of truth in the data package (DASHBOARD_REST_NAMESPACE), shared by the dashboard route hooks and the init-module registration. Addresses retrofox's review note on #49572.
…ce re-export Drop the boot-once idempotency guard in registerWidgetModulesEntity and destructure addEntities directly. Remove the DASHBOARD_REST_NAMESPACE re-export from the dashboard hooks' constants; the two layout hooks now import it directly from @jetpack-premium-analytics/data, the single source of truth, matching how the init module and the rest of routes/ consume it.
Re-add the getEntityConfig existence check before addEntities, matching the upstream @wordpress/dashboard-init pattern so a pre-existing registration (e.g. from core's dashboard-init) isn't duplicated. Reword the changelog to drop lifecycle jargon.
…ter trunk merge The trunk merge brought in routes/post-detail/route.ts (#50096), which imported DASHBOARD_REST_NAMESPACE from ../dashboard/hooks/constants. This branch moved that constant's single source of truth into @jetpack-premium-analytics/data, so the old export no longer exists and esbuild failed. Point the import at the data package, matching every other importer (init, use-dashboard-layout, use-dashboard-section-layout).
5d5e349 to
0887df2
Compare
|
Now that the @wordpress/* dependencies are updated, this PR is ready for a code review! |
It doesn't work when the Gutenberg plugin isn't activated. Although the issue doesn't belong to this PR, I suggest holding off until a fix is in place before landing this one. Working on it. |
Proposed changes
Follow-up to retrofox's review note on #49572: move the one-time
widgetModulecore-data entity registration out of the dashboard route'sbeforeLoadand into the pageinitmodule, so it runs once at app boot instead of on every navigation/preload.packages/init/src/index.tsnow registers thewidgetModuleroot entity frominit()(which@wordpress/buildruns once at boot, before routes render), alongside the existingsetupApiFetch()and menu update. The idempotency guard is kept (harmless, in caseinit()ever re-runs on re-mount/HMR).routes/dashboard/route.tsbeforeLoadno longer registers the entity — it's left doing only the connection/sync guards and the date seed. The stale doc-comment paragraph that flagged this as a tracked follow-up is updated to reflect reality.jetpack/v4REST namespace literal now has a single source of truth in the data package (DASHBOARD_REST_NAMESPACEinpackages/data/src/api/constants.ts, re-exported from the package index). The dashboard route hooks and the init module both import it — so the route folder isn't imported frominit, and the literal isn't duplicated.@wordpress/core-data,@wordpress/i18n, and@jetpack-premium-analytics/datatopackages/init/package.json(matching the versions used elsewhere in the package on trunk). The entity guard/registration callsselect( coreStore ).getEntityConfig()anddispatch( coreStore ).addEntities()against the real core-data types directly, no local casts.This is a behavior-preserving move: the same entity is registered, just once at boot rather than re-checked on every
beforeLoadrun.Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
pnpm run buildinprojects/packages/premium-analytics(under Node 24).?page=jetpack-premium-analytics) on a connected, synced site.widgetModuleentity is now registered at boot viainit(), souseWidgetTypes/ the stage'sgetEntityRecordsread resolves exactly as before.beforeLoad.[Status] Needs Review