Ga topic status with localstorage

[gabriele-ct]

Attempt to use localstorage cache for swr.

I invested some time on it and still has glitches:

• if a user logs out with, say, 1 quiz passed, then logs in again and passes the 2nd quiz, when navigates from one page to another, keeps getting the old 1 quiz passed response.
• little flash when navigating to a SSR page (as it doesn't have localstorage knowledge)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1902036

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@commercetools-docs/gatsby-theme-learning	Minor
@commercetools-docs/gatsby-theme-docs	Minor
@commercetools-website/docs-smoke-test	Minor
@commercetools-website/documentation	Minor
@commercetools-website/api-docs-smoke-test	Patch
@commercetools-website/site-template	Patch

Not sure what this means? Click here to learn what changesets are.

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

[github-actions]

🚚 Build Process Details

Preview URLs:

• https://docskit-ga-topic-status-with-localstorage.commercetools.vercel.app (permalink to the last build of this branch)
• https://docskit-sha-3d9230594707ae477344463787ec2c6cffea3935.commercetools.vercel.app (this commit)

[gabriele-ct]

First doubt. If we want to have the course/topic status available in the sidebar and (potentially in the future) in the actual content page, the only place common between these 2 layouts is the application layout.
Adding cache provider here means that all the usages of swr in the app will be cached in local cache. This might be what we actually want, or might be creating side effects.

[nkuehn]

#1 I wonder if something like the SWRConfig would not be better placed in gatsby-browser's "wrapXXXElement" hooks. That implicitly makes them client side only and also makes sure they are in all layouts.

#2 having one cache provider for any SWR even across microsites felt weird to me too in the beginning but I concluded that it's the whole point of it. The cache keys are the URLs you use to fetch from SWR and the content is the API response. And we want that information to be available at least in stale state for other pages / views / microsites. So it must be one fixed key like "app-cache" and also at top level for the domain. We could use a more specific localstorage key maybe that is more explanatory.

[gabriele-ct]

This handler is rather blind approach as it will simply dump swr state to the cache each time the page is refreshed. But we refresh the page also each time we login and logout.
This is the reason of the 2 custom events that basically disable writing the cache upon login and logout.

[nkuehn]

The behavior is nice :-)

Still a slight delay but that is the general hydration of the static page after reloading (it just becomes more visible but is not new, the top meny does not work too in the first second).

[nkuehn]

#1 I wonder if something like the SWRConfig would not be better placed in gatsby-browser's "wrapXXXElement" hooks. That implicitly makes them client side only and also makes sure they are in all layouts.

#2 having one cache provider for any SWR even across microsites felt weird to me too in the beginning but I concluded that it's the whole point of it. The cache keys are the URLs you use to fetch from SWR and the content is the API response. And we want that information to be available at least in stale state for other pages / views / microsites. So it must be one fixed key like "app-cache" and also at top level for the domain. We could use a more specific localstorage key maybe that is more explanatory.

[gabriele-ct]

The behavior is nice :-)

Still a slight delay but that is the general hydration of the static page after reloading (it just becomes more visible but is not new, the top meny does not work too in the first second).

If you have time I'd like you to have a look to more specific scenarios like, for example:

• new user signup
• takes part of the course
• logs out
• logs in again
• take another quiz

I felt something was wrong, but I might be wrong

[nkuehn]

If you have time I'd like you to have a look to more specific scenarios like, for example:

@FFawzy could you do me a favor and test through the mentioned scenarios with a diligent look at the status indicators in the navigation? Realistically I would not be able to follow up because I'll only be there for a day next week.

[FFawzy]

Notes while testing the preview:

• if we don't have anything stored in the local storage and then you take a quiz and pass it, there is a green tick appears but then if you navigate to a different page, the tick disappears for a sec and then appears again (I guess it tries to read from localstorage, does not find it and fetch it again)
• if we have some data stored in the localstorage it does not seem to get updated properly.
  try taking a quiz, pass it. then refresh the page (storing the data in local storage) then try to take a second quiz and pass it too.
  then try to navigate to a different mdx page within the same site, you will see the second quiz status disappears and appears again,

TBC with more test cases

[nkuehn]

the tick disappears for a sec and then appears again
@FFawzy to properly analyze you have to have the network tab open and filter the api requests. There is a short delay on reloads (like microsite switch) that cannot be avoided because it's the time the browser takes to hydrate the static page with the app. But there could also be a longer delay if it really re-fetches the data. Slow-motion / slow network mode of the dev tools is you friend in this kind of analysis work.
The second topic you brought up also sounds like you need to analyze it in depth with slow mo and the API calls logged while it loads