ETT-1529: bugfix for clearing input when switching from collection to website search#149
Conversation
carylwyatt
force-pushed
the
ETT-1529-searchbar-bug
branch
from
e8157b1 to
b047717
Compare
| }, | ||
| }; | ||
| export const Desktop = { | ||
| args: { |
There was a problem hiding this comment.
I removed this args block. The search bar doesn't have a modal, so I don't know why this was here to begin with.
|
This looks like a thorough solution and testing. I tested some parts and they work for me too. Great work! |
| await canvas.getByLabelText('Search using keywords').focus(); | ||
| await userEvent.type(canvas.getByLabelText('Search using keywords'), 'elephant'); | ||
| const whereToSearch = canvas.getByLabelText('Where do you want to search?'); | ||
| await userEvent.selectOptions(whereToSearch, 'Collection'); |
There was a problem hiding this comment.
Does this catch the bug if the default is already "Collection"? I think we need to switch to "Website" first so the effect actually runs the buggy branch, otherwise this passes even without the fix.
maybe we could add await userEvent.selectOptions(whereToSearch, 'Website'); before switching back.
There was a problem hiding this comment.
It's hard to see in this frame because the interaction tests already ran, but the default Desktop view starts with Website already selected. You can see the Desktop story here: https://dev-3.babel.hathitrust.org/common/firebird/dist/storybook/?path=/story/search-bar--desktop&globals=viewport:bsLg
In the Type Then Change Fields story, in the "add on panel" (storybook's sidebar toolbar thing), you can open the Interactions tab and press the ⏪ (Go to start) button to see the starting state and walk through each interaction.
eumalin
left a comment
eumalin
left a comment
There was a problem hiding this comment.
Changes look good to me!
2 participants
The problem
On prod, if you start from the "website" search option, type in a keyword, then switch back to "collection" search, your search input gets erased.
The fix
Most of the search logic is inside the
$effectblock, and all the variables inside that block are reactive. When the dropdown select changes value (from "Website" to "Collection"), everything in the effect block runs, including setting the search input to a blank string. The fix ended up being very simple: check to make sure there isn't already a value in the input before resetting it to an empty string.I also added a guard to the top of the
$effectblock. I was getting an error in storybook that some values weren't defined, so I added the check to make sure the UI was rendered before trying to do anything else.Testing
This is staged on dev-3: https://dev-3.www.hathitrust.org/ (please excuse the ACF Better Search warnings at the top of the page... this plugin was finally updated last week, and I will be updating the plugin soon!)
I tested this in all of the places the search bar appears (wordpress, ls, mb, catalog, pt) and had no issues, but feel free to test as much as you want!
Automated test
I added a storybook test that checks for this bug: https://dev-3.babel.hathitrust.org/common/firebird/dist/storybook/?path=/story/search-bar--type-then-change-fields&globals=viewport:bsLg