[Feedback] Discount UI Settings improvements

Extensions
1

Hey folks,

I wanted to put down my thoughts of how/what should be done to the discount settings UI, to enable complex discounting applications to actually migrate to using the discount ui settings; this is a feedback post. This is important because discount-app-components is now/soon-to-be deprecated.

Space/UI:

Admin block extensions have a height limit of 300px, and can be further expanded. It appears that this limit has been removed specifically for discount-settings, which is great. However, the restriction of creating ‘only one card’ per resource page, makes it difficult to include complex UI, without overwhelming merchants.

I think there are two solutions to this. First is that partners use Admin action extensions to separate complex UI. Second, is to enable creating multiple cards, and potentially even adding space on the side bar.

There is currently a bug, which prevents the use of Admin action extensions.

Another example, is you may want to provide additional information/data to summary card.

Discount classes

There is currently no granular control over discountClasses, these are either set to ‘Product, Order’, ‘Product, Order, Shipping’ or just ‘Shipping’, based on if you implement both the cart and delivery targets. This removes granularity in discount combinations and would actually not be backwards compatible, with existing discount(s) that have, for example a discountClasses value of just [‘Order’].

Top level API properties

In the same vein, there are other properties on the discount, which are not available to read, but also to write. To note down some initial examples:

  • Recurring payments UI is never shown for a discount-settings-ui extension. In native discounts these are toggled by an ‘applies to’ value of ‘subscription’ (recurringCycleLimit)
  • Applies to subscription/appliesOnOneTimePurchase - I believe these are less relevant now as the latest discountAPI only lets you target cartLines, and not productVariants
  • If the discount is a manual code, or automatic code. In this case, you may want to have a field for overriding a discount message, or not, depending on the application method.

I think the API can be extended to provide the following:

Actions:

  • toggleRecurringPayments - this shows/hides the recurringPayments UI
  • applyDiscountClasses - allows you to override the default behaviour and provide a more accurate discountClasses value.
  • applySummaryChange - allows you to add additional summary data to the summary UI

Data:

  • applicationMethod - code or automatic
  • discountCodesCount - if there are additional redemption codes
  • …I’m sure there would be other useful information here

These are of course just examples, but I do think there are some fundamentally missing pieces to make a truly useful experience for merchants. I also understand that it’s completely possible to opt-out here, and build with app bridge, but there are MANY benefits in using a Shopify controlled resource here!

2 Likes
2

I’d also add that the Picker API, while usable, throws a type error when accessed while targeting a Discount UI extension. As a result, it must be used completely un-typed which is a development pain point. Resource selection is a key component of many discount configurations.

1 Like