Refactor `@wordpress/editor` to be usable outside of a WordPress admin context

[sarayourfriend]

Problem

Currently the @wordpress/editor package and the exposed Editor component rely on a WordPress admin context. The WP admin context is assumed through the use of apiFetch both directly and indirectly through core-data.

Proposed solution

1. Refactor @wordpress/editor and related packages to remove direct usages of apiFetch in favor of using core-data.
2. Create an adapter API for core-data such that anyone could implement a @wordpress/data store that adheres to the core-data interface thereby allowing someone to define all the behaviors of entity retrieval and modifications for whatever backend they have that may or may not be WordPress.

The goal would be that the <Editor /> component could be dropped in with a few props and that as long as a core-data adapter store is defined correctly, the Editor would work.

This solution will require the following:

• A fully documented entity model. This is already documented through TypeScript types, but should be published in regular documentation.
• Fully documented core-data interface.
• Perhaps an example core-data adapter using browser persistence APIs like localStorage to show the community how a core-data adapter can be written.

Implications

This will have implications for how problems like async block dependencies are solved. For example, we cannot solve that problem with a WordPress admin context in mind, we would need to make the solution available outside of WP admin.

Some default behaviors that exist in @wordpress/editor like the user autocompleter or even the classic block should be moved into WordPress admin specific contexts like separate packages that are consumed by the various edit-* packages.

[jsnajdr]

I'm very excited about this work 🙂

My understanding is that this breaks down into two broad tasks:

Making Gutenberg fully powered by REST API That's what @ockham sees as a major issue, if I understand correctly. Don't rely on the server-rendered PHP page for Gutenberg to supply the editor with information, but rather expose everything through a REST API and make that the only communication channel. This is also one of the main technical ideas behind Calypso.

Build the WP-agnostic entity model and network API That's @youknowriad 's vision 🙂 Here I admit that I don't fully understand what's the practical use case for that abstraction. I'm familiar with the WP.com integration, and for that, an api-fetch adapter seems like a perfectly OK solution. WP.com is still WordPress and its REST API, and we only need to map the routes by adding a /sites/$site prefix here and there, and do the authentication right. api-fetch is the right place for that.

In Calypso, we built an ambitious abstraction around the data layer, but 4 years later, I feel it still doesn't have a convincing use case. For most practical purposes, using action thunks and direct wpcom calls continues to work just fine. I'd like to avoid building a similar abstraction again.

I'm aware that there are many use cases for Gutenberg totally outside the WordPress world, it's just that I don't have any deep knowledge about them, so my excitement is limited by that 🙂