Prices based on customizable attributes that aren't tied to a variant

[guyathomas]

Crosspost from discord

Problem Statement

I'm trying to determine the price of a variant based on user-specified attributes ( width and height of a product). Making a variant for each dimension is not practical because we'll have 4 million + variants for each given product then.

These are two similar posts that I found, neither with a resolution.

• Github Issue
• Discord Thread
• The issue is, everywhere in the medusa core code there is an assumption that a variant will only hold 1 price ( scoped to user group, region, etc... ). But I need a way to control the pricing outside of creating a new variant.

Proposed Solution

I want to build this in a way so that it can be contributed to the core package ( I'm happy to make these changes ) so I would love feedback on the below implementation, or ideas for other designs.

When adding a line item, the client will send the customizations as metadata ( or maybe another field name to keep metadata out of price calculations )
medusa/packages/medusa/src/services/pricing.ts commonly makes an assumption that the pricing for a given variant will be unique. We could add methods that would support the calculation of a single variant + the customizations provided. The pricing service would still export the existing methods to maintain backward compatibility.
These customizations would then be provided to the PriceSelectionStrategy, which individuals could then use to implement their custom pricing logic.
From here, I see two main options for devs. 1. Maintain a price list with the Override configuration that can include the option fields that correspond to a particular price ( we'd still end up with a lot of price list entries, but seems easier to maintain ), or 2. In the PriceSelectionStrategy just chose to augment the price with their external logic, now that they are provided the customization fields.

Use Cases / Requirements

Width * Height dimensions determine the pricing of curtains. This impacts price.
A text field, that determines the engraving on a product. This would not impact price.
A reference to another product that is to be included in this order. i.e. Curtains that have the motor product, could include the FeatureVariant ID of the correct product and having the pricing taken from there. This impacts price

[srindom]

A possible solution would be to have a custom approach to generating line items and setting the unit price instead of maintaining a list of prices anywhere. The LineItem model has a unit_price field that you can set to whatever value you want in the service layer, so if you override api/store/carts/add-line-item.ts you can add your logic to calculate the price. It would look something like:

const generatedLineItem = await lineItemService.generate(...)
generatedLineItem.unit_price = await myCalc(metadata.width, metadata.height)

// save line item

This is a simplification, but curious to hear if you think this is directionally something that could work and then we can brainstorm further.

[guyathomas]

Thanks for the input! I found this last night too I'll be exploring it more today. The good thing about using the line_item field is that I found the LineItem service will treat each addition as a new line item - rather than incrementing the quantity for the line item with the same variant_id.

[guyathomas]

After looking into this I found a few fallbacks to the approach. When the PriceSelectionStrategy is involved, it has a tendency to override the unit price. Would the guidance be to override that strategy to return an empty map?

• Cart Example - This calls the PriceSelectionStrategy to get the variant pricing and overrides the unit_price.

One thought that I have is that it seems like having the PriceSelectionStrategy as the single source of truth for price calculations would be good since it's used throughout the app, but the main problem is it depends on every variant being the same price. Is there any consideration to call the PriceSelectionStrategy individually for each LineItem, rather than in batch?

[guyathomas]

One additional note, it looks like handleAddOrUpdateLineItem already accepts a bunch of values to be passed to LineItem. Adding support for unit_price there would allow others to leverage this strategy, although we'd maybe want to hold off until it's solved end to end.

[guilhermecomum]

Any updates? @guyathomas did you find a solution?

[trnc-ck]

Any update on this? We'd need to implement prices for m2, m3 etc.

[hmartiins]

Any updates here?