Do not merge. Another preview test...

Issues resolved by this pull request

Type	Required (Y/N)	Instructions
`Deployed`	Y/N	Click link near `Deployed to` below.
`Local`	Y/N	Check out this branch, run its start cmd
`GitHub`	Y/N	Review diffs and likely Markdown

[ ] Front-end: no DevTools console errors occur in the built code (PR review URL) in the step/s required to test the PR.
[ ] Local/terminal: no terminal errors occur in the step/s required to test the PR.

[ ] Cohesive visual design is preserved relative the rest of the site. Colors, type, and layout blend appropriately with the surrounding elements.

[ ] Content is free of typos, grammar/spelling mistakes, and unclear wording.
[ ] README sections: document outline makes sense semantically (proper use of heading levels, lists, tables, etc.).
[ ] README formatting: proper use of code, /paths/to/files/and.stuff, and emphasis when needed.
[ ] README links: all links work correctly and any internal links are relative.
[ ] README headings: should be "First word capitalized" rather than "Some Kind of Other Approach", and should have unique names (a Markdown linter will catch this).

[ ] Any new function is documented using a docblock. Existing functions that were modified can be addressed on a case-base basis.
[ ] Each new file has a page header indicating the file's name and a summary of what it does.
[ ] No typos, grammar/spelling mistakes, or unclear wording.
[ ] Sufficient non-docblock documentation is also provided. (e.g. a simple // Smaller headings for About page).
[ ] No ambiguous abbreviations are used for variable names. No one, including the code author, will know what const f refers to at first glance, but everyone should know what const filePath refers to (or at least have a rough idea).

[ ] If a new file was created, it is in an appropriate directory.
[ ] If new functionality was added, the code is in an appropriate file.
[ ] Efforts have been made to promote DRY code: "don't repeat yourself". If the same code has been repeated multiple times, is there a more efficient and maintainable way to implement it?
[ ] Are naming conventions intuitive and consistent with the rest of the project?