Refactor components to use dateRange via datastore

Feature Description

Once the datastore foundation is in place in #1529, the existing DateRangeSelector should be refactored to use the datastore for its state, rather than WP hooks

---

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

Acceptance criteria

• DateRangeSelector should use datastore state internally instead of the current filter-based implementation
• All other components/functions which consume/reference dateRange state (e.g. dataAPI) must be updated to source the value from the datastore, without using @wordpress/hooks

Implementation Brief

Legacy non-functional components that can’t be rewritten as functional components will need to be updated to be wrapped with withSelect and withDispatch as needed which provide registry selected data or dispatch functions to the consuming components as props.
This can be done by wrapping the component before it’s exported.

Update DateRangeSelector

should be reimplemented as functional component

Displaying all options Rather than defining all options internally, it can get them via the new getAvailableDateRanges utility

Selecting a new date range Replace the current hook with a dispatch call when a new range is selected https://github.com/google/site-kit-wp/blob/09a45d7c0f2a8af533335d8d7076e434f04051b5/assets/js/components/date-range-selector.js#L77-L84

• Replace with useDispatch(...).setDateRange( slug )

Triggering new data to be fetched Currently this is done like so https://github.com/google/site-kit-wp/blob/09a45d7c0f2a8af533335d8d7076e434f04051b5/assets/js/components/date-range-selector.js#L86-L88

This can be done with useEffect( () => {...}, [ dateRange ] ) to run every time the date range changes

The component will still need to use WordPress hooks for this until we’re no longer using the legacy dataAPI.

dataAPI and utils

After all other components are refactored to use date range state from the datastore, dataAPI will be all that’s left, using it via these utilities

• getCurrentDateRange
• getCurrentDateRangeSlug

These can be updated to use slug = Data.select( 'core/user' ).getDateRange() directly in place of the filters. The date range label is available via getAvailableDateRanges( slug ).label

Remaining components

• AnalyticsDashboardWidgetTopAcquisitionSources
  • clean refactor to functional component with useSelect as it only has a render method
• AnalyticsDashboardWidget
  • refactor with data HOCs to provide dateRange
• GoogleSitekitSearchConsoleDashboardWidget
  • refactor with data HOCs to provide dateRange

QA Brief

Changelog entry

• Migrate the existing date range selector component to rely on the centrally managed date range from datastore.

[aaemnnosttv]

Can you update the function names in the IB? After that, it’s good from my end.

@felixarntz updated! I removed the part about initial state as well since that will be handled in #1529 anyways.

Assuming this is IB ✅ - moving to backlog 👍

[felixarntz]

Right, but that means we don’t need to handle this here, since getDateRange would never return undefined right?

Can you update the function names in the IB? After that, it’s good from my end.