search

magento / architecture

A place where Magento architectural discussions happen
274 stars 154 forks source link

[Draft] Catalog storefront, product options and variants management #411

Closed akaplya closed 3 years ago

akaplya commented 4 years ago

Solution

This document proposes to review options and variants management approach to :

tariqjawed83 commented 4 years ago

Hi - based on reviewing shopify, big-commerce, commercetools, magento and salesforce in detail, I have following suggestion for truly headless product schema.

  1. Can we just use Product Template with multiple Attributes?
  2. Each Attribute will have their Type; for instance boolean, text, number/money, datetime, reference to other objects, list.
  3. Constraint on Attributes will help define the Variant possibility and the field can have no constraint also; for instance "Unique for each variant", "Same for all variants", "Unique for combination".
  4. Eliminate the need for Variant Matrix by using Attribute Constraints only, which helps to validate the new variant; at the time of creation of variant.
  5. Product Variant will act a concrete product, based on Product Template only, No need for selecting options, make it simple.
  6. Product Variants will hold concrete values of same attributes defined in Product Template. These variants will be created by choice only, not pre-populated or created; we will just validate the variant based on attribute constraints defined above.
  7. Don't think product options just for variants; think of them as product attributes in general; yes they can have constraints but if no constraint defined, it should be treated like normal field.
  8. Eliminate anything related to UI / User Experience from Product Template / Variant Definition, since it should be completely headless. All we need to do is define the attribute types in such a way that they could store any type of UI field; like file reference, text input, boolean, list etc. (as defined above).
  9. Pricing and Inventory can be reference of Product Variant itself, since that is a concrete type; but this can be flexible, some Product Variant can derive their price or inventory from Product Template, and some optionally use their own.
akaplya commented 3 years ago

should be merged as is, since the last conversation the proposal was mostly implemented. So it has more sense merge it, and apply changes on top of the document if required.