Use googlesitekit-data imports directly instead of object destructing

[tofumatt]

Feature Description

Our googlesitekit-* modules (eg. googlesitekit-data, googlesitekit-api, etc.) are exported as objects with only default entrypoints, meaning to use things like useSelect or withSelect, we need to import the whole module, then do object destructuring to get the actual function we want, eg:

import Data from 'googlesitekit-data';

const { createRegistrySelector, useSelect } = Data;

These webpack aliases are unlike any other code/imports in our codebase—they're sort of awkward, don't allow for auto-imports, and make following the path to 'googlesitekit-*' modules in VSCode/other TypeScript-aware editors impossible, because they aren’t aliased.

This would be a nicer interface:

import { createRegistrySelector, useSelect } from 'googlesitekit-data';

I forget why we didn't do this at the time, but it might've just been an error of omission that's ballooned to quite a big surface area of a small pain point 😆

We should support importing directly from the module. My proof-of-concept PR removes about 300 lines of code and improves the developer ergonomics/experience a fair bit in doing so: #8753.

---

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

Acceptance criteria

• All properties of the Data module that is available as googlesitekit.data should also be exported as named exports from googlesitekit-data, so our internal code can access these functions/constants directly as named imports instead of properties from the Data object.
• It should be possible to follow the import 'googlesitekit-data' in VSCode/other TypeScript-aware tooling to the file that exports these functions, eg. assets/js/googlesitekit/data/index.js.

Implementation Brief

Note: Leave this issue for @tofumatt to work on, as he's already started the proof-of-concept PR for this issue and has a lot of context, as he worked on it during the Hackathon 🙂

• Export all attributes of googlesitekit-data's Data object directly (see: https://github.com/google/site-kit-wp/pull/8753/files#diff-057e8bc0b27b93a085309c427c3856be324d1a340050abe2435491bef9ec77a9R71-R86)
• Ensure exports can be followed in VSCode using a tsconfig.json with an alias for googlesitekit-data: (see: https://github.com/google/site-kit-wp/pull/8753/files#diff-b55cdbef4907b7045f32cc5360d48d262cca5f94062e353089f189f4460039e0R6-R8)
• Update all googlesitekit-data imports
• Possibly removing Data default export to prevent new usage (Kept so that functions that interact with the registry/googlesitekit-data still work)

See: #8753 for the proof-of-concept for this PR.

Test Coverage

• No new tests are needed, but all existing tests should pass without modification.

QA Brief

No explicit QA instructions; this modifies all of our datastore imports, but should not actually change any behaviour.

It would be best to set up a site with all modules and do basic smoke testing after this is merged. If there are no issues, everything is good 😄

Changelog entry

• N/A

[eugene-manuilov]

IB ✔️

[wpdarren]

QA Update: ✅

Verified:

I was able to set up a site with all modules and completed basic smoke testing. I could not find any obvious issues. No console errors, or on screen error messages. We will ensure that more through testing is completed during release testing.

[aaemnnosttv]

We have one instance of this left that looks like it was added while this one was in flight in

site-kit-wp/assets/js/modules/analytics-4/components/audience-segmentation/dashboard/AudienceSelectionPanel/ErrorNotice.js

Line 37 in 8240ccf

const { useSelect, useDispatch } = Data;

We can clean it up later though 👍

@tofumatt can we perhaps include this in one of the follow-up issues to do the other packages?