[Just In Time Messages] Refresh JITMs

[joshheald]

Part of: #7916

Description

JITMs were previously only loaded when the Dashboard was first loaded. This could mean that the latest message is not shown, especially if the app has stayed in memory for some time.

The dashboard has data which benefits from regular refreshing, so in this PR we refresh the JITMs whenever that data is refreshed.

Additionally, when the user takes action in a webview, they may make themselves ineligible for a JITM, by completing the action it's informing them of. This PR resyncs the announcements when the webview is closed, so that JITMs will be automatically dismissed in that case

Testing instructions

N.B. see pdfdoF-1uc-p2#comment-2581 for details of setting up your store to be eligible for the test JITM

With a US store that is eligible for the test JITM, on a debug/alpha build of the app

Pull to refresh:

1. Set up Proxyman or Charles to observe network requests
2. Open the app
3. Observe that the message is shown, after a network request to https://public-api.wordpress.com/rest/v1.1/jetpack-blogs/{SITEID}/rest-api/?json=true&path=/jetpack/v4/jitm%26_method%3Dget&query=%7B%22message_path%22%3A%22woomobile%3Amy_store%3Aadmin_notices%22%7D
4. Dismiss the JITM
5. Pull to Refresh
6. Observe that the JITM doesn't show, but that there's been another network request (with {data: []} as the response)
7. Wait 30 seconds, then Pull to Refresh again
8. Observe that the JITM shows again

Refresh after webview dismissal

1. Set up Proxyman or Charles to observe network requests, setting a breakpoint on the response to https://public-api.wordpress.com/rest/v1.1/jetpack-blogs/*/rest-api/?json=true&path=/jetpack/v4/jitm*
2. Open the app
3. Observe that the message is shown
4. Tap the CTA
5. Tap Done or swipe the webview away
6. At the breakpoint, edit the response body to {"data": []}
7. Observe that the JITMs are dismissed. (Since this is simulated, they will return when pulling to refresh unless you edit the response again!)

N.B. there's nothing you can do in this webview to become ineligible for the JITM, which is the expected use case. With potential future backend changes, e.g. to target only people who've not bought a card reader, this refresh behaviour could automatically remove a JITM without need for them to dismiss it.

Screenshots

jitm-refresh-on-webview-close.mp4

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[joshheald]

@rachelmcr optional review again. FYI I moved the code that prevents JITM sync when there's a product announcement showing, because it was stopping us from clearing the JITMs on refresh, if the user had become ineligible for the message.

Let me know if you have any concerns but it has the same effect on priority of announcements.

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8012-3eb1f86 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[peril-woocommerce]

	Warnings
⚠️	This PR is assigned to a milestone which is closing in less than 2 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS

[rachelmcr]

Thanks, these changes make sense! No issues from the products onboarding perspective 👍

[koke]

I tested the first part and it worked fine. However, when I tap on the CTA and then dismiss the web view, the JITM is still there

[joshheald]

I tested the first part and it worked fine.

Thanks for the speedy review @koke!

However, when I tap on the CTA and then dismiss the web view, the JITM is still there

Yes, this is expected with this JITM.

Ideally, if you tapped on the CTA, and bought a card reader, the JITM would be removed on refresh when you dismiss the webview. However, even if you do that it won't actually be dismissed with this test JITM: there's no targeting rule for "hasn't bought a card reader on woocommerce.com" at the moment.

The code here merely gives us the ability to remove the JITM after some backend changes:

N.B. there's nothing you can do in this webview to become ineligible for the JITM, which is the expected use case. With potential future backend changes, e.g. to target only people who've not bought a card reader, this refresh behaviour could automatically remove a JITM without need for them to dismiss it.
– testing instructions

[koke]

I was confused by the 6. Observe that the JITMs are dismissed. If this is the expected behavior then it's good to go 🚀

[joshheald]

I was confused by the 6. Observe that the JITMs are dismissed. If this is the expected behavior then it's good to go 🚀

Ah sorry that is confusing. I missed out the step in those testing instructions where you should edit the response to {"data": []}, to simulate the user becoming ineligible for the JITM after that action, which I think I did in the video... Sorry about that, and thanks again!

Adding that in now to avoid confusing @pachlava as well 😬