Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PWA-413] [Cart Page Edit] Price Does not get updated after changing the color/size. #2483

Merged
merged 5 commits into from
Jun 18, 2020

Conversation

tjwiebell
Copy link
Contributor

@tjwiebell tjwiebell commented Jun 10, 2020

Description

Steps -

  1. Add a configurable product to Cart and go Cart page.
  2. Go to Edit panel and switch to different color.

Expected - Price should get updated based on selection.
Actual - Price is static, user will get confused after seeing the update on Cart page.

Note - Same issue exists on Mini Cart Edit window as well but will be part of mini cart refactor?

Related Issue

  • [PWA-413] [Cart Page Edit] Price Does not get updated after changing the color/size.

Acceptance

Verification Stakeholders

Specification

Verification Steps

⬆️ Use repro steps in description ⬆️

Screenshots / Screen Captures (if appropriate)

Checklist

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

@PWAStudioBot
Copy link
Contributor

PWAStudioBot commented Jun 10, 2020

Fails
🚫 A version label is required. A maintainer must add one.
Messages
📖

Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.

📖 DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next nightly build run (assuming they are fixed).
📖

Associated JIRA tickets: PWA-413.

Generated by 🚫 dangerJS against 3927f86

@devops-pwa-codebuild
Copy link
Collaborator

devops-pwa-codebuild commented Jun 10, 2020

Performance Test Results

The following fails have been reported by WebpageTest. These numbers indicates a possible performance issue with the PR which requires further manual testing to validate.

https://pr-2483.pwa-venia.com : LH Performance Expected 0.85 Actual 0.57, LH Best Practices Expected 1 Actual 0.92
https://pr-2483.pwa-venia.com/venia-tops.html : LH Performance Expected 0.75 Actual 0.35, LH Best Practices Expected 1 Actual 0.92
https://pr-2483.pwa-venia.com/valeria-two-layer-tank.html : LH Performance Expected 0.8 Actual 0.49, LH Accessibility Expected 0.9 Actual 0.89, LH Best Practices Expected 1 Actual 0.92

jimbo
jimbo previously approved these changes Jun 11, 2020
Copy link
Contributor

@jimbo jimbo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

As our core workflows become more complicated in order to handle edges like this, let's keep an eye on it. The more types of products we support, the more strain it's going to put on talons as our only layer of abstraction; we may need to add another layer at some point.

@m2-community-project m2-community-project bot moved this from Ready for Review to Reviewer Approved in Pull Request Progress Jun 11, 2020
Copy link
Contributor

@sirugh sirugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems functional but I wasn't sure about the initial state expectations. Lets talk about it.

import { useAppContext } from '../../../../context/app';

export const useEditModal = () => {
const [{ drawer }, { closeDrawer }] = useAppContext();
const isOpen = drawer === 'product.edit';

const [variantPrice, setVariantPrice] = useState();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is undefined initially. What happens if the item in the cart is a configurable item? I know it falls back to price but could that be wrong? Perhaps we need to do the calculation here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first render for this component will have item = undefined, so it wouldn't be that easy. I could add an effect, but I didn't really see the purpose when ProductDetail already had the data it needed to render price. Instead of having to handle a bunch of different states for opening, then resetting on close, I passed this responsibility down to ProductForm.

BTW - you can only edit Configurable product right now (assuming you meant isn't a configurable item)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes, I mistyped.

What I meant was that when you first click on a product to edit the value for variant was "undefined". It seemed to render correctly regardless, but maybe that was by coincidence?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By design. I'm willing to make this change, but did want to do some validation. If I add a product to my cart that is on sale, but don't checkout until a day later when that product is no longer on sale, do I still get that product at the sale price? I don't know the answer to that, but that would be a reason to use cart price instead of variant price. There might be other use cases as well where cart price is the accurate value, and is what we want to render.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If variant price reflects product specific sales I think it's fine to only use that. Would be odd to reflect cart sales such as BOGO or <$X discounts in an edit view.

Copy link
Contributor

@jimbo jimbo Jun 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I add a product to my cart that is on sale, but don't checkout until a day later when that product is no longer on sale, do I still get that product at the sale price? I don't know the answer to that, but that would be a reason to use cart price instead of variant price.

We can assume that if a sale price expires before a shopper completes a purchase, the sale price is forfeit. If there are special cases where that's not true, someone would have to handle those cases as exceptions.

edit: Also, in general, we should use null rather than undefined as an initial value for useState().

@@ -11,16 +11,20 @@ import ProductForm from './productForm';

const EditModal = props => {
const { item, setIsCartUpdating } = props;
const talonProps = useEditModal();
const { handleClose, isOpen } = talonProps;
const talonProps = useEditModal({ item });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice you pass the item here - is that to do the calculation of the variant price on initial render? You aren't using it anymore in the talon though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I attempted your suggestion to initialize in the talon at first, but went the simple route. Will remove this prop.


const classes = mergeClasses(defaultClasses, props.classes);
const rootClass = isOpen ? classes.root_open : classes.root;

const bodyComponent = item ? (
<div className={classes.body} key={item.id}>
<ProductDetail item={item} />
<ProductForm item={item} setIsCartUpdating={setIsCartUpdating} />
<ProductDetail item={item} variantPrice={variantPrice} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

variantPrice is undefined if you open the edit modal and don't click on anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. We render cartItem price until a new variant is selected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if the item in the cart is a variant of the default, cartItem.price will be the selected variant price not the default price?

sirugh
sirugh previously approved these changes Jun 15, 2020
@tjwiebell tjwiebell dismissed stale reviews from sirugh and jimbo via 158865d June 16, 2020 15:18
@dpatil-magento
Copy link
Contributor

Went ahead and QA'ed this, looks good.

@dpatil-magento dpatil-magento merged commit c3c7775 into develop Jun 18, 2020
@dpatil-magento dpatil-magento deleted the tommy/configurable-edit branch June 18, 2020 18:12
@m2-community-project m2-community-project bot moved this from Review in Progress to Done in Pull Request Progress Jun 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

6 participants