The next question to answer will be how the source (i.e. core/post-data) will handle different block attributes (id, url, alt, title) all being bound using the same args, and how to map source properties to block attributes. For example, an image object retrieved from WP's REST API has fields such as id, alt_text, source_url, and title , where title has raw and rendered properties. We need to find a way to define a mapping from those source properties to block attributes, and a way to default to the "right" mapping -- i.e. where alt_text maps to alt, source_url to url, etc, when dealing with an Image block.

Size Change: -24 B (0%)

Total Size: 1.91 MB

_{compressed-size-action}

One thing to consider would be e.g. how the Featured Image block currently fetches a post's featured image, and how it maps the latter's properties to its attributes -- especially considering that in the long run, it should be possible to express the Featured Image block as an Image block bound to the core/post-data source's featuredImage field.

One thing to consider would be e.g. how the Featured Image block currently fetches a post's featured image, and how it maps the latter's properties to its attributes

The Featured Image block is dynamic, so everything is handled with the get_the_post_thumbnail helper function. Better example would be the Cover block which dynamically replaces injects the featured image URL as style:

The next question to answer will be how the source (i.e. core/post-data) will handle different block attributes (id, url, alt, title) all being bound using the same args, and how to map source properties to block attributes.

When connecting the __default for the source, should the mapping between the properties from external data and the block attributes be optionally provided? It's a bit tricky because it means the source would have to provide this mapping on a per-block basis.

The next question to answer will be how the source (i.e. core/post-data) will handle different block attributes (id, url, alt, title) all being bound using the same args, and how to map source properties to block attributes.

When connecting the __default for the source, should the mapping between the properties from external data and the block attributes be optionally provided? It's a bit tricky because it means the source would have to provide this mapping on a per-block basis.

Yeah, that's the big question here. As we discussed on our call, there's no one-size-fits-all mapper; e.g. while the image-related attributes are called id, url, alt, and title in case of the core/image block, they're called mediaId, mediaUrl, and mediaAlt in case of the core/media-text block.

This means that the mappers are still fully determined by the block type. This would probably allow us to make Block Bindings smart enough to make the __default binding take this into account.

The individual attribute mappings -- which I had originally suggested to read

{
	"alt":{"src":"core/post-data","args":{"key":"featuredMedia"}},
	"id":{"src":"core/post-data","args":{"key":"featuredMedia"}},
	"title":{"src":"core/post-data","args":{"key":"featuredMedia"}},
	"url":{"src":"core/post-data","args":{"key":"featuredMedia"}}
}

should however probably expose the attribute that's actually mapped; otherwise, there's to much magic going on. So maybe

{
	"__default":{"src":"core/post-data","args":{"key":"featuredMedia"}}
}

should expand to

{
	"alt":{"src":"core/post-data","args":{"key":"featuredMedia.alt_text"}},
	"id":{"src":"core/post-data","args":{"key":"featuredMedia.id"}},
	"title":{"src":"core/post-data","args":{"key":"featuredMedia.title"}},
	"url":{"src":"core/post-data","args":{"key":"featuredMedia. source_url"}}
}

in case of the core/image block, and to

{
	"mediaAlt":{"src":"core/post-data","args":{"key":"featuredMedia.alt_text"}},
	"mediaId":{"src":"core/post-data","args":{"key":"featuredMedia.id"}},
	"mediaUrl":{"src":"core/post-data","args":{"key":"featuredMedia. source_url"}}
}

in case of core/media-text.

(I still want to tweak the args syntax a bit; I don't like using key to denote nested properties here. Additionally, we actually do need to pass in an actual "argument" -- the desired image resolution.)

Another loose thought: JavaScript's object destructuring syntax could serve as inspiration for getting multiple "fields" from a source, and mapping the values to different block attribute names.

const { alt_text: alt, id, title: { rendered: title }, source_url: url } = featuredMedia;

Though I'm of course not sure how to best express this in JSON and within the existing framework of block bindings syntax 🤔 So it's probably more for inspiration.

Edit: The most "direct" translation of the left-hand side into JSON would probably be

{
	"alt_text": "alt",
	"id": "id",
	"title": { "rendered": "title" },
	"source_url": "url"
}

One possible way of using this way of defining a mapper could be by specifying it as a separate property:

{
	"__default":{
		"src":"core/post-data",
		"args":{
			"key":"featuredMedia"
		},
		"map":{
			"alt_text": "alt",
			"id": "id",
			"title": { "rendered": "title" },
			"source_url": "url"
		}
	}
}

(The reason why I wouldn't include it in args is that mappings are source-agnostic -- if the source provides the needed properties, Block Bindings can use the mapper to assign them to the block's attributes without requiring further knowledge of the source. OTOH, args are meant for the source -- it's totally up to the source what information it accepts, and what it returns based on that information.)

In particular, for __default, including a new property map makes perfect sense to me. It's a special case, so it has different requirements 👍🏻

I'm still debating if the above format should transform into

{
	"alt":{"src":"core/post-data","args":{"key":"featuredMedia.alt_text"}},
	"id":{"src":"core/post-data","args":{"key":"featuredMedia.id"}},
	"title":{"src":"core/post-data","args":{"key":"featuredMedia.title.rendered"}},
	"url":{"src":"core/post-data","args":{"key":"featuredMedia.source_url"}}
}

or into something different 🤔

The problem is that sources are pretty much free in what args they accept, whereas the "destructuring" would happen at a source-agnostic level; so how would it know that it's the key that it needs to modify to include the "field" (e.g. featuredMedia.alt_text)?

Jotting down some more thoughts on this.

• I'm pretty much convinced that the core/post-data source should return a post's featured image as an object.

• The question is what kind of shape that object should have. It could be modeled after what the REST API returns for a post's featured image.

• WordPress functions that deal with (featured) images, e.g. get_the_post_thumbnail_url, accept an image indicating the desired image size (e.g. as a slug such as medium or large). In the world of blocks, this size (or resolution, really) can be set from an image block's block inspector.

• While it's possible to pass arguments to a Block Bindings source, there's a semantic awkwardness in having {"metadata":{"bindings":{"url":{"src":"core/post-data","args":{"key":"featuredMedia","size":"medium"}}}}}, as it's not clear if the size argument is meant to be understood at source level, or at field level only. In this example, it's the latter; it doesn't make sense to pass a size argument when requesting a post's title or publish date. (Even other subfields of the featured image, such as the alt text and ID, don't require a size argument.)

• Going back to the shape of image objects, if we draw inspiration from the REST API, we notice that rather than allowing to provide the size arg as a query arg to the posts endpoint, it simply includes a list of all sizes, leaving it up to the consumer to select whichever size they're interested it: