Removes ability to add configurable items to cart until options are chosen

[supernova-at]

Description

This PR disables the "Add to Cart" button on configurable product description pages (PDPs) until all product options have been selected.

Related Issue

Closes #640 .

Verification Steps

Configurable Products

1. Select a configurable product (ex: https://magento-venia-concept-cj55l.local.pwadev:8582/valeria-two-layer-tank.html).
2. See that the "Add to Cart" button remains disabled until you make selections for each product option (color, size, etc.).

Non-Configurable Products

1. Select a non-configurable product (ex: https://magento-venia-concept-cj55l.local.pwadev:8582/augusta-necklace.html).
2. See that the "Add to Cart" button is always enabled.

How Have YOU Tested this?

I loaded up a configurable and non-configurable product, as described above.

yarn test passes.

Screenshots / Screen Captures (if appropriate):

Proposed Labels for Change Type/Package

• major (e.g x.0.0 - a breaking change)
• minor (e.g 0.x.0 - a backwards compatible addition)
• patch (e.g 0.0.x - a bug fix)

Checklist:

• I have updated the documentation accordingly, if necessary.
• I have added tests to cover my changes, if necessary.

Further Details / Risks / Notes / Etc.

This is perhaps the simplest solution to this problem. Some other options would be:

Client-side, per-field Validation

Other forms in the app (ex: Address Form) have the ability to perform client-side, per-field validation and show error messages inline on the form.

Unfortunately the PDP would need to be heavily refactored to allow for this, and a solution for the color swatches would need to be included as part of this (changing them to radio buttons instead of actual buttons).

Why I didn't go this route:
We would still want to stick to Venia's precedent and pattern of not enabling the "submit" button of the form until all required fields are filled out, and since there is no additional client-side validation on top of this field was filled in, the refactor seemed to be too much work for not enough payoff.

Edit: turns out this isn't much of a precedent or pattern. The checkout flow doesn't enable the submit button until billing, payment, and shipping are filled in but other forms have their submit buttons enabled and hooked up to client-side validation first.

Capturing the Error in Redux

Currently our backstop reducer handles the error from the server that results from attempting to add a configurable item to your cart without specifying options.

Ideally, the cart reducer handles this itself and passes the error back up to the UI (via Redux and mapStateToProps) so that the UI can show a nice, in-context error message.

Why I didn't go this route:
By disabling the "Add to Cart" button until all options are selected, we sidestep this problem.

Because client-side validation can be circumvented, some consideration should be given to the question of "what happens if the call to the server is made some other way?", in which case the backstop reducer would still kick in and the original issue would persist.

But I don't think solving for this case is worth it: if someone intentionally sidesteps our UI to make a server call, they shouldn't expect a nice clean UI if it fails.

[vercel]

This pull request is automatically deployed with Now.
To access deployments, click Details below or on the icon next to each push.

[coveralls]

Coverage decreased (-0.09%) to 76.458% when pulling 5063da3 on supernova/640-configurable_product_error into 9afa103 on develop.

[tjwiebell]

Have a suggestion for improvement, but this would be fine as-is. Merge away if you'd prefer not to introduce __typename into the mix.

[supernova-at]

PR Updated:

• Extracts out all isProductConfigurable logic to one utility function
• Updates appropriate graphql queries to explicitly ask for __typename