Skip to content
New issue

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

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

Already on GitHub? # to your account

Requesting price summary fragment in shipping info mutation. #2445

Merged
merged 9 commits into from
Jun 3, 2020

Conversation

revanth0212
Copy link
Contributor

@revanth0212 revanth0212 commented Jun 1, 2020

Description

The price summary is not updated on submitting shipping information on the checkout page. This is because the price summary is not being fetched in the mutation result.

Solved by adding price summary fragment to shipping information mutation.

Related Issue

Closes PWA-614

Verification Stakeholders

@tjwiebell

Verification Steps

  1. Go to the deployed app's checkout page.
  2. Update the shipping address to a state that has no tax (Texas). There should be no tax section in the price summary.
  3. Update the shipping address to a state that has tax (California). There should be a tax section in the price summary.

@fooman mentioned there is a setting in the admin panel to perform tax calculation based on billing address instead. @dpatil-magento when you are testing, try to check for that option as well. The code has logic to render tax changes on billing address change as well.

Screenshots / Screen Captures (if appropriate)

Lone Star State (No Tax)
image

Golden State (😮 Tax)
image

Checklist

No tests needed. It is a GQL update.

@revanth0212 revanth0212 added the version: Patch This changeset includes backwards compatible bug fixes. label Jun 1, 2020
@PWAStudioBot
Copy link
Contributor

PWAStudioBot commented Jun 1, 2020

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-614.

Generated by 🚫 dangerJS against 06608bf

@devops-pwa-codebuild
Copy link
Collaborator

devops-pwa-codebuild commented Jun 1, 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-2445.pwa-venia.com : LH Performance Expected 0.85 Actual 0.58, LH Best Practices Expected 1 Actual 0.92
https://pr-2445.pwa-venia.com/venia-tops.html : LH Performance Expected 0.75 Actual 0.36, LH Best Practices Expected 1 Actual 0.92
https://pr-2445.pwa-venia.com/valeria-two-layer-tank.html : LH Performance Expected 0.8 Actual 0.51, LH Accessibility Expected 0.9 Actual 0.89, LH Best Practices Expected 1 Actual 0.92

@fooman
Copy link
Contributor

fooman commented Jun 1, 2020

It is possible to configure the back-end to calculate tax based on billing address. Would it make sense to add the same PriceSummaryFragment to the set billing address mutation?

Copy link
Contributor

@supernova-at supernova-at left a comment

Choose a reason for hiding this comment

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

It makes sense that we want the PriceSummaryFragment included in the SET_GUEST_SHIPPING_MUTATION mutation but not in the GET_SHIPPING_INFORMATION query.

@supernova-at
Copy link
Contributor

It is possible to configure the back-end to calculate tax based on billing address. Would it make sense to add the same PriceSummaryFragment to the set billing address mutation?

Thanks for pointing this out; I would say yes. If we find that we're overfetching and that is problematic, we can find a way to conditionally include the fragment based on the back-end configuration.

@jimbo
Copy link
Contributor

jimbo commented Jun 2, 2020

It is possible to configure the back-end to calculate tax based on billing address. Would it make sense to add the same PriceSummaryFragment to the set billing address mutation?

Good callout. I could see how it would make more sense to have it configured that way, too.

@revanth0212
Copy link
Contributor Author

revanth0212 commented Jun 2, 2020

It is possible to configure the back-end to calculate tax based on billing address. Would it make sense to add the same PriceSummaryFragment to the set billing address mutation?

Nice point @fooman. I have included the fragment in the setBillingAddressMutation as well and try to set the billing address state like Texas to remove the taxes but unfortunately, the backend didn't recognize that. I will include the fragment so if the backend supports it, you should see the tax update on billing address change.

@jimbo @supernova-at any thoughts?

image

jimbo
jimbo previously approved these changes Jun 2, 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 now. Let's let QA have a shot at it. 👍

supernova-at
supernova-at previously approved these changes Jun 2, 2020
@dpatil-magento
Copy link
Contributor

