Update Home Page content after cache hit (#2230)

[davemacaulay]

Description

Apollo will not query the GraphQL endpoint for a new version of CMS Page content due to the usage of the default fetch policy, cache only. This PR updates this cache policy to use cache-and-network (https://www.apollographql.com/docs/react/api/react-apollo/#optionsfetchpolicy) which will ensure the cached data is rendered, then a request is made to retrieve any new data if available.

This fetch policy ensures a quick user experience while ensuring up to date content is rendered on the homepage. If there was a change in content between the cache and GraphQL Apollo automatically handles re-rendering this.

Related Issue

Closes #2230 .
https://jira.corp.magento.com/browse/PWA-471

Acceptance

Verification Stakeholders

@jimbo
@sirugh
@brendanfalkowski
@dhaecker

Specification

https://www.apollographql.com/docs/react/api/react-apollo/#optionsfetchpolicy

Verification Steps

• Navigate to homepage in app (allowing content to be cached)
• Open Admin
• Go to Content > Pages > Home page
• Edit the home page and save
• Refresh the application (the old content will display, which is expected for the first reload)
• Refresh the application again
• The old content will be displayed again, as it will for any number of times that the page is refreshed
• Manually clear the localStorage property, {{apollo-cache-persist}}
• Refresh the application
• Now the updated home page data will be displayed

Screenshots / Screen Captures (if appropriate)

New Experience:

Checklist

• I have added tests to cover my changes, if necessary.
• I have updated the documentation accordingly, if necessary.

[PWAStudioBot]

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

Generated by 🚫 dangerJS against 239d8d9

[devops-pwa-codebuild]

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-2453.pwa-venia.com : LH Performance Expected 0.85 Actual 0.54, LH Best Practices Expected 1 Actual 0.92
https://pr-2453.pwa-venia.com/venia-tops.html : LH Performance Expected 0.75 Actual 0.35, LH Best Practices Expected 1 Actual 0.92
https://pr-2453.pwa-venia.com/valeria-two-layer-tank.html : LH Performance Expected 0.8 Actual 0.49, LH Accessibility Expected 0.9 Actual 0.89, LH Best Practices Expected 1 Actual 0.92

[zetlen]

Is PageLoadingIndicator something different from packages/venia-ui/lib/components/LoadingIndicator or is it a reimplementation?

This is a well-designed API and hook for page load. We already have that concept in the codebase, but it's not perfect. Did you look at LoadingIndicator first, or just make a simple PageLoadingIndicator real fast?

[davemacaulay]

Is PageLoadingIndicator something different from packages/venia-ui/lib/components/LoadingIndicator or is it a reimplementation?

This is a well-designed API and hook for page load. We already have that concept in the codebase, but it's not perfect. Did you look at LoadingIndicator first, or just make a simple PageLoadingIndicator real fast?

@zetlen they have very different purposes. The LoadingIndicator is used to signify the whole app is loading and is purposefully blocking. The new PageLoadingIndicator sits in the header and only represents a page is doing a cache-and-network load. It will only be displayed when Apollo is making that network request (while having already displayed the cached data), but might not actually change any data.

[jimbo]

This is looking good. I've requested changes in a few places, but nothing significant.

[jimbo]

Did you look at LoadingIndicator first, or just make a simple PageLoadingIndicator real fast?

This is essentially a leaf-node component, and I'm okay if those proliferate. It's a thin wrapper around Icon; I'm afraid of getting too much more abstract than that. 😅

[tjwiebell]

One minor suggestion in addition to what's already requested. We need to have a team discussion about redux, but not a blocker to this PR. Looks good 👍

[dhaecker]

QA approved