Adds support for async react renders for admin extensions

[thomas-marcucci]

Background

As per this comment in https://github.com/Shopify/ui-api-design/issues/227 we want to lift where an extension can fetch data to the extension callback

Solution

This solution mirrors the implementation from checkout .

🎩

You can try out my spin instance which has both async and sync rendering react and js extensions, lemme know if my dev server isn't running.
https://admin.web.arbok.thomas-marcucci.us.spin.dev/store/development-store-1/products/2

Otherwise if you want to test it on your own:
spin up checkout-ui-extension-dev
git clone git@github.com:Shopify/ui-extensions.git
cd into ui-extensions/packages/ui-extensions and yarn link
cd into ui-extensions/packages/ui-extensions-react and yarn link
cd into ui-extensions root and yarn build

create an app and generate an admin block extension
cd into your extension's folder and yarn link @shopify/ui-extensions and yarn link @shopify/ui-extensions-react
change the render function in your extension to be be async

export default reactExtension(TARGET, async (api) => {
  return <App />;
});

Now yarn dev and open up the extension preview. It should work as normal. If you throw an exception it should show in the extension's place. If you throw an exception in the render, it should be swallowed and the extension will render its default version (extension name as title and empty content).

Checklist

• I have 🎩'd these changes
• I have updated relevant documentation

[lemonmade]

Instead of a union of function types, can we change the return type to be a union (ReactElement<any> | Promise<ReactElement<any>>?

[lemonmade]

In Checkout's version of this registration function (https://github.com/Shopify/ui-extensions/blob/unstable/packages/ui-extensions-react/src/surfaces/checkout/render.tsx#L44-L62), we kept the new Promise wrapper, so that we could resolve the promise only in the post-rendering callback React gives us. I think we should match that implementation here.

[cpeddecord]

🎩'ed with your extension code and some validation code as well, code matches checkout's implementation less the error boundary, not sure if that's needed now or if we should follow up.

[lemonmade]

Checkout awaits this, which I personally like a little better. But it ends up working out to the same thing for the caller of this function, so it's up to you if you'd prefer to match or not.

[thomas-marcucci]

Good catch! I didn't intend to leave it with the return. I was playing around with it and didn't catch it when I was putting it back

[jamesvidler]

Nit: is this really a minor change or a patch? I would argue that its more of a small change (patch) to an existing feature of rendering extensions.

[thomas-marcucci]

You're right! The tool made me think I had to select major or minor lol