Prices based on customizable attributes that aren't tied to a variant #4679
Replies: 3 comments 4 replies
-
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
This is a simplification, but curious to hear if you think this is directionally something that could work and then we can brainstorm further. |
Beta Was this translation helpful? Give feedback.
-
Any update on this? We'd need to implement prices for m2, m3 etc. |
Beta Was this translation helpful? Give feedback.
-
Any updates here? |
Beta Was this translation helpful? Give feedback.
-
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.
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
Beta Was this translation helpful? Give feedback.
All reactions