Packages: Move api-fetch usage to new shared package

[spacedmonkey]

Feature Description

• Move some of the code from /assets/src/edit-story/utils/base64Encode.js to /packages/api-fetch/src/
• Move some of the code from /packages/design-system/src/utils/addQueryArgs.js to /packages/api/src/ + tests
• export * from '@wordpress/api-fetch';
• Update imports where necessary.
  Use @web-stories-wp/... imports for anything that is already a package, relative imports for everything else.
• Create /packages/api-fetch/package.json referencing its dependencies
• Create /packages/api-fetch/README.md with short documentation.

Alternatives Considered

Additional Context

---

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

Acceptance Criteria

Implementation Brief

[spacedmonkey]

Adding this new package, adds a new number of benefits.

1. base64Encode.js will not longer be loaded from editor in dashboard.
2. addQueryArgs is moved to a more sensible place out of the design system.
3. Neither the editor / dashboard will have direct dependencies on a WordPress package.
4. Updating apiFetch package is done in one place.

Thoughts @swissspidy ?

[swissspidy]

With the decoupling work we'll end up with at least the following packages:

• dashboard
• wp-dashboard
• story-editor (think @wordpress/block-editor in Gutenberg)
• wp-story-editor (think @wordpress/edit-post in Gutenberg)

There will probably be a fifth one with shared utilities used by both wp- packages, e.g. wp-story-utils or similar.

addQueryArgs, @wordpress/api-fetch usage, base64Encode, getResourceFromAttachment, etc. would all live in that package.

story-editor and dashboard would never use those directly. Only wp-dashboard and wp-story-editor would.

So I'd rather name this wp-story-utils or similar, not api-fetch.

[spacedmonkey]

The decoupling work would be part of the reason we could do this. I am hoping that are some point, if when we decouple this editor from WordPress, we could simple replace the api-fetch package with api-fetch-drupal or similar. As long as the functions returned as the same return and params, the internals could be very different.

wp-story-utils as a name is bad, as utils is sounds like a catch-all dumping ground name. Something with api in the name makes it much clearer it's use.

[swissspidy]

The decoupling work would be part of the reason we could do this. I am hoping that are some point, if when we decouple this editor from WordPress, we could simple replace the api-fetch package with api-fetch-drupal or similar. As long as the functions returned as the same return and params, the internals could be very different.

In such a scenario we would create a dedicated drupal-story-editor package that interacts with the Drupal API and passes the necessary data to story-editor, and more.

wp-story-utils as a name is bad, as utils is sounds like a catch-all dumping ground name. Something with api in the name makes it much clearer it's use.

Ignore the name, I just made this up on the spot to try to explain the goal. The point is that there would be a shared package consumed by the two wp- packages.

With this goal in mind, the package will look much different.

1. No need for a custom addQueryArgs util, because the wp- packages can just use the one from @wordpress/url, which is OK.
2. No need for re-exporting @wordpress/api-fetch, because the wp- packages can just use that one directly, which is OK.
3. story-editor and dashboard will not depend on any WordPress packages directly.

---

Edit: We're basically saying the same thing, it's just that this package will likely look quite different and contain more things. It's too early to work on this though.