Enhancement — consider displaying/linking variants as relation instead of matrix

[oadslug]

This is a general UI and performance issue. I currently have a client that has some products with 45+ variants. And each variant has some 30+ fields, which when you get beyond selling t-shirts isn't really that uncommon. (i.e. think of sports equipment or any other product that has lot's of associated feature specs, etc.).

In terms of performance, I have started running up against max post variable limits in php when saving some of the products. I have fixed this by upping the limit in php config, but not ideal.

In terms of UI it is also getting a bit unweildy. First it is a bit difficult to scroll through 40+ variants when they are all open. Collapsing the variants helps a lot of course (although would be great to have a 'collapse all' or 'collapse selected' button/option).

It would also be great to have more than one tab available on variants, to organize things a bit and to support giant fields (think SEO plugin fields).

In general, for all of the above reasons, it might be worth considering linking variants to products using a relation style field, instead of a matrix style field (or even better a relation table so that you could display data columns, sort, search, etc — something that I haven't really seen much in the craft world.). This would allow the user to view, edit, save variants via the product or via a seperate 'variants' section independent of the product. Obviously there is an issue with enforcing the variant field layout when created independent of the product, which I'm not sure what the solution is (perhaps a drop down 'create new producttype variant' and a required 'product' relation field). Anyway, some things to consider in your future design plans.

(Fyi... I am transitioning a site from OctoberCMS where I have built a custom product/variant UI using a relation table, which works great and was otherwise laid out in a very Craft like way. If it would help to see a screenshot, let me know.)

[lukeholder]

What kinds of products have 40+ variants? What's the use-case there? Also, if each variant has 30+ fields, what information is so specific to the variant that couldn't be on the product fields layout? I can see maybe 10 things that differ between variants, but 30+? Interested to find out.

[oadslug]

Variant criteria: Color (5+ colors), Orientation (portrait/landscape), Format (8.5x11, A3, A4, etc, and every other common paper size, can be as many as 14), and depth (.5", 1", 2"). The largest 1 has 45 variants.

Additional fields: internal dimensions (LxWxH); external dimensions (LxWxH) — which is different then shipping dimensions used for calculating shipping; hero image; images; imprinting template; compatible variants; description; capacity; includes; internal price mapping (list, map, net, etc); out of stock, available on date, and UPC code. (I believe 26-30 in total — I would have to look through all the product types to be certain). And at some point, would like to add some additional SEO meta-data fields.

There are also a number of product add-ons/customization options, but this has been abstracted to keep the variant count low (as many as 4 customizations, with expedited option, which could potentially swell the variant count x8, if not abstracted). This is done by 'adding-on' other variants as separate line-items transparently, and using lineItem options data to maintain parent-child relationships, sync quantities, calculate lineItemBundle totals, etc throughout the order process, invoices, etc.

Anything that can be abstracted, or moved to the product level has been.

While the variant count is a little unusual, I don't think that number of fields is at all. I often see variants with very large data sheets (even a simple food product has nutritional data, ingredients, etc, which is 20-30 fields).

[lukeholder]

Thanks for the info and feedback, hoping to see others 👍 this issue and see the support for this as a request. Thanks.

[23d1]

Curious; do you use some sort of multi-add functionality to tack on line items? Is that functionality available in commerce 2 as of now, and if so, how have you implemented it (roughly speaking)?

[oadslug]

@23d1 Basically, when a user chooses any variant option (including any 'add-ons' that are technically different product SKUs entirely) then I AJAX load the 'variant' detail, which includes the primary variant and any add-on variants. At the same time, I render a bunch of custom hidden fields to the form (like purchasables[0][options][groupId], purchasables[3][options][parentId], purchasables[1][options][useParentQty]) to maintain relationships throughout the system, and to keep quantities in sync (i.e. if user increases qty on parent item, I also increase qty on child items, etc). To make life even more complicated some items are 'one-time set up fees' which do not increase in quantity, thus the 'useParentQty' variable. When the user clicks add to cart, it adds all the variants in the form to the cart (with their respective hidden option variables). And when I display the order (for cart, invoices, etc.) I can group items using the custom option variables, and calculate a group total price, using a fancy loop to check for parentId, etc. Likewise, if the user removes an item (bundle), I remove any line-items matching the 'groupId' via js; and if they change qty, I change any line-items matching 'groupId' that have 'useParentQty' via js. Amazingly, it all works!

[23d1]

@oadslug Whoa! That's a helluva process. Seems like this is something that should be easier to do. I've been looking at implementing similar functionality on a current build, but really want all that to happen in the Craft/Commerce/template code, rather than surrender too deep into JavaScript (which is already a pretty big part of the build for choosing type+color from within the same product, although "type" in this case could be unlimited stock). Anyway, thanks for the breakdown.

[oadslug]

@23d1 Although it sounds complicated, it's really not. Almost everything is done in twig, with the exception of removing items and updating quantities. And those are literally 2-3 lines of javascript. The rest just submits/reloads the form.

var updateLineItemGroupQuantity = function ($element) {
    var qty = $element.val();
    $element.closest('.js-line-item-group').find('.js-match-qty').val(qty);
    updateCart();
 };

var removeLineItemGroup = function ($element) {
    $element.closest('.js-line-item-group').find('.js-remove').val(1);
    updateCart();
};