Implement Block Supports as GraphQL Interfaces

[justlevine]

⚠️ Disclaimer

This is a [stub] follow-up to #136 , as @moonmeister encouraged me to start backfilling some of my bigger wish-list items instead of keeping them all for myself 😇

Problem

Currently, Block fields and attributes are registered directly on each block type. This causes several issues:

1. Bloated schema / queries / userland codebases*, since you can't write generic fragments
2. Schema conflicts / inconsistencies, as different blocks implement the same value as different types ( e.g. an int vs a string attributes.height)
3. Prone to breaking on Gutenberg updates (e.g when they notice and patch those type discrepancies)
4. Suboptimal DX (e.g instead of an int or a string, attributes.height should be a CssMeasurement<{$size}{$unit}> )

Solution

*BlockAttribute Object types should implement GraphQL Interfaces per their Block Supports, and use that as the stable source of truth for those parts of the schema going forward.

Then and only where there is a conflict between the interfaces and what's inferred from the block.json we can coerce it on the block resolver level. The same approach can also:

• provide stability and future-proofing (by coercing any values resolved via the interface),
• allow for multiversion-backcompat (it's just another conditional in the resolver)
• (eventually) provide a path for improved subjective DX, without it becoming additional tech-debt (due to the previous two points).

For example (I suck at naming things, so giving a few different styles. These are illustrative only):

• BlockAttributesSupportsTypographyFontSize
• BlockSupportsColorHeading
• FilterDuotoneBlockSupportAttributes

You can see some exploratory work to this effect in rtCamp#31

Additional Notes

• Nothing here requires a breaking change to implement, and it can be implemented incrementally.
• An obvious future extension of this are interfaces for shared functionality on a Block level. E.g. image/media item connections, related terms, etc

[theodesp]

Hello @justlevine. Just to get this right. Is this a generalization of the Anchor supports interface that we implemented here?

https://github.com/wpengine/wp-graphql-content-blocks/blob/708ab892a938c004468785b9835d984ac4eff9ec/includes/Field/BlockSupports/Anchor.php

So now we want to add more Attribute interfaces that we can query based on their respective support types?

[justlevine]

@theodesp it would (deprecate and then) replace the existing Anchor interface, yes. But handling and approach are very different.

we want to add more Attribute interfaces that we can query based on their respective support types?

Kinda the opposite: we want to build and resolve our Attribute objects based on Interfaces that align with their respective support types.

But yes ultimately, from a final schema POV there would be a GraphQL Interface applied to the relevant GraphQL objects that would indicate the presence of an anchor field.

[theodesp]

@justlevine sure. It looks like a good improvement. Is it OK with you If we cut some tickets in the backlog for this based on your PR?