Contextual price for ExpandedItems in Expand Operation

Functions
1

Is it possible to get the contextual price for an Expanded Item in the Expand Operation?

Contextual price being the current price of the product based on the users Market and/or Company/Price List.

In the Price Per Component example app - a singular price is saved within the metafield for the parent product:

bundledComponentData: {
  value: JSON.stringify([
    { id: "gid://shopify/ProductVariant/2", price: "25.00" },
    { id: "gid://shopify/ProductVariant/3", price: "25.00" },
  ]),
},

This solution only works for the products home price.

It would be possible to convert this with presentmentCurrencyRate, but this would not account for % increase/decrease, or fixed price settings for Markets.

It would be possible to save all prices from all Markets but this becomes unrealistic/unwieldy at scale.

The example also doesn’t account for B2B Prices.

Merge is not suitable
Merge might be suitable for some circumstances, but I’m speaking directly to this example, and the use of Expand and Price Per Components.

3 Likes
2

Just bumping this one in case Shopifolk are around to provide a response now.

1 Like
3

I agree with your concerns about obtaining the “contextual price” for expanded items. From my understanding, the core issue you’re highlighting is the inability to efficiently retrieve the current set price of sub-products included as components in the Expand operation.

Currently, apps can only provide store owners with two types of setting interfaces:

  1. A discount percentage applied to the entire component
  2. Input fields for fixed amount values for each component

These options work in some cases, but they have limitations. For instance, when a store owner changes the price of a product, they might want to update the price settings for all components referencing that product.
However, with the current system, they would need to manually adjust each component’s price setting individually, which can be time-consuming and tedious.

If we could retrieve the “current set price,” it would allow for a more flexible app interface, enabling features like:

  • Discount values based on the current price
  • Percentage discounts from the current price

This would streamline management by making it possible to automatically reflect base price changes across all related bundles.

Currently, there are two main approaches to track “component price based on current prices”:

  1. Using a metafield in the cartTransform itself to aggregate all current prices - simple but limited by the 10,000 byte restriction.
  2. Storing the current price of component products in the parent product’s metafield - more flexible but requires complex bulk operations to manage rate limits when updating multiple products.

Both methods have drawbacks, especially for large stores or complex pricing structures.

A native Shopify feature to directly retrieve the “current set price” in the Expand operation would significantly enhance the flexibility and efficiency of price management for app developers.

I apologize if I’ve misinterpreted any part of your post. Please correct me if I’ve misunderstood any aspects of your concerns or the current Shopify functionality.

4

Currently, there are two main approaches to track “component price based on current prices”:

  1. Using a metafield in the cartTransform itself to aggregate all current prices - simple but limited by the 10,000 byte restriction.
  2. Storing the current price of component products in the parent product’s metafield - more flexible but requires complex bulk operations to manage rate limits when updating multiple products.

This is absolutely part of the issue.

In the example app and docs, the component prices are stored in the parent products metafield. This means this list of prices can get very large, very quickly if a bundle has hundreds or thousands of potential component products…

This has a knock on effect beyond the 10kb cart transform limit, as it also places immense pressure on the instruction limit too. This exponentially increases if a user adds multiple bundles to cart.

It becomes even less feasible to store contextual prices for all the potential price values across Markets and B2B price lists.

5

I tried the following approach:

When creating a map of ProductIds and current prices, I shortened the productIds to fit as many as possible within the 10,000-byte limit. For example, “gid:shopify//ProductVariant/01234…” was shortened to “01234…”.

In this case, I generously estimated 20 digits for the “01234…” part and another 20 digits for the current price. This allowed me to create about 250 key-value pairs (10000 / 40 = 250). I then split the metafield keys into multiple parts like “prices_1”, “prices_2”, etc. When I ran the cart-transform, it worked well in my specific case.

However, as you pointed out, this doesn’t solve the issue of instruction count limits, and the size restriction still remains a fact.

Therefore, instead of this method, I plan to adopt an approach where I set “only the necessary product prices” for each parent product. Furthermore, in my case, I’m planning to increase the allowable number by converting the ProductVariantId to an index number.

Please note that this text has been translated, so there might be some parts that are difficult to understand clearly.