Guidance Update Feature

[beahackman]

Deploy Preview

What does this PR do?

Added an update feature that tracks changes to the guidances. It uses the Github API to read the pull requests closed onto the site, then displays the information via inline notifications and tags. It also uses visitation tracking for a personalized experience, this makes it so once the user has seen the update on the guidance page, it won't show again.

Where should the reviewer start?

They should start in the app.js file in the pages folder. This has the fetching information and calls the other components with that information. It would then be beneficial to explore the functions called/added in app.js from there.

What testing has been done on this PR?

I've tested that the feature against older PRs (making sure they wrote over the old ones), tested it in incognito with no access to local storage, and different cases with last-visted tokens.

In addition to the feature you are implementing, have you checked the following:

General UX Checks

• Small, medium, and large screen sizes
• Cross-browsers (FireFox, Chrome, and Safari)
• Light & dark modes
• All hyperlinks route properly

Accessibility Checks

• Keyboard interactions
• Screen reader experience
• Run WAVE accessibility plugin (Chrome)

Code Quality Checks

• Console is free of warnings and errors
• Passes E2E commit checks
• Visual snapshots are reasonable

How should this be manually tested?

To test visitation tracking or to see how information is being stored, I would check the local storage in the browser's developer tools. A user who is entirely new to the site will have neither "update-history" or any tokens ending in "-last-visited," but when launching, it will create the "update-history."

Any background context you want to provide?

To run the visitation tracking correctly (in dev mode) I had to turn the React StrictMode to false when writing it. I turned it back to true before this push/pull, but to run it with proper logic it should be toggled to false.

What are the relevant issues?

Issue #3405

Screenshots (if appropriate)

Should this PR be mentioned in Design System updates?

Yes

Is this change backwards compatible or is it a breaking change?

Note about pageUpdateReady:

In app.js there is a declared state of pageUpdateReady. This is used to accommodate for the rendering behavior when entering a guidance page. Here is the context we need it for:

• A user who hasn't seen the update enters the guidance page, sees the update, and navigates back to the components page.
• The update state for this page will still be true as they navigate away, this is because the update state is only calculated when they enter the guidance page.
• The user clicks on the component card to re-enter the guidance page they just saw. This is how it renders:

1. Layout.js renders the current update state (which would be true before calculations)
2. The route change hook in app.js sets the update state as false
3. Layout.js re-renders the page with the update as false (this switch from true -> false causes the flash)

• We address this with the pageUpdateReady state variable by changing the flow to this:

1. Layout.js renders, but it first (and always) sets the pageUpdateReady as false. Since the update components' rendering rely on this to be true, they won't show yet.
2. The route change hook in app.js then sets the update state as false (the correct state.) Once this is figured out, it will set pageUpdateReady as true.
3. Since the pageUpdateReady is now true, Layout.js re-renders with pageUpdateReady as true (which allows for the inline notifications/side navigation indicators to load the proper information once.)

[netlify]

👷 Deploy request for keen-mayer-a86c8b accepted.

Name	Link
🔨 Latest commit	402d3df
🔍 Latest deploy log	https://app.netlify.com/sites/keen-mayer-a86c8b/deploys/64fb773dc69e6e0008e2c213

[jcfilben]

Nice work! I'm still working on reviewing but here are some minor comments so far

[jcfilben]

Looks like there is a conflict with the yarn.lock file. To fix this you can do the following on your branch:
git fetch upstream
git merge upstream/master
rm -rf yarn.lock && rm -rf node_modules && yarn cache clean && yarn install
and then stage your changes, commit and push

[jcfilben]

Another round of comments

[jcfilben]

Last few comments!
Can you also run prettier on your files that you changed? (option+shift+f)

[jcfilben]

Just need to fix the yarn.lock conflict, otherwise looks good!

[beahackman]

hey quick heads up: i noticed a bug where everything runs smoothly if you access the updated components via the components/templates page, but it only flashes the updates (inline notifications & side navigation indicators) when you enter the guidance through the search bar. i'm pushing up a version with the most recent comments resolved and quick edit to the route names, but after that push i'm going to be working on that problem.

[taysea]

A few tiny comments, but I think the PR looks good otherwise!

[jcfilben]

I think we are good to merge, nice work!

[taysea]

I'm running this locally right now and getting a variety of linting errors. Working through fixing them before we merge.

[taysea]

Looks great!