fix(modal-checkout): handle auth modal analytics

[miguelpeixe]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

1200530782742699-as-1208558693529961/f

When a reader starts the modal checkout they may get prompted to authenticate or register, which will not trigger the GA4 event to register the intent.

This PR, along with Automattic/newspack-plugin#3481, implements that support.

Along with that:

• Some variable names have also been updated for better readability.
• Fixed the gtag integration within the checkout, which was being dequeued and unable to trigger the form_submission event

How to test the changes in this Pull Request:

1. Checkout this branch and add the following to line 24 of src/modal-checkout/analytics/ga4/utils/index.js for easier testing:

console.log({ eventName, payload });

2. In a fresh session, start a checkout button block flow
3. Confirm the opened event is logged in the console
4. Close the auth modal and confirm the dismissed event is logged in the console with the correct payload
5. Start the flow again and confirm it also triggers a new opened event (checkoutOpen changed to false)
6. Go through registration and confirm that opening the checkout does not trigger a new opened event
7. Purchase and confirm the form_submission event is triggered with the correct payload
8. Confirm that finishing the purchase flow will not trigger the dismissed event
9. Start the checkout flow for a variable subscription
10. Confirm that opening the variation modal triggers the opened_variations event
11. Select a variation and confirm the opened event is triggered
12. Close the modal and confirm dismissed is triggered
13. Click again and confirm opened_variations triggers again

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[chickenn00dle]

Nice work @miguelpeixe!

This works as expected. I just had one question about using a flag for open state before giving a thumbs up.

Also had a second non-blocking question/nit but feel free to ignore that one!

[chickenn00dle]

Is this flag necessary? Can we just use the data-state of the modal checkout container which will be open when the modal is open and closed when not?

[miguelpeixe]

The checkoutOpen is also set to true when an anonymous reader intent to purchase triggers the auth modal. In this case, we can't leverage the checkout modal state because it's not yet open at this point.

We can rename the variable or have a different strategy, but I don't think going through each modal state would be practical for this.

[miguelpeixe]

I updated the variable name and added a comment in 94fea3f. I think this change makes it more clear that it's not about the checkout modal being open. Let me know if you think this works

[chickenn00dle]

This works for me! Thanks for clarifying @miguelpeixe 👍

[chickenn00dle]

Non-blocking nit/question. Feels weird to provide an onClose callback option that won't be called everytime. Especially considering we already provide a generic callback option. Is it possible to simply use the callback for analytics purposes here, using the authData and open state as a flag for whether this was dismissed?

[miguelpeixe]

My concern is that the callback is only called on success, so, as is, we don't have a way to hook into dismissals.

I think we can go 2 ways:

1. Make the callback also trigger on dismissals, including the success/error/dismiss as a callback argument
2. Change callback to onSuccess and preserve onClose (or rename to onDismiss)

WDYT?

[chickenn00dle]

Change callback to onSuccess and preserve onClose (or rename to onDismiss)

I like the idea of onSuccess/onDismiss. I feel this makes it super clear where functionality for each should go. But truthfully I'm fine with either approach if you have a preference for 1.

[miguelpeixe]

I also like 2 better 😄

[miguelpeixe]

Updated in 89aacb6 and Automattic/newspack-plugin@cda1b5c. I've also introduced the onError callback and updated the newsletter signup modal to follow the same standard.

[chickenn00dle]

add the following to line 24 of src/modal-checkout/analytics/ga4/utils/index.js for easier testing

Would be neat if we could make this logging permanent and only have it enabled when some development flag is present or something like that. Definitely not something needed in this PR, but thought I'd bring it up.

[miguelpeixe]

Would be neat if we could make this logging permanent and only have it enabled when some development flag is present or something like that.

That can be handy. I usually use browser extensions to track GA behavior on a page. I just figured the console log would be more straightforward for this PR than suggesting an extension.

[miguelpeixe]

f958d86 fixes a missing dependency for the checkout form. Reversed in c5bb48d because that's already being taken care of in #1909

[chickenn00dle]

Looks good! Thanks for the changes @miguelpeixe!