Improve user search experience

[ttannis]

Summary of Changes

This PR further addresses issues from our user interviews, namely:

1. Persisting filters when re-executing a search on the SearchPage
2. Removing the requirement of a search term, which allows users to execute higher level searches across categories, e.g. "I'm looking for all resources in this schema"

NavBar

1. Passes the current location to SearchBar

SearchBar

1. Removed isFormValid check and requirement for a search term to execute a search
2. Passes a boolean to the submitSearch action to specify whether or not the existing filters should be used in this search.

SearchPage

1. Utilizes a new hasFilters boolean to assist with the error message logic. Our new user flow allows for users to clear all search input (search term + filters), in which case they now see a blank page. Note: Will get feedback in Design QA about whether or not we should add some instruction, or otherwise better utilize this space.

Redux Changes

1. submitSearch and searchAll actions take a useFilters boolean in the payload.
2. searchAll no longer resets the filter state. Instead there is a new clearAll action that is fired by searchAllWorker if useFilters is false.

Tests

TODO: As part of final feature branch review

Documentation

TODO: As part of final feature branch review

CheckList

Make sure you have checked all steps below to ensure a timely review.

• PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy
• PR includes a summary of changes, including screenshots of any UI changes.
• PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public python functions and the classes in the PR contain docstrings that explain what it does
• PR passes all tests documented in the developer guide

[codecov-io]

Codecov Report

Merging #376 into feature/ui-filter will increase coverage by 0.09%.
The diff coverage is 39.13%.

@@                  Coverage Diff                  @@
##           feature/ui-filter     #376      +/-   ##
=====================================================
+ Coverage              70.95%   71.04%   +0.09%     
=====================================================
  Files                    174      174              
  Lines                   4380     4411      +31     
  Branches                 568      576       +8     
=====================================================
+ Hits                    3108     3134      +26     
- Misses                  1217     1222       +5     
  Partials                  55       55

Impacted Files	Coverage Δ
...undsen_application/static/js/ducks/search/types.ts	100% <ø> (ø)	⬆️
..._application/static/js/components/NavBar/index.tsx	100% <ø> (ø)	⬆️
...on/static/js/components/common/SearchBar/index.tsx	82.45% <0%> (+2.45%)	⬆️
...undsen_application/static/js/ducks/search/sagas.ts	0% <0%> (ø)	⬆️
...lication/static/js/ducks/search/filters/reducer.ts	48.14% <40%> (+0.32%)	⬆️
...dsen_application/static/js/ducks/search/reducer.ts	95.08% <66.66%> (ø)	⬆️
...lication/static/js/components/SearchPage/index.tsx	98.43% <83.33%> (-1.57%)	⬇️
...mponents/TableDetail/RequestMetadataForm/index.tsx	100% <0%> (ø)	⬆️
...dback/FeedbackForm/BugReportFeedbackForm/index.tsx	100% <0%> (ø)	⬆️
...eedback/FeedbackForm/RequestFeedbackForm/index.tsx	100% <0%> (ø)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e8f499b...e7bcd31. Read the comment docs.

[danwom]

Is there a better place for this logic? If possible I wouldn't want the SearchBar to be aware of location and which routes should preserve the filters.

• Maybe the reducer or saga should be aware of the route and decide if the filters should be used or not.
• Maybe there should be a small checkbox somewhere that would explicitly decide to preserve or clear filters.

[ttannis]

Hope the following is clear I time-boxed some investigation:

1. After some investigation I'm not confident this is a quick fix as opposed to separate task of augmenting our usage of Redux on that manner. I couldn't quite wrap my head around the safest way to do this that is 100% guaranteed to keep the redux state and react-router in sync -- if it exists.

2. If the ability to toggle useFilters or not was equal work effort I'd be confident to include it, but in this case there would be extra effort to add this to the application state and ensure page navigations still somehow update this state. I think it's worth investing effort into that toggle implementation only if users request it, or Design supports it. I'd essentially hate to spend a couple days on this and then have to remove it after Design QA. It is worth proposing as part of the final design QA though.

In summary we could talk about this more offline as its own task. I boil this down to the fact that we need a SearchBar that will cause either one of two action chains to happen:

1. clearFilters & submitSearch
2. submitSearch

Meaning that SearchBar could take its submit method as a passed property, and it's parent components which are connected to the router could pass the correct submit action to the SearchBar. Let me know what you think, and I can add the modification before final feature branch review.

[ttannis]

FYI references -- first found this library which might have been overcomplicating things and is now deprecated, but it could also be as little effort as some of these suggestions