Sirgalleto/add location modal for order routing extensions

[sirgalleto]

Background

Add a new extension target for OrderRouting admin.settings.order-routing-rule.render and its LocationList component.

Solution

1. Create a new remote component definition for the LocationList and exclude it from AllComponents since it should only be allowed in the OrderRouting extension target. Add docs + examples.
2. Create a new target with AllComponents + OrderRoutingComponents available

🎩

Tested with our UI extension

Checklist

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

[jbalsas]

Didn't 🎩 (is this something we could do through yarn link or yalc, perhaps?), but code makes sense to me!

[MitchLillie]

Are these docs ready to ship? Once this change gets merged in to the unstable branch, someone might generate the docs and cause this API to be published.

[jbalsas]

Not at all 😓

[MitchLillie]

We should just remove these docfiles until we're ready to publish

[jbalsas]

Will do! I think we weren't super sure what was the process here so this was a bit of a shot in the dark. If I understand correctly, we should:

• Commit the types so they get to unstable
• Work on the docs separately and merge them when ready

Would that be the expected workflow?

Is there a timeline as to when unstable becomes stable? Is there any sort of deadline we'd want to hit?

[jbalsas]

We'll also need to bring in saveMetafields from https://github.com/Shopify/web/pull/108366 once ready.

@olavoasantos, @MitchLillie, could you walk me through how would we accomplish that? Is this supposed to be augmented somewhere else for the plugins?

[MitchLillie]

I think you just need to add whatever methods/properties that plugin provides developers to the typedef here.

[jbalsas]

Yeah, makes sense... @olavoasantos suggested (or so I understood) typing them here and then consuming the types in web from here. So I'll add that.

cc @cpeddecord , would you say our types are solid enough to get them over here?

[cpeddecord]

I'd prefer for that PR to land before moving the types over, but otherwise I'm confident the public API won't change

[jbalsas]

Yeah, makes sense, I'll just prep over here but wait for it to land before pushing this!!

[jbalsas]

PR should be good to go now, waiting on https://github.com/Shopify/web/pull/108366/files and a potential ✅ from @MitchLillie here before going forward with this.

[jbalsas]

@olavoasantos, @MitchLillie, there's still no easy way to expose this to the extensions (nor to web, for that matter).

I managed to resolve the type through some TS gymnastics like:

type ExtractElementType<T> = T extends readonly (infer ElementType)[]
  ? ElementType
  : never;

type ApiForRenderExtension = ReturnType<
  typeof useApi<'admin.settings.order-routing-rule.render'>
>;

type ExtractMethod<T extends keyof ApiForRenderExtension> =
  ApiForRenderExtension[T];

type SaveMetafields = ExtractMethod<'saveMetafields'>;

type MetafieldChange = ExtractElementType<Parameters<SaveMetafields>[0]>;

I like how the types are clean and properly derived from useApi(TARGET), but wondering if we'd want to expose some of the helpers that already exist in this repo as well in order to make this slightly simpler... or to allow for some sort of additional types 🤔

Normally one wouldn't need this, but as things grow, types might be needed in files that do not call useApi making some of this necessary 🤔

[MitchLillie]

I like how the types are clean and properly derived from useApi(TARGET)

Couldn't you just export and import these types directly? For example you're exporting LocationProps already. I know this would make them not-perfectly derived from useApi, but it would make the extension code simpler.

[jbalsas]

Yeah, but it would be the only ones... we're currently not exporting anything anything else, not even the ApiForRenderExtension and other useful types that already exist, to I don't see how it would make sense to directly export such a dedicated type.

It might be fine in most cases, so I'm fine with the ocasional additional complexity for now, just flagging it so we can keep this in the radar for future improvements!

[MitchLillie]

Yep, makes sense. This would be a good enhancement. I created #1525

[cpeddecord]

can we hold on merging this? We may need to update the saveMetafieldsPlugin's public API to match checkout-web's

https://shopify.slack.com/archives/C04710CKFMH/p1699642277565379

[jbalsas]

can we hold on merging this? We may need to update the saveMetafieldsPlugin's public API to match checkout-web's

Sure thing @cpeddecord, please just signal when ready!

[MitchLillie]

Didn't 🎩, but code looks good. It would be good to have someone 🎩 before merge, I can take a look a bit later today.

Note: Please run yarn changeset as suggested in this comment. It's required to generate our changelog properly.

[jbalsas]

@MitchLillie, @sirgalleto, @cpeddecord, I've updated the types here and 🎩 with https://github.com/Shopify/order-routing-default-function-app/pull/199

Rebuilding the consumer seems to produce the right types: