Automatically perform a slow scroll of any overflow content in a Snippet component when the component enters the viewport. Leverage IntersectionObserver for visibility detection.

Useful for grabbing attention (i.e. "under construction" messaging), demonstrating occluded snippet is not "broken" behavior, and actually displaying longer snippet content in its entirety with limited screen real estate, especially on smaller screens.

Return to start once scroll has completed or remain at maximum x position of snippet container? If returning, should return animation snap, proceed at same speed in reverse, or race quickly back to start position?

#43 broke App.test.js, seemingly by removal of setTimeout call wrapping the reference to the Toaster ref'd child's state...

6bb6611#diff-14b1e33d5bf5649597cdc0e4f684daddL40

Every visit to privacy page causes another copy of 3rd party script to be added to DOM:

Implementation still requires injecting the script to trigger 3rd party functionality but check for existing tags with identical source and remove before adding.

also "soft 404s"

On small screens, the spacing of the dismiss-snackbar button from the edge of the window is uncomfortably close to the role details column of the same width and similar color:

After a lot of reading:
https://www.iubenda.com/en/help/8385-gdpr-cookie-law-caloppa-online-compliance-for-blogs
https://www.iubenda.com/en/help/11994-privacy-policy-for-google-analytics

Seems like legally the safest thing to do is always forbid cookies until user explicitly opts into them, even for anonymized-ip, no-data-sharing Google Analytics.

However, this is relevant only in the EU. And I am not selling anything to anybody, especially not in the EU. And when I adhere strictly to this, my portfolio site's minuscule traffic entirely disappears.

Realistically, I knew from the outset that I would never really need a Privacy Policy and a Cookie Policy and strict adherence to EU Cookie Law for a small portfolio site. But I enjoyed the exercise.

Now what I should probably do is just kill those components and reuse them for some other gimmick.

current privacy page is a little bare:

Would be better to replace checkbox with something more stylish. Perhaps style the options component itself more distinctly so that it stands out as more than just text.

Animated transitions between routes can jump if navigating from route with tall content to route with short content and window scrollY is any greater than 0. Smooth scroll to top of document on transition would alleviate this.

Probably ideal for the smooth scroll to be cancellable if the user is already scrolling or if the user begins to scroll during.

Extra padding needed at bottom of viewport to render all content visible when Snackbar component is position: fixed there. Calculation of Snackbar height and update of padding-bottom on App container element is performed on App component mount but should also be repeated on window resize.

After upgrading to latest create-react-app in #62 , now possible to use Sass files out of the box. Convert *.css files to *.scss.

ConsentToaster component implements an attractive, low-profile notification box in the style of a Material UI "snackbar" component. Generalize this component so that it can be used for more than just cookie consent messaging.

Perhaps leverage Material UI and <Snackbar /> itself? As an aside, I don't know where I got "toaster" from.

Popular effect on many sites, although this example usually includes navigation.

Header starts as a larger block, fixed to top of viewport. As user scrolls down towards more content (when there is any/enough to overflow viewport-y), the header elements shrink and collapse to take up less of the available viewport real estate. Compromise between fixed nav/header and space in the viewport for content.

Usually, the header begins to "grow" back to its original dimensions as soon as the user begins to scroll back up to the top; sometimes one pixel of scroll back up is enough to return the header to its initial state. This, I think is a bad choice because of the implications for scrolling up and down slightly several times in a brief interval, common behavior for e.g. folks searching and scanning for specific content.

The alternative should be to trigger the header restore when the window has been scrolled back to the position at the top where the header shrink initially.

service worker is caching really hard, difficult to get new version without 'bypass for network' in application tab

Current approach to rendering react-router routes on live site leverages CloudFront to intercept would-be 403 errors and instead return 200 OK and serve the create-react-app index.html at the attempted route.

Downsides to this approach

• all possible routes on www.shanedg.com are valid, no true 40x errors to let user/crawlers know they have gone astray; best-case scenario is "soft" 404s
• robots.txt is not being located and parsed if it exists

Resolution

• create-react-app begins to address here, but this is not entirely satisfying; solution is not 100% fleshed out; not exactly "universal" or isomorphic
• could yarn eject and go nuts, but not sure that really makes this process any more straightforward
• could follow this other advice from create-react-app but I'm not super excited about that approach; static is boring, but could result in fewer headaches
• follow a SSR + code-splitting tutorial like this one; might be more challenging but tutorial is fairly recent and I've seen the same pattern in other walkthroughs demonstrating the same concept; pair with asyncComponent concepts from this guide

Currently using local ref just to read desired DOM element height value into state and then access the state of that component through a separate ref created by the parent and attached to the component.

App.js should not have to reach depth of state to get the DOM height we need: this.toasterRef.current.state.height
Rather: this.toasterRef.current.clientHeight

Add Prettier to enforce consistent style across the codebase:
https://github.com/prettier/prettier

CRA support added, details here

• react router transitions are just destroying/replacing rendered components right now, would like to add eye-catching transition between routes
• investigate whether code splitting/async component concepts will prohibit this kind of animation, i.e. ReactMotion and https://serverless-stack.com/chapters/code-splitting-in-create-react-app.html

When the role details are toggled open, the role details list animates in with a staggered effect at the same time as the containing element is toggled in by animating scaleY(). On exit, the scaleY() animation on the containing element is reversed but the staggered entry of the individual role description items is not.

This may actually be desirable behavior, but want to compare against reversing the staggered effect.

Current setup has App.js at the top of /src, and then the rest of the components are stored in /src/components. Some are then nested within other components and this makes relative references brittle and convoluted.

Consider creating an alias to the /src or /components directories to alleviate relative referencing issues.