USE-188: Responsive behavior for tab bar

[djanelle-mit]

Developer

Implements responsive behavior for our tab bar. When the screen is too narrow, a "more" button is created with an overflow menu beneath it.

This work also includes final names, approved by UXWS, for our tabs.

Notable includes in this work:

• I had to add a condition to the loading spinner JS to stop it from firing when buttons or li elements were clicked. It now only fires when a link is clicked.
• This adds a new JS file, and I'm not sure if there's anything I missed when implementing that.
• Keyboard navigation works via TAB key. In <select> dropdown menus up and down keys are how folks navigate, but because this feels like a navigation menu, where tab is typically how folks navigate, it felt right to keep it that way.

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

E.g., if the PR includes updated dependencies and/or data
migration, or how to confirm the feature is working.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

Pull Request Test Coverage Report for Build 19826599962

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.833%

---

Totals
Change from base Build 19640498490:	0.0%
Covered Lines:	948
Relevant Lines:	969

---

💛 - Coveralls

[JPrevost]

I'm not sure if the is an edge case you prefer to come back to, but if I start with a wide viewport from the USE UI home and then run a search and then narrow my viewport it does not collapse.

If I then refresh, I get the collapsed mode and it works when I expand and contract the viewport as expected.

This issue is being caused by the JS throwing an error and stopping execution.

[JPrevost]

I get this error in the console when this is loaded from the main USE UI page.

null is not an object (evaluating 'container.querySelector')

We likely either need to change this logic here or to not error which prevents the script from running further or only load this script on pages that have that selector.

This script erroring prevents it from working when a search is run.

One way to address this might be to wrap this logic in a function and then have a return block at the start of the function if the required DOM elements are not present.

[JPrevost]

We need to address the errors when starting from the USE homepage, either by resolving the problem or opening a ticket to come back to it.

[djanelle-mit]

@JPrevost I switched to loading via javascript_include_tag inside the tabs view (same way we handle loading the JS for the search forms) and that seems to have resolved everything. No errors are thrown (since the JS only loads when the tabs are present) and because it's being loaded when the tabs are present the initial load call of doAdapt fires. Previously it was only firing on the homepage and not when the search was performed.