@revanth0212 Zero checkout flow breaks!

  1. Add Emilia Cropped Lace Top product to cart .
  2. Go to checkout and enter Texas address.
  3. Select Free Shipping
  4. Apply gift card 0BPAZOGI82B8 , no payment required as order total is < gift card amount.
  5. Now edit shipping address to California.

Issue - Even though order total is greater than gift card amount, payement module still stale.
(and vice-versa, if CA address entered first then changed to TX.)

image

@revanth0212
Copy link
Contributor Author

@revanth0212 Zero checkout flow breaks!

  1. Add Emilia Cropped Lace Top product to cart .
  2. Go to checkout and enter Texas address.
  3. Select Free Shipping
  4. Apply gift card 0BPAZOGI82B8 , no payment required as order total is < gift card amount.
  5. Now edit shipping address to California.

Issue - Even though order total is greater than gift card amount, payement module still stale.
(and vice-versa, if CA address entered first then changed to TX.)

Nice catch @dpatil-magento.

There are 2 things we have to note here.

  1. We have to fetch available payment methods when the shipping address change, which I will add in the next commit. This brings me to another question, should we re-fetch available shipping methods as well, because shipping methods can change when the shipping address has changed. @jimbo @supernova-at should I fetch shipping methods as well along with payment methods in the mutation response?
  2. When I added the GQL fragment to fetch the payment methods on shipping address change, you can see that the Free payment method is still available even though the total is not 0, but when I refresh the page, the GQL query on the same cart id returns a diff response for available payment methods (does not return free). That seems like a bug in GQL.

On shipping address submit:
image

On refresh:
image

@revanth0212 revanth0212 dismissed stale reviews from supernova-at and jimbo via 96555dd June 3, 2020 17:59
supernova-at
supernova-at previously approved these changes Jun 3, 2020
@supernova-at
Copy link
Contributor

@jimbo @supernova-at should I fetch shipping methods as well along with payment methods in the mutation response?

Just to update here, that fragment should exist already and the list of available shipping methods should already update on shipping address change.

@revanth0212
Copy link
Contributor Author

@jimbo @supernova-at should I fetch shipping methods as well along with payment methods in the mutation response?

Just to update here, that fragment should exist already and the list of available shipping methods should already update on shipping address change.

Yeah, you are right. Found it. Thanks Andy.

tjwiebell
tjwiebell previously approved these changes Jun 3, 2020
Copy link
Contributor

@tjwiebell tjwiebell left a comment

Choose a reason for hiding this comment

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

Approving, but spotted an odd linter line that should be corrected. Please take a look.

}
}
${AvailablePaymentMethodsFragment}
`;

/* eslint-disable graphql/required-fields */
Copy link
Contributor

Choose a reason for hiding this comment

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

Not related to this PR, but couldn't help but notice this rule get disabled, and never re-enabled. This is probably preventing any file after this from being properly linted. Consider fixing in this scope, or please create a followup task to resolve this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch Tommy. Havn't noticed that. Also looks like my linter is not working 😓 . Fixed it in 06608bf

@@ -1,5 +1,8 @@
import gql from 'graphql-tag';

import { PriceSummaryFragment } from '../../CartPage/PriceSummary/priceSummaryFragments';
Copy link
Contributor

Choose a reason for hiding this comment

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

On line 28 in this file too, I think we intended to turn the lint rule back on.

@revanth0212 revanth0212 dismissed stale reviews from tjwiebell and supernova-at via 06608bf June 3, 2020 21:36
@dpatil-magento dpatil-magento self-requested a review June 3, 2020 22:13
@dpatil-magento dpatil-magento merged commit e7d2c68 into develop Jun 3, 2020
@dpatil-magento dpatil-magento deleted the revanth/checkout_page_price_update_fix branch June 3, 2020 22:13
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
pkg:venia-ui version: Patch This changeset includes backwards compatible bug fixes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants