Migrate plugin dashboard to use Widgets API infrastructure

Feature Description

After #1300, we should start using the Widgets API. Note that with the changes below we’ll break all these screens by making them empty (there won’t be any widgets initially).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The existing components for dashboard screen and the dashboard-details screen should be modified (let’s not refactor these components; let’s change them as little as possible, as much as needed for just this change here) to use the WidgetAreasRenderer to render widget areas. If possible, for now let’s just add this component and not replace the existing “filtered components” currently being used to render the respective area. This will allow us to temporarily have both the old and new way available (we’ll never publish any release with that state, but it’ll potentially help building the new widgets and ensuring they look and behave similarly). Also keep in mind this is all happening in a branch separate from develop. The components should render widget areas for the given context as follows:
  • For the dashboard use context dashboard.
  • For the dashboard-details (“dashboard for a single URL”) use context pageDashboard.
• Modify the core/widgets datastore module so that it automatically registers a few core widget areas for context dashboard (they should registered with prioritiy 1-5 in the order below):
  • dashboardAllTraffic
  • dashboardSearchFunnel
  • dashboardPopularity
  • dashboardSpeed
  • dashboardEarnings
• Modify the core/widgets datastore module so that it automatically registers a few core widget areas for context dashboardDetails (they should registered with prioritiy 1-4 in the order below):
  • pageDashboardSearchFunnel
  • pageDashboardAllTraffic
  • pageDashboardTopQueries
  • pageDashboardSpeed

Implementation Brief

• Add feature flags and use them for this code:
  • Use webpack-feature-flags-plugin to set our feature flags. This gives us tree-shaking dead code elimination (so we never ship that code to production until it’s enabled), but allow us to reduce our usage of long-running feature branches.
• Add { featureFlags.DashboardWidgetsAPI && <WidgetAreasRenderer context="dashboard" />} to https://github.com/google/site-kit-wp/blob/c302d8cb77374e394ba4711a93b3d7ca33e43802/assets/js/googlesitekit-dashboard.js#L54. I’d prefer to place our new components up as high-as-possible in the tree to prevent interaction with existing filters/WP JS Hooks, etc. We can create a component to house this WidgetAreasRenderer if desired, but I’d love to put the new components up at the top of the tree. We may need to place it lower in the tree to be able to share screen space with existing widgets, but best to try to put it as high as possible and adjust during implementation 😄
• Add a <WidgetAreasRenderer context="pageDashboard" /> to https://github.com/google/site-kit-wp/blob/c302d8cb77374e394ba4711a93b3d7ca33e43802/assets/js/googlesitekit-dashboard-details.js#L44. I’m going with pageDashboard as the context here over dashboardDetails, because I agree that we should have a better name for this, and I’ve always found “Dashboard Details” to be confusing and a bit of an unclear implementation leak.
• Register these widgets areas for the dashboard context:
  • dashboardAllTraffic
  • dashboardSearchFunnel
  • dashboardPopularity
  • dashboardSpeed
  • dashboardEarnings
• Register these widgets areas for the pageDashboard context:
  • pageDashboardSearchFunnel
  • pageDashboardAllTraffic
  • pageDashboardTopQueries
  • pageDashboardSpeed

These widgets won’t all exist yet, but we should write the code to queue them up. Then place the code behind a development feature flag. That way we can start outputting whatever widgets we do have available by excluding them from the feature flag check (or having specific flags for each feature and enabling them for production builds).

QA Brief

• For a development build, these duplicate widget areas should be displayed (indented), in both the dashboard and the single page dashboard. They don’t have any widgets yet, so it should basically just be the headings and subtitles.
• For a production build, these should not be displayed at all. There should be no visual change from a production build with and without this issue completed.

Changelog entry

• Implement widget areas using new Site Kit widgets API.

[felixarntz]

With this getting merged, be aware that running a development build (npm run build:dev) will from now on include an unfinished and unpolished duplicate list of widget areas in both the dashboard and the single page dashboard. Due to some grid constraints and to keep things simple alongside the existing production UI, the new widget areas are slightly further indented. Let’s keep it this way for now, it actually serves as a good visual indicator that those further indented areas are the new ones, which are hidden behind a feature flag.

See these screenshots for reference of what this should look like for a development build: Dashboard

Single Page Dashboard

For production builds (npm run build), nothing should visually change from today, i.e. these duplicate widget areas shouldn’t display there.

We will resolve the outer UI concerns, i.e. make sure the new areas are no longer extra indented, once we’re closer to completely removing the old widget areas (which didn’t use the API and were just hard-coded). In the long term, it will also be ensured that a widget area will not be displayed if it has no widgets in it (like what’s happening now).

[cole10up]

Tested

Installed develop zip and activated plugin.

Notice dashboard:

Installed latest 1.12.0 release candidate and activated plugin

Notice dashboard:

Confirmed install and uninstall of plugin

Passed QA ✅