Global / Category Based Product Options #11910
NicolasGorga
started this conversation in
RFC
Replies: 1 comment 1 reply
-
Hey @NicolasGorga. Here is mine suggested draft approach on solving product attributes. enum AttributeUIComponent {
TYPEAHEAD = 'typeahead', // ui component with custom text but suggested values which are represented in possible value table
MULTIVALUE = 'multivalue',
UNIT = 'unit', // cantimeters, grams etc which are represented in scale table
TOGGLE = 'toggle',
TEXTAREA = 'text-area',
COLOR_PICKER = 'color_picker'
}
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I am about to start working on my approach to solve the issue outlined up next, would highly appreciate a conversation with a CODEOWNER, so as to not waste time and be aligned.
Problem Statement
By design, the Product model is related to One or Many ProductOption model, which in turn, is related to One or Many ProductOptionValue.
This implies that there are no “global” ProductOption and ProductOptionValue, so for each Product, options and option values must be defined, even if these two are shared by all or a related set of Products.
Imagine a clothing store, that for almost all of their products, a Size option with S, M and L values are needed. The admin would have to recreate over and over again this options in the Admin Panel and on the DB side, you would end up with duplication represented by following formulas:
ProductOption: products * count(distinct option) -> Example: 1000 products, 1 Size option = 1000 ProductOption entries representing same thing (Size), when it should actually be 1
ProductOptionValue: products * count(distinct option) * count(distinct option value per option) -> Example: 1000 products, 1 Size option, 3 values (S, M, L) for Size option = 3000 ProductOptionValue entries representing same thing (S, M, L Size values), when it should actually be 3
Proposed solution
Changing core Product and ProductOption
In my opinion, the problem lies in the relationship between Product and ProductOption models (One to Many). Rather, if ProductOptions are considered global (either to all products or categories, types), it should be a Many to Zero or Many.
In the previous example, one would define a single ProductOption entry: Size and 3 ProductOptionValue entries (S, M, L) for Size ProductOption.
Product A and Product B, would link to the same Size ProductOption and their ProductVariant models would in turn link to the same ProductOptionValue entries. The duplication in the DB is removed and it more closely represents the reality.
Changes in Admin Panel
The previously outlined solution, apart from the changes to core (which i don’t know the surface area it has), would need changes in Admin panel, for the create and update product page.
I would create a subsection, (like categories), for the Products section, called “Attributes” (or any other name representative enough), where one can define the Global (or category, type or any other entity that narrows the availability of the option for products related to that entity) attributes.
Then, when creating variants, the options wouldn’t be created ad hoc, but rather, have an available list of options and option values, as defined in the Attributes section.
One limitation of this, is for products that have an option / option value that no other product shares. Also, when creating the Global option, a boolean field like “is_variant_defining” should be made available, to specify if this is simply a “marker” (an attribute useful for filtering in the storefront) or, apart from a marker, it defines the product variant.
References
v1 custom attributes plugin: https://github.com/vholik/medusa-custom-attributes
This plugin mainly focuses on the "markers" part of the problem statement. It facilitates filtering from the storefront, doesn't tackle the usage of global product options / values for defining variants (doesn't solve the db duplication issues), but has really good implementations regarding the definintion of options for specific categories.
Existent feature request, but with no repercusion whatsoever in terms of core team involvement: #5119
Beta Was this translation helpful? Give feedback.
All reactions