[Issue #75] Added sticky behavior to search filter sidebar

[btabaska]

Summary

Fixes #75

Time to review: 3 mins

Changes proposed

Added a div with class behavior to set filters to independent sticky scroll

Context for reviewers

Tested with betaAlert component to ensure sticky behavior worked with both

Additional information

[github-actions]

Coverage report for ./frontend

St.❔	Category	Percentage	Covered / Total
🟢	Statements	83.27%	846/1016
🟡	Branches	68.31%	222/325
🟡	Functions	75.46%	163/216
🟢	Lines	82.81%	795/960

Test suite run success

168 tests passing in 54 suites.

Report generated by 🧪jest coverage report action from 94df8f4

[rylew1]

nit: maybe pull these classes into their own custom style className="searchFormStickyBar"

[acouch]

We should have a standard and stick to it (either prefer custom class names or not) and document. I don't have a strong opinion either way.

[btabaska]

Iterated based on that feedback.

[btabaska]

My opinion is that USWDS already supports custom CSS in the _uswds-theme-custom-styles file and we have already leveraged that for the .pdf-card component. It is cleaner to move large chunks of CSS into a single file to make it easier to read inline.

[andycochran]

If we add custom classes, they shouldn't duplicate the function of utility classes. USWDS already has a class that makes something sticky, no need to define a new style to do the same thing. I think custom classes should only be used for styles that are not possible with utility classes.

[rylew1]

I'll let @andycochran take a peek but looks good!

[andycochran]

We might hold off on this ticket. Honestly, it was sort of a placeholder/note-to-self when I wrote it. I imagined it might work a little differently than it's implemented here. It's a bit awkward that it has a max-height and scrolls independently while not stuck. Since there's no :is-stuck CSS selector, it'd be quite a bit of work to detect that state (e.g. link) and only apply the max-height then. Again, maybe we hold off on this. I'm not sure it's necessary, and the filter design is likely to change quite a lot.

The downside to not doing this is that the scroll position of the results and filter are intertwined. And we've not done any usability testing that shows this is a problem. It's an assumption that users will want to retain the results scroll position while scrolling through the filters.