Reusable ProductOptions

[skid]

In addition to this issue #965 I here's another idea for extending the product options: Make ProductOptionGroup a ManyToMany relation with Product. I realise that this is a more complicated endeavour, but here are the arguments:

Variants conceptually represent a different mode of the same product. These modes are most often repeatable and appear on many different products - the most notable is clothing size (s, m, l, xl). In my own case, I have pre-weighed and packaged items (300g, 350g, 400g).

When creating new products you need to input all of these every time, but the bigger problem is when developing features around variations - having a different option group for each product makes it difficult to abstract over the "Size" or "Weight' property of different products (e.g. do something all L t-shirts).

Woocommerce does exactly this - you can manage product option groups (called attributes in WC) independently of product variations.

The admin UI can be made to allow you to select a product option group, pre-populate all the options and then allow you to remove the options that your product doesn't use. This can be recorded in a JSON field in the relation table, e.g.

// Entity Product_ProductOptionGroup_Relation
{
  productId; ID, 
  productOptionGroupId: ID, 
  includedOptionsIds: ID[],
}

You can also model the current behaviour this way (ManyToMany is a superset of OneToMany).
Finally, may this behaviour could be simulated with a customField to the ProductOptionGroup entity, but I think this is maybe better suited to the core as I suspect a decent number of people might need it.

[michaelbromley]

In a very early version of Vendure it did work something like this. I changed in to the current model for the sake of simplicity - I found that the extra complexity around having to pick a subset of options for each Product was not justified by the benefit, at least in the cases I was dealing with: in our inventory we have many products which have ~70% same options, and then there is a long tail of differences which would make the shared option group huge and would then require careful curation when creating a new product based on that option group. I grant that for other inventories it would be much more straightforward and therefore would make more sense.

Anyway, for now I will not be changing the data model - that would be a breaking schema change which will only happen at version 2.0.

However, you have a very good point from a UX perspective - it is a chore to have to re-enter the same/similar options each time. It would be totally possible to improve this experience even with the current data model. E.g, when creating a new product, we could allow the admin to "copy" the option groups from an existing product. It would not share the group, a new one would be created, but UX-wise it would be similar to sharing groups.

This would still not solve the problem of being able to do something to all of a particular option, e.g. set a custom field value on all "large" sizes. Right now that would need to be done as custom code, e.g. by implementing a mutation which does a lookup based on option name and applies the change that way.

[devinova]

it would be interesting to have an options system similar to OpenCart, where besides being able to reuse the options, I have several other interesting fields such as value, type, mandatory, etc.

[michaelbromley]

@devinova this sounds like something that might be covered by this proposed feature: #627