[info arch] Adds OnThisPage component and aside feature to PageLayout

[katydecorah]

This PR merges into #334

• Create OnThisPage component that displays headings on the page and performs scroll spy to indicate where you are on the page.
  • Replaces react-scrollspy with a local script to detect when a heading is in view.
  • Deletes @mapbox/dr-ui/plugins/create-sections plugin as it's no longer needed.
• Update PageLayout component.
  • Add aside feature which includes the OnThisPage and Feedback components. On larger devices, the aside is stuck to the right-side of the screen. On smaller devices, OnThisPage moves inline below the page's title and Feedback will appear at the bottom of the page.
• Update Feedback component.
  • Removed background color and use AsideHeading component to style the component's heading.
• Update docs-prose.css.
  • You can now use .unprose class on h2 elements to remove the styling.

Note: The dr-ui component home page doesn't have a left sidebar right now. It will once #332 lands.

In addition to the details in the changelog, I wanted to point out a few decisions and get your thoughts:

• I decided not to use Sticky component (react-stickynode) for the aside feature in PageLayout. I decided to go with a less expensive option, CSS (position: sticky), however this means that the aside feature will not stick on IE 11 and will instead by static. I think this is ok and considered a progressive enhancement as the core functionality of the component of providing anchor links is still attainable.

• The new OnThisPage component requires that all headings that will be used as links have the anchor class. This will help us to better identify and track via the scroll spy functionality. This should not be a problem for most pages, where this PR updates the add-links-to-headings plugin to add the class to headings automatically. This also allows us to remove (which this PR does) the create-sections plugin which added a lot of divs to sectionize headings for the purpose of scroll spy. Overall, I think this will be an improvement. But during roll out, we'll need to be mindful of pages that use html rather than markdown (like Mapbox GL JS) to make sure we add the anchor class to each h2 and h3 element that is expected to show up in the OnThisPage component.

• This PR also includes a bunch of small/fiddly updates to the catalog page to enable the Feedback component on all pages to make testing easier.

To do

• Fix tests
• Fix aside on catalog page (it scrolls with the page)
• Add task to [info arch] Redesign PageLayout #332 to increase max-width of limiter class in PageLayout to give the content and new feature enough space.

How to test

• View the OnThisPage test cases page (npm start)
• View the catalog site (npm run start-docs) -- Note the homepage of the catalog site doesn't currently have a left sidebar, but that will be changed when the PageLayout updates are added.

QA checklist

• No errors logged to console.
• Accessibility score in Chrome DevTools Audit/Lighthouse is 100% with Lighthouse version: #.#.#.
• Component is accessible at mobile-size viewport.
• Component is accessible at tablet-size viewport.
• Component is accessible at laptop-size viewport.
• Component is accessible at big-monitor-size viewport.
• Create a PR in a site repo, copy the component, and test it. Push to staging and let the reviewer know they can also test the component there.

Open the test cases app locally on:

• Chrome, no errors logged to console.
• Firefox, no errors logged to console.
• Safari, no errors logged to console.
• Edge, no errors logged to console.
• IE11, no errors logged to console.
• Mobile Safari, no errors logged to console.
• Android Chrome, no errors logged to console.

Fixes #341

[danswick]

This is so good! I tested thoroughly locally and left a few comments (mostly just clarifying) inline.

Regarding the prompts you left:

• I decided not to use Sticky component... This seems like a great decision to me. The IE trade-off seems perfectly justifiable to me as well.
• The new OnThisPage component requires that all headings that will be used as links have the anchor class... This also seems like a justifiable decision. Most of this component's users will be working almost exclusively in markdown anyway. If it becomes a big issue, we could consider a custom plugin, but I feel pretty confident we won't need to.

My only concern when looking at the live page is that 1200px might be a bit of a high threshold to sacrifice both a persistent sidebar as well as second-level headings. Right now, anything that takes up less than half the width of my external monitor gets the collapsed version. Maybe we can check back in when the page layout is finalized to see how much real estate we can buy back and see what feels feasible?

[danswick]

Interesting! I don't think I've seen a recursive component before 👀

[danswick]

Do you think this will ever nest further or are we committed to H2 and H3?

[katydecorah]

I think we are committed to h2 and h3. I think anything beyond h3 is too granular.

[katydecorah]

My only concern when looking at the live page is that 1200px might be a bit of a high threshold to sacrifice both a persistent sidebar as well as second-level headings. Right now, anything that takes up less than half the width of my external monitor gets the collapsed version. Maybe we can check back in when the page layout is finalized to see how much real estate we can buy back and see what feels feasible?

@danswick Right, I added a task to #332 to adjust the max-width of the limiter to afford space for the aside

Edit: As I reread your comment, I think you're talking about the media queries and I was thinking about just the limiter!! Yes, you're right. Right now the aside is only sticky starting at -mxl, I agree that once we update the width on the limiter we can try to start sticky for the aside sooner at -ml. I added this to our tracker to remind us to follow up.