Remove extra nesting/padding around new Widgets API-driven dashboard

[felixarntz]

Currently there is some extra padding and various nested HTML elements around the new Widgets API-based dashboard which are mostly there because the new WidgetContextRenderer was embedded into the existing legacy DOM structure. We should fix that so that the WidgetContextRenderer practically can take care of rendering the entire page itself.

---

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

Acceptance criteria

• The Widgets API-based version of the dashboard (see DashboardApp) and the single URL dashboard (see DashboardDetailsApp) should have the same visual padding from the main page border as its current/legacy version does.
• The Widgets API-based version of the dashboard (see DashboardApp) and the single URL dashboard (see DashboardDetailsApp) should work like it would if it was the "only thing on the page", i.e. it should have its own (duplicate) header and (duplicate) "Need help" link in the footer.
• The WidgetContextRenderer component should be able to take care of rendering basically the full page content (except the overall Site Kit header bar):
  • It should support an optional className prop so that the div.googlesitekit-widget-context element can have additional class names.
  • It should support an optional Header prop for a component to render as the overall header for the widget areas within the context.
  • It should support an optional Footer prop for a component to render as the overall footer for the widget areas within the context.

Implementation Brief

• Add optional className prop to WidgetContextRenderer (with PropTypes.string). If passed, combine it with the automatically added googlesitekit-widget-context class so that the outer div has all of those classes.
• Add optional Header prop to WidgetContextRenderer (with PropTypes.elementType). If passed, it should be rendered within the div.googlesitekit-widget-context, but before all widget areas, and it should be wrapped within a <Grid><Row><Cell size={ 12 }> so that it's correctly indented.
• Add optional Footer prop to WidgetContextRenderer (with PropTypes.elementType). If passed, it should be rendered within the div.googlesitekit-widget-context, but after all widget areas, and it should be wrapped within a <Grid><Row><Cell size={ 12 }> so that it's correctly indented.
• Introduce DashboardHeader component which renders the PageHeader component with the same props that it's rendered with above the legacy widgets in DashboardApp.
• Introduce DashboardFooter component which renders a HelpLink within a div that causes it to render right-aligned.
• Modify the DashboardApp component:
  • Replace rendering the PageHeader with rendering the new DashboardHeader.
  • Move the rendering conditional for whether the widgets.dashboard feature flag is enabled above div.googlesitekit-module-page, below rendering the notifications, to separate the new Widgets API-based rendering from the current/legacy rendering entirely.
  • Remove the Cell that wraps WidgetContextRenderer.
  • Pass className prop to WidgetContextRenderer with value googlesitekit-module-page googlesitekit-dashboard, to keep these classes applying to the new Widgets API-based rendering as well.
  • Pass Header prop to WidgetContextRenderer with DashboardHeader.
  • Pass Footer prop to WidgetContextRenderer with DashboardFooter.
• Introduce DashboardDetailsHeader component which renders the Link and PageHeader component from DashboardDetailsApp, and also conditionally the DashboardDetailsEntityHeaderContainer from either DashboardDetailsEntityView or DashboardDetailsEntityNotFoundView, depending on whether there is a current entity.
  Note: DashboardDetailsEntityView and DashboardDetailsEntityNotFoundView will be reimplemented via DashboardDetailsHeader and will be removed (see below)
• Introduce DashboardDetailsFooter component which renders a HelpLink within a div that causes it to render right-aligned.
• Modify the DashboardDetailsApp component:
  • Replace rendering the Link and PageHeader and DashboardDetailsEntityView / DashboardDetailsEntityNotFoundView with rendering the DashboardDetailsHeader and, if there is a current entity, the DashboardDetailsModules component.
  • Add a rendering conditional for whether the widgets.pageDashboard feature flag is enabled above div.googlesitekit-module-page, below rendering the Header, to separate the new Widgets API-based rendering from the current/legacy rendering entirely.
  • In that conditional, render a WidgetContextRenderer.
  • Pass className prop to WidgetContextRenderer with value "googlesitekit-module-page googlesitekit-dashboard-single-url`, to keep these classes applying to the new Widgets API-based rendering as well.
  • Pass DashboardDetailsHeader as Header prop and DashboardDetailsFooter as Footer prop.
  • If there is a current entity, pass slug="pageDashboard". Otherwise, pass slug="pageDashboardNotFound" to ensure no widget areas are rendered there. (Technically, this relies on another (non-existing) widget area, so we could at some point leverage that to add e.g. a search widget to the page or help the user in another way.)
• Remove the DashboardDetailsEntityView and DashboardDetailsEntityNotFoundView components entirely.
• Prefix all purely legacy Dashboard* components with Legacy*, e.g. LegacyDashboardModules, LegacyDashboardDetailsModules etc.
• Check the Storybook stories for both of these states so that they still work as expected.

Test Coverage

• N/A

Visual Regression Changes

• N/A

QA Brief

• In a development build of Site Kit, the Widgets API-based version of the Site Kit dashboard should look exactly like the legacy version (from the production build, compare in separate window/tab).
  • There should be no extra padding or any visual disparities.
  • They should both include the "Site Overview" heading, and they should both include the "Need help?" link in the footer.
• In a development build of Site Kit, the Widgets API-based version of the Site Kit single URL dashboard view should look exactly like the legacy version (from the production build, compare in separate window/tab).
  • There should be no extra padding or any visual disparities.
  • They should both include the "Detailed Page Stats" heading, the white box that includes title and URL, and they should both include the "Need help?" link in the footer.
• In a production build, there should be no visual changes overall from how the dashboard / single URL view look today (no need to check specific widgets - this is about the overall page layout, similar to the points mentioned above).

Changelog entry

• Prepare Widget API-based version of the dashboard for launch, rendering the entire page content including header and footer.

[aaemnnosttv]

@felixarntz – overall the IB looks good to me. A few questions/thoughts:

• Introduce DashboardFooter component which renders a HelpLink within a div that causes it to render right-aligned.
• Introduce DashboardDetailsFooter component which renders a HelpLink within a div that causes it to render right-aligned.

Why not use DashboardFooter for the Footer prop in both cases rather than introduce a duplicate component?

• Add a featureFlags.widgets.dashboard.enabled rendering conditional above div.googlesitekit-module-page, below rendering the Header, to separate the new Widgets API-based rendering from the current/legacy rendering entirely.

We should probably refer to the feature flag condition a bit more abstractly (or in terms of how it will be) since #2452 will likely be merged before this issue is picked up.

---

One thing that comes to mind here regarding the transition to the Widgets API is that it might be a bit easier to transition by wrapping the legacy layout in a single widget area + full-width widget. Then the feature flag would simply influence which context is provided to the area (e.g. dashboard or legacyDashboard). That way we wouldn't need to have completely separate wrapping components and we could introduce the Widgets API a bit more gradually rather than all at once since the main risk is more around the new widgets rather than the API itself.

[felixarntz]

@aaemnnosttv

Why not use DashboardFooter for the Footer prop in both cases rather than introduce a duplicate component?

We could, but I think since these two are different area-specific components and since it is not set in stone that those would necessarily render the same thing, I think it makes sense to have them separate.

We should probably refer to the feature flag condition a bit more abstractly (or in terms of how it will be) since #2452 will likely be merged before this issue is picked up.

Good point, updated.

One thing that comes to mind here regarding the transition to the Widgets API is that it might be a bit easier to transition by wrapping the legacy layout in a single widget area + full-width widget. Then the feature flag would simply influence which context is provided to the area (e.g. dashboard or legacyDashboard). That way we wouldn't need to have completely separate wrapping components and we could introduce the Widgets API a bit more gradually rather than all at once since the main risk is more around the new widgets rather than the API itself.

I think the idea is worth considering overall, but the way the legacy components are implemented I think it's easier to keep them separate as is. Putting the legacy components into a separate widget would probably be more work than is needed here, and it could result in unexpected breakage. I'd prefer to touch the old components as little as possible and just wait for them to be replaced/removed.

It shouldn't be too much of a problem to wait until the Widgets API-based dashboard has been rolled out to production for the Widgets API to be used. With all the widgets Site Kit will have it will also be a better starting point for 3P developers, since they can then look at those widgets for reference.

[aaemnnosttv]

@felixarntz IB LGTM – the only thing that was a bit confusing was understanding the changes to DashboardDetailsApp and how DashboardDetailsEntityView and DashboardDetailsEntityNotFoundView are being replaced (merged into) the new DashboardDetailsHeader since this isn't mentioned until further down. I'll make a note of this above but otherwise great!

IB ✅

[wpdarren]

QA Update: Engineer to confirm ⚠️

@aaemnnosttv I am seeing quite a few differences but not in layout. E.g. on the Site Kit dashboard, on development build the Search funnel says Unique Visitors From Search, where as on production build it is saying Unique Visitors. I know the ticket suggests this is just layout, but would like to double check.

[aaemnnosttv]

@wpdarren I noticed a few differences between the widget-based and legacy dashboard when doing my review but not as a result of this issue. Please make a note about all of the differences you see and we can see which ones need issues or which are intentional changes.

[wpdarren]

QA Update: Engineer to confirm ⚠️

@aaemnnosttv here are the differences I've found between production and development build for the Site Kit Dashboard and Detailed Page Stats page. The layout looks fine, so this can be passed but would appreciate it if you could look through the differences and let me know if these need a new ticket or not.

There are a number of differences between the production and development build. I've listed them all here, even though the change in this ticket might not necessarily be the cause. New tickets can be created.

1. On the Site Kit dashboard. Under Page speed. The list of recommendations are ordered differently.

Production build

Development build

2. On the Detailed Page Stats page. The line graphs look different.

Production Build

Development Build

3. On the Detailed Page Stats page. The new All Traffic widget appears on Production build but the old pie chart appears in the development build. This might be expected but want to check.

Production Build

Development Build

4. On the Detailed Page Stats page. On the Production build the title is Popularity whereas on Development build it is Top Queries related to search console pages.

Production Build

Development Build

5. On the Detailed Page Stats page. Under Page speed. The list of recommendations are ordered differently. (see screenshots above)

6. Under Search Funnel. The unique visitors title is different. On Production build it is Unique Visitors but Development build says Unique Visitors from Search

Production build

Development build

The comparison above was for a site with analytics, etc. I did the same with a site that installed Site Kit for the first time.

7. Production build had a Use goals to measure success but the development build didn't

8. Development build has a thick white border around the Popularity section but didn't in Production Build

[aaemnnosttv]

Thanks for the detailed report @wpdarren! I think these are probably unrelated but some of them are probably worth opening issues for. I'll assign this to @felixarntz to confirm.

[wpdarren]

@felixarntz wondered what your thoughts on my review of the differences? Are these related to this ticket or would you like me to create a new ticket? I know the ticket mentions more the padding/nesting which does not appear to be an issue.

[felixarntz]

@wpdarren Thanks for the ping, sorry for the delay. Some feedback:

1. This is expected, the order and the available recommendations may differ between different requests, so this is unrelated to the widget API-based dashboard.
2. This is actually an improvement, the current/old dashboard shows the same sparkline for Bounce Rate as it does for Unique Visitors which is incorrect (captured via #1996).
3. Oh wow, we should fix this ASAP. The old All Traffic widget should no longer be used - it is actually showing up in a production build 🤦‍♂️ I'll open a high priority issue, we need to get this fixed now, before the release.
4. That is an expected change, we've consolidated the widget areas to have consistent titles between overall dashboard and single URL dashboard.
5. Expected, same as 1.
6. This also is an expected change; these users aren't all "visitors from search", they come from any sources.
7. This is indeed incorrect, I'll open an issue to fix it. There are a few inconsistencies between the old and new Goals widget.
8. That is an acceptable change.

Overall observation, I think you accidentally mislabelled some of the screenshots between develop and production build? At least under 2, 3, 4, and 6, the screenshots are each for the respective other build.

Note that, at this point, and for any future reviews, using a development build vs production build should no longer matter. Feature flags are now solely controlled via the 1.4.0 version of the Site Kit tester plugin; so going forward you should be able to always use a production build, and then compare state with the respective feature flag turned on or off.

[wpdarren]

@felixarntz thank you for confirming these for me. I will give this another run through based what you've said about the 1.4.0 tester plugin and then move this forward. To confirm 3, and 7 you have/will create tickets for these.

[wpdarren]

QA Update: Pass ✅

Verified:

• On the Site Kit Dashboard: There are no extra padding or any visual disparities. Both include the "Site Overview" heading, and they should both include the "Need help?" link in the footer.

• On the Single URL dashboard: There are no extra padding or any visual disparities. Both include the "Site Overview" heading, and they should both include the "Need help?" link in the footer.