Purchases: Reduxify Stored Cards on Secure Payment page #6710
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stephanethomas
added
[Status] Needs Review
| @@ -95,7 +98,7 @@ const Checkout = React.createClass( { | |||
| props = props || this.props; | |||
|
|
|||
| analytics.tracks.recordEvent( 'calypso_checkout_page_view', { | |||
| saved_cards: props.cards.get().length, | |||
| saved_cards: props.cards.length, | |||
There was a problem hiding this comment.
I wonder if we shouldn't record this event only when the list of cards have loaded from the server, otherwise we might just provide stale data to Tracks. This is how it currently works though.
stephanethomas
force-pushed
the
update/reduxify-checkout
branch
from
7c7ddb0
to
eb4f30e
Compare
|
Product 👍 Thanks the detailed notes and comments! |
stephanethomas
force-pushed
the
update/reduxify-checkout
branch
from
eb4f30e
to
d0f3a74
Compare
3 tasks
stephanethomas
force-pushed
the
update/reduxify-checkout
branch
from
d0f3a74
to
ef09216
Compare
drewblaisdell
force-pushed
the
update/reduxify-checkout
branch
from
ef09216
to
57d5970
Compare
|
Code 👍 I also tested this, and updated the last commit to remove a misplaced space here (not introduced by this PR). |
drewblaisdell
added
[Status] Ready to Merge
and removed
[Status] Needs Review
… during mounting This is to avoid having to explicitly fetch stored cards when a user uses a new credit card during purchase or adds a new payment method to an existing purchase - as otherwise the Billing History page will display stale information if it was accessed by the user beforehand during a same session. It indeed doesn't really make sense to perform this call in these two use cases since there is little chance that the user visits the Billing History page afterwards. It seems to be more effective to fetch stored cards every time the user access this specific page.
…story page only if no data has been fetched ever
…stored cards This also removes the singleton that was used originally to get this data.
stephanethomas
force-pushed
the
update/reduxify-checkout
branch
from
57d5970
to
4aee69d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is a follow-up of #6613, #6628, and #6665 that updates the
Secure Paymentpage in the checkout to use the global state tree to manage credit cards (stored during previous purchases or when a user added a new payment method to an existing purchase) instead of the old singleton:Testing instructions
git checkout update/reduxify-checkoutand start your server, or open a live branchBilling HistorypageManage Your Credit CardssectionSecure PaymentpagePaybuttonAdditional notes
This pull requests also updates the query component for stored cards to fetch data as soon as it is mounted, and only in that case. This is to avoid having to explicitly fetch stored cards when a user uses a new credit card during purchase or adds a new payment method to an existing purchase - as otherwise the
Billing Historypage will display stale information if it was accessed by the user beforehand during a same session.The logic here is that it indeed doesn't make sense to perform this call in these two use cases since there is little chance that the user visits the
Billing Historypage afterwards. It seems to be more effective to fetch stored cards every time the user access this specific page, which I assume doesn't receive lots of traffic.Reviews
@Automattic/sdev-feed