Extract Embed Block template code to a package.

[pento]

Description

Fixes #13490.

This PR extracts the common code used by Core's embed blocks into a new @wordpress/embed-block package, allowing plugins to make use of this simpler method for creating embed-style blocks.

How has this been tested?

Automattic/jetpack#14648 is an experiment in making use of this new package.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[pento]

This is currently a first pass, but I'd appreciate some early feedback on the direction. 🙂

[gziolo]

This is a very interesting idea to move all common code related to embeds to its own package. In fact, there is some prior-art for media utils. See @wordpress/media-utils package introduced by @jorgefilipecosta. It's definitely a good direction if we want to make it easier to build custom embeds.

The biggest challenge is how to ensure that only essential APIs are exposed from this package and are well documented. In particular utils.js files, it seems like it shouldn't be part of the public API.

[pento]

The biggest challenge is how to ensure that only essential APIs are exposed from this package and are well documented. In particular utils.js files, it seems like it shouldn't be part of the public API.

I agree, this will need auditing. I just went with export * while hacking it together to get it working. 🙂

[pento]

I have some time to push this forward again, so I've updated the PR, and created a sample use: Automattic/jetpack#14648

@gziolo Do you have more thoughts on the viability of this approach?

[gziolo]

@mcsf, did you have a chance to look at embeds and how they could possibly be refactored to sue variations? Still, it might be necessary to expose some components as proposed in this PR.

[mcsf]

@mcsf, did you have a chance to look at embeds and how they could possibly be refactored to sue variations? Still, it might be necessary to expose some components as proposed in this PR.

(Oops, I missed this ping due to some AFK time.)

I looked at embeds very experimentally as a prelude to the work on Social Icons, which was more pressing. I still think it's fairly feasible to turn Embeds into variations of a single block type. @pento, if you're interested in this, I can cc you in that task so we can figure out what makes most sense to extract from block-library.

[mcsf]

@gziolo: looking at embeds, it becomes clear that we need slash-inserter support for variations.

[gziolo]

@gziolo: looking at embeds, it becomes clear that we need slash-inserter support for variations.

I'm putting it on my todo list 👍

[pento]

@mcsf: I don't know that I'll have wild amounts of time to devote to this, but if you can give me some more details on what needs to be done, I'll see what I can wrangle.

[mcsf]

@mcsf: I don't know that I'll have wild amounts of time to devote to this, but if you can give me some more details on what needs to be done, I'll see what I can wrangle.

@pento: don't worry, I'll share a PR whenever I have something and it should become apparent what could be reused. Honestly, though, my wish is that we could, over the next quarter, greatly simplify the way that embeds work (and turning them into a variation would be a definite first step) so that there is actually very little that needs to be reused. I suspect that advances in React from the last year and half (cf. hooks) could help us untangle some design patterns in the embeds code base, too.

[pento]

Sounds like a plan, @mcsf. I'm going to close this PR out, then, and we'll pick it back up again when you've had a chance to explore the block variation idea.