-
Notifications
You must be signed in to change notification settings - Fork 63
Convert search store to an options store #1259
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a UI perspective, everything I tested is working correctly:
- Toggling and clearing filters
- SSR and client-side page loads
- Switching content types
onMounted(() => { | ||
searchStore.$reset() | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this clears all the search information, but it doesn't clear the results. So given the following flow:
- Search for 'dogs' on the homepage
- See the results on the /search page
- Click the openverse logo / home link
- Make a new search for 'cats'
The user will see a flash of dog results while the 'cat' results are loading.
Not sure if that's a problem or should be fixed here, just noting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thank you for noting this! I'll add add the result reset, too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, wait. This will require the reset in the media store. Let me make an issue for fixing it after one of the store PRs is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return mediaFilterKeys[state.searchType] | ||
.filter((filterKey) => filterKey !== 'mature') | ||
.reduce((obj, filterKey) => { | ||
obj[filterKey] = this.filters[filterKey] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we choose to use either this
or the explicit state
parameter consistently? Mixing the two is confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to use this
for some getters
because we are calling actions from within them. Using state
as a param is convenient because you don't have to explicitly add the return type of the getter
. But it using both is confusing, then we should just stick to this
, and manually typing the return type.
I'll refactor all the getters if we agree that it's better for consistency, @sarayourfriend
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting. I guess it's fine to mix them, I will get used to it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything seems to work as expected 👍
Co-authored-by: sarayourfriend <24264157+sarayourfriend@users.noreply.github.com>
Fixes
Fixes #1258 by @obulat
Description
This PR converts the setup Pinia store into options store. This means that we pass an options object to the
defineStore
function that hasstate
,getters
andactions
, similar to Vuex stores.This PR also resets the state when homepage mounts so that the old search type is not used when navigating back to the homepage from a search page using the logo, and searching again.
Testing Instructions
Try searching for all content, images and audios, opening single results, searching from the homepage
Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin