The "Overview for the last x days" widget on the Search Console module page should be refactored as a new component that is registered and rendered using the Widget API.

The existing component should be untouched and only be renamed, giving it a Legacy prefix.

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

Acceptance criteria

• A new component ModuleOverviewWidget should be added in assets/js/modules/search-console/components/module/ModuleOverviewWidget.js.
• It should be implemented as a functional, hook-based, datastore-driven widget component that renders a new version of the existing "Overview for the last x days" block on the Search Console module page, in a refactored way
  • It should display similar metrics to what the legacy SearchConsoleDashboardWidgetOverview and SearchConsoleDashboardWidgetSiteStats components display.
  • However, the UI should be slightly different from the current version: It should follow the same conventions and use the same visual components as the overview graphs on the Analytics and AdSense modules pages respectively.
    • It should no longer be possible to have multiple metrics selected at the same time; i.e. the graph should always have only one x-axis.
    • The graph line chart should also include the dashed line for the previous period (i.e. extra metrics need to be included here).
    • At a high level, even though this refactoring here also changes the expected behavior, at the same time it makes it simpler in some ways as a similar component implementation that was used for the refactored Analytics and AdSense module page overview widgets can be reused here (see the components from Migrate Analytics page "Audience overview" widget to use Widget API #2067 and Migrate AdSense page "Performance" widget to use Widget API #2065).
  • Sub-components can be implemented as necessary. If reusable, they should go into assets/js/modules/search-console/components/common. Otherwise (if specific to just this widget), they should go into a new assets/js/modules/search-console/components/module/ModuleOverviewWidget directory; in this case, the main widget component should go into the index.js file within that directory.
• The new component should be used to register a new widget in assets/js/modules/search-console/index.js (for testing, requires to enable the widgets.moduleScreens feature flag):
  • slug: searchConsoleModuleOverview
  • width: WIDGET_WIDTHS.FULL
  • priority: 1
  • wrapWidget: false (since it needs to render Widget manually to add the Header prop
  • widget area: AREA_MODULE_SEARCH_CONSOLE_MAIN
• SearchConsoleDashboardWidgetOverview and SearchConsoleDashboardWidgetSiteStats should be renamed to have a Legacy* prefix added.

Implementation Brief

• Implement requirements defined in the AC
  More specifically:
• Look to the AdSensePerformanceWidget component for how to implement the Search Console Overview component (pictured below)
  

  site-kit-wp/assets/js/modules/adsense/components/dashboard/AdSensePerformanceWidget.js

  Lines 39 to 84 in 857b07e

  	export default function AdSensePerformanceWidget( { handleDataSuccess, handleDataError } ) {
  	const [ selectedStats, setSelectedStats ] = useState( 0 );
  	const {
  	startDate,
  	endDate,
  	compareStartDate,
  	compareEndDate,
  	} = useSelect( ( select ) => select( CORE_USER ).getDateRangeDates( { compare: true } ) );
  	const handleStatSelection = useCallback( ( stat ) => {
  	setSelectedStats( stat );
  	}, [] );
  	const metrics = {
  	EARNINGS: __( 'Earnings', 'google-site-kit' ),
  	PAGE_VIEWS_RPM: __( 'Page RPM', 'google-site-kit' ),
  	IMPRESSIONS: __( 'Impressions', 'google-site-kit' ),
  	PAGE_VIEWS_CTR: __( 'Page CTR', 'google-site-kit' ),
  	};
  	return (
  	<Fragment>
  	<AdSenseDashboardWidgetOverview
  	startDate={ startDate }
  	endDate={ endDate }
  	compareStartDate={ compareStartDate }
  	compareEndDate={ compareEndDate }
  	metrics={ metrics }
  	selectedStats={ selectedStats }
  	handleStatSelection={ handleStatSelection }
  	handleDataSuccess={ handleDataSuccess }
  	handleDataError={ handleDataError }
  	/>
  	<AdSenseDashboardWidgetSiteStats
  	startDate={ startDate }
  	endDate={ endDate }
  	compareStartDate={ compareStartDate }
  	compareEndDate={ compareEndDate }
  	metrics={ metrics }
  	selectedStats={ selectedStats }
  	/>
  	</Fragment>
  	);
  	}

• Note that the previous period for Search Console data should be selected, for an example using AdSense see:

  site-kit-wp/assets/js/modules/adsense/components/dashboard/AdSenseDashboardWidgetSiteStats.js

  Lines 38 to 59 in 857b07e

  	const {
  	startDate,
  	endDate,
  	compareStartDate,
  	compareEndDate,
  	metrics,
  	selectedStats,
  	} = props;
  	const currentRangeArgs = {
  	dimensions: [ 'DATE' ],
  	metrics: Object.keys( metrics ),
  	startDate,
  	endDate,
  	};
  	const prevRangeArgs = {
  	dimensions: [ 'DATE' ],
  	metrics: Object.keys( metrics ),
  	startDate: compareStartDate,
  	endDate: compareEndDate,
  	};

  . Unfortunately, the Search Console API does not support the compareStartDate options as it has no sense of a "previous period"—see comment Migrate Search Console page "Overview" widget to use Widget API #2063 (comment) below. The logic to be used for getting the reports ("previous" and "current") needs to request "both periods at once" and then separate out the data—get all dates inside compareStartDate-compareEndDate as the "previous" report, and all other dates as the "current" report. The old data request can be found here:

  site-kit-wp/assets/js/modules/search-console/components/dashboard/SearchConsoleDashboardWidgetOverview.js

  Lines 146 to 159 in 857b07e

  	[
  	{
  	type: TYPE_MODULES,
  	identifier: 'search-console',
  	datapoint: 'searchanalytics',
  	data: {
  	dimensions: 'date',
  	compareDateRanges: true,
  	},
  	priority: 1,
  	maxAge: getTimeInSeconds( 'day' ),
  	context: [ 'Single', 'Dashboard' ],
  	},
  	],

  and should be transferred to a useSelect( ( select ) => select( MODULES_SEARCH_CONSOLE ).getReport() ) call that spans from the compareStartDate to the endDate, with the report then filtering out the relevant periods. (It might be nicer to modify the getReport selector to handle this automatically. What do you think @felixarntz? It would mean more requests but our API would be more consistent and easier to reason about. 🤷🏻‍♂️ )
• Note that the selectedStats behaviour should also be copied—only one item should be allowed to be selected. Essentially, this sort of state:

should not be allowed. Only one stat can be selected at a time, eg:

Test Coverage

• N/A

Visual Regression Changes

• The new Search Console widget will only allow for a single metric to be selected, so won't:
  • start with two metrics selected
  • allow 2, 3, or 4 metrics to be selected at the same time
  • ever hide the labels for metrics because no more than 1 (or 2) metrics can be selected

This won't affect VRT tests for legacy components, but it's worth highlighting.

QA Brief

• Visit the "Search Console" dashboard.
• The new "Overview" widget should be displayed above the current legacy component. Both widgets, legacy and new one should display the same data.
• The new widget should not allow the selection of multiple metrics at the same time and there should be a graph line chart should also include the dashed line for the previous period.

Changelog entry

• Migrate Search Console module page overview widget to use Widget API.