-
Notifications
You must be signed in to change notification settings - Fork 43
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
fix(modal-checkout): optimize iframe load and refactor anonymous cart generation #1896
Conversation
'wc-', | ||
'wc_', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its not uncommon for woo extensions to utilize these prefixes for scripts, so we probably wouldn't be fully covered. That said this is definitely a more thorough approach and better than what we have now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we talked about making this filterable so that publishers can have other payment gateways if they'd like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! Thank you for reminding me, updated in 893a9c4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Very cool way to decouple the iframe logic from the load event. I like this approach, although it doesn't seem to take into account the transition between completing checkout and loading the thank you view.
I think we will need to unflag the ready state during this transition so the handler doesn't return early. Or maybe implement a new flag that triggers the complete state separately?
Oops! Thank you for catching that. That was actually because the newsletter subscription script wasn't whitelisted to be enqueued. Fix in f0972b7 Also, the iframe resize observer failed to resize the modal after the checkout because of the new |
25f6118 removes the It's safe to run the logic outside the trigger. To keep the diff reasonable, I'm maintaining the code inside an You can reproduce the race condition by throttling your network to 3G and disabling the cache before starting the modal while on the epic branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes @miguelpeixe!
I am running into a new issue where stripe throws the following exception when removing the init logic from the init_checkout
event, which causes modal checkout to be stuck in a blocked state on the payment gateway step:
{
"message": "We could not retrieve data from the specified Element.\n Please make sure the Element you are attempting to use is still mounted."
}
This only happens when I've throttled my network speed to 3G and when going through the auth + checkout flow as a new reader, so maybe another race condition between Woo payment gateway logic and our init method? Not sure.
I found another race condition issue with the domReady callback. It's an immediately invoked function that will not run as a domReady callback. Updated in 7dcfc12 |
return; | ||
} | ||
|
||
$is_newspack_checkout = filter_input( INPUT_GET, 'newspack_checkout', FILTER_SANITIZE_NUMBER_INT ); | ||
$is_newspack_donate = filter_input( INPUT_GET, 'newspack_donate', FILTER_SANITIZE_NUMBER_INT ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this because donations are not handled here. Please let me know if I'm missing something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, this method will set the registration checkout flag for donations, which is why this was added. This was to set some order meta so we know whether to send a regular thank you email, or a welcome + thank you email. Maybe there is a better way to handle this now with the async cart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it working? Because donation checkout requests are processed in a different method. We can replicate the flag logic there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see it works because it's before the is_newspack_product
check. WDYT we replicate it to the donate request method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... Given the entire logic for the checkout registration flag lives in the blocks plugin, I see why it's better to have it there. I'll restore it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 35b6d59. I've also changed the is_newspack_checkout
to be a guard clause for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @miguelpeixe!
This is working very nicely for the most part. It looks like I am no longer able to receive the welcome + thankyou emails for new registration checkout though. These should look like this:
We use that checkout registration flag to set session data, and when the order is created set some order meta that our email logic can use to determine which thank you email to send:
newspack-blocks/includes/class-modal-checkout.php
Line 1703 in 6a68ca6
public static function maybe_add_checkout_registration_order_meta( $order ) { |
src/modal-checkout/modal.js
Outdated
iframe.addEventListener( 'load', handleIframeReady ); | ||
|
||
/** | ||
* Generate cart. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking suggestion: Just so it's documented somewhere in the code, maybe its worth adding some further details about the need to trigger this asynchronously to avoid potential session buginess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in bffe929, let me know if it's clear enough
Thank you for reviewing, @chickenn00dle!
Yes! I noticed that too, I've recently pushed some changes that should address that. I commented further here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the changes @miguelpeixe! This is looking good now! I left one non-blocking comment but feel free to ignore that.
triggerCheckout( form ); | ||
} | ||
} | ||
|
||
/** | ||
* Handle modal checkout url param triggers. | ||
*/ | ||
const handleModalCheckoutUrlParams = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking nit: Even though we are no longer using url params for the magic link, I think it might be worth keeping this checkoutURLParam logic so publishers can do things like craft urls in newsletters so readers can be taken directly to checkout for xyz product.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call! Restored in 21f542c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Thanks for the quick turnaround @miguelpeixe! 🙌
Thank you for the reviews! |
All Submissions:
Changes proposed in this Pull Request:
This PR addresses a few different issues:
Introduces a new strategy to detect iframe load so it can be ready sooner. The
load
event dispatch waits for render-blocking assets to load before firing. The new strategy watches for the iframe content document to trigger when the DOM is ready.The dequeuing strategy is now reversed so that only whitelisted assets can be enqueued. This prevents unnecessary assets from loading.
Cart generation via ajax
To handle an edge case in which carts are getting wiped between an account registration and the modal checkout render, this PR changes the strategy for anonymous readers.
Carts should now be generated in parallel to the auth/account creation flow. This allows for the cart session to be created before the authentication, which, once authenticated, Woo should handle the transition without issues.
Because of this new strategy, readers signing in via link should also be able to restore the checkout flow with the existing cart. The pending checkout logic has been simplified here and in Automattic/newspack-plugin#3471.
How to test the changes in this Pull Request:
Other information: