Is your feature request related to a problem? Please describe.
I'm trying to build a transform from a WooCommerce block that displays a product using API data into the newly updated Cover block. Unfortunately, in the source block I only have the product ID attribute, and need to get the data for Cover's innerBlocks via an API request. You can see the start of this at this PR, currently using a mocked product: woocommerce/woocommerce-blocks#490
Describe the solution you'd like
It would be great if transforms could support async functions, so that I could write something like:
transform: async ( { productId } , innerBlocks ) => {
const product = await apiFetch( {
path: `/wc-blocks/v1/products/${ productId }`,
} );
// now I can use the values in `product` to populate some
// innerBlocks in the Cover block.
But that makes switchToBlockType more complex.
Describe alternatives you've considered
My best alternative so far would be to populate some attributes for the product values I need (name, description, image src, etc), but these would not actually be editable attributes - the block would always have to pull from the product in case the source product has been updated. So that seems like an anti-pattern for attribute use.
Is your feature request related to a problem? Please describe.
I'm trying to build a transform from a WooCommerce block that displays a product using API data into the newly updated Cover block. Unfortunately, in the source block I only have the product ID attribute, and need to get the data for Cover's innerBlocks via an API request. You can see the start of this at this PR, currently using a mocked product: woocommerce/woocommerce-blocks#490
Describe the solution you'd like
It would be great if transforms could support async functions, so that I could write something like:
But that makes
switchToBlockTypemore complex.Describe alternatives you've considered
My best alternative so far would be to populate some attributes for the product values I need (name, description, image src, etc), but these would not actually be editable attributes - the block would always have to pull from the product in case the source product has been updated. So that seems like an anti-pattern for attribute use.