Reduce home page flickering show relevant content only

[gabriele-ct]

You probably have noticed that when a logged in user refreshes the learning minisite homepage sees logged out content first, then logged in content and, if he finished the learning path has a 3rd content change on the page as you can see in the video below:
https://vimeo.com/826184271/db6e4faced

This happens since some API calls need to happen in order to determine what content should be displayed to the user.
Although it doesn't cause a massive amount of layout shift I find it quite misleading for the user and rather unprofessional.

I'd like you to have a look to this different approach which is to display nothing until all the API calls have completed and we're sure about what content to display:
https://vimeo.com/826187147/082555513f

Obviously none of the above are ideal since there are technical limitations that we all know. However, I feel like the second approach feels somehow less amateur-ish than the first.

I'd like to know what's your opinion about it @zbalek @nkuehn @FFawzy @timonrey

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4ca4609

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

🚚 Build Process Details

Preview URLs:

• https://docskit-ga-reduce-flickering.commercetools.vercel.app (permalink to the last build of this branch)
• https://docskit-sha-8d74f23d18e1de7587bbd3e08d477009fb1f069c.commercetools.vercel.app (this commit)

[gabriele-ct]

As note I don't think the assumeTrue helps much as the logged out user will see logged in content which is IMHO even worse

[zbalek]

@gabriele-ct I think that the proposed approach makes sense. I was wondering though - would it be possible to implement something like this whilst we wait for the page to load?: https://uikit.commercetools.com/?path=/story/components-loading--loadingspinner @FFawzy @timonrey

[nkuehn]

(edited second bullet for having been nonsense in some aspects - the initial hydration time will always stay)

@gabriele-ct

• yes, assuming logged in just inverts in the issue into "a different kind of flicker". We only have it on the content MDX component because that component does not know what's in it so it can't reserve space. In that case an author can decide which is the "better among the bad" choices.
• Our architecture is multiple SPA microsites so switching between microsites is 90%+ of the occurrences of loading state flicker, not the actual login itself. Forcing a reload is an edge case too but a good simulation of switching between mincrosites.
  So far for the obvious, just to give context.

The root cause resolution for the class of problem is not investing even more time into reserving some space but to configure both SWR and Auth0 to use localstorage based caches instead of memory based caches. Reserving space is never a full resolution because the content displayed in the respective states can only in some cases fit into the exact same space. (this was BS)

Given that the time to hydrate the SPA will always be there in the one or the other way trying to reserve space wherever it is predictable is a good idea that will always be applicable (this PR). Minimizing the time until the information is available can then be optimized by addresssing two things

• configure both SWR and Auth0 to use localstorage based caches instead of memory based caches (removes the time after hydration until at least stale data is available)
• applying gatsby's "partial hydration" feature to selected components once stable on react side (e.g the top nav and user avatar). https://www.gatsbyjs.com/docs/conceptual/partial-hydration // https://www.gatsbyjs.com/docs/how-to/performance/partial-hydration // It sounds like a server side runtime but in gatsby's case is still a static website but with two classes of components in the page - some "client side" and the rest "server side" (telling the client to not bother about making them "alive")