-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Search Functionality #172
Conversation
6127cb8
to
7c6dd69
Compare
5428133
to
5ba7b6c
Compare
6cc22a6
to
879a332
Compare
The only thing missing is the implementation of new tests. |
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.
I still have to review the whole system (the refetching and all) just checked some high level stuff
src/components/HomePage/SearchResultsArea/SearchResultsWidget/SearchResultsUtils.js
Outdated
Show resolved
Hide resolved
ed7664d
to
c12ecd1
Compare
// The "search" and "loadMoreOffers" functions do not share the same state; | ||
// When we run "setHasMoreOffers(false)" on the "loadMoreOffers" function, | ||
// the "search" function does not know that the "hasMoreOffers" variable has changed; | ||
// In the same way, when we run "setHasMoreOffers(true) on the "search" function, | ||
// the "loadMoreOffers" function does not know that the "hasMoreOffers" variable has changed; | ||
// Then, when the "loadMoreOffers" function is executed after a previous execution where the | ||
// "hasMoreOffers" variable became "false", the state of this variable is still false, which | ||
// prevents the fetching of new offers. | ||
// Knowing that, I needed a way to set the "hasMoreOffers" variable to "true" when the previous fact | ||
// happens: setting the "hasMoreOffers" to true when the "queryToken" (which is stored in redux) changes | ||
useEffect(() => { | ||
setHasMoreOffers(true); | ||
}, [searchQueryToken]); |
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.
@imnotteixeira I found out that we have a bug when we fetch all the offers of a search and then do another search. What do you think of this way to solve that?
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.
I have a solution, but I'm not sure you're going to like it...
Maybe it's time to go full-hook and ditch redux for search functionality.
The main idea is: the HomePage Controller (might need to create it) will start storing the search state by calling the search hook. The search hook will be modified to hold the state and export the setters of each filter and the search value etc. Then it will expose the search
and loadMore
functions, as it does currently. It will additionally hold the results array, and errors and loading state, etc... like the redux state currently has.
Then SearchArea and SearchResultsWidget components can both access the HomePage context which will have these methods/data accessible, and most importantly common to both. There can only be 1 search at any given time, which is what we want. Components that currently use the redux state for search can easily call useContext(HomePageContext)
and retrieve whatever they need, no need to pass props around, no connect components to redux.
I'm not sure if we will only ever have the search on the homepage. Maybe some day we will want to keep the search state while the student goes through other pages (viewing offers, adding them to his personal track-list, dunno) and keep the results in a sort-of cart that they can quickly get back to. But for now this is good enough, no need to handle the context above for it to be accessed in other pages.
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.
I think it's a good solution
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.
@imnotteixeira That refactoring will take some time, mainly due to all the changes in the tests. What do you think of leaving this as it is now (because it works) and opening an issue for that?
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.
@imnotteixeira I found out that we have a bug when we fetch all the offers of a search and then do another search. What do you think of this way to solve that?
Then is this a bug or not?
In any case, we should migrate in the future. Search is the next big system still not using hooks/context. Migrating will probably make it simpler. Create the issue and link it here please
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.
It was a bug, but I solved it using that useEffect
, which uses the searchQueryToken
from redux
.
4dcd572
to
cbf11ee
Compare
Beware that search service is being changed here #217. Make sure the changes are migrated to this PR as well. Rebases can sometimes hide these changes and the merging goes wrong. |
cbf11ee
to
1255f0f
Compare
892e91e
to
dc7e8ce
Compare
…on do not share state
98405dd
to
ecb6b42
Compare
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.
Apart from the problem that was discussed and will be solved in another issue, this looks great! I don't have my PC to run this locally but from the video and code review it's 💯.
src/components/HomePage/SearchResultsArea/SearchResultsWidget/useOffersSearcher.spec.js
Outdated
Show resolved
Hide resolved
@imnotteixeira Sorry to bother you, but since you requested changes in this PR, we need your review so that this PR is ready for merging. |
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.
I can't really review currently, so I'll approve since there is already another approval to avoid blocking
2022-02-14.19-15-39.mp4
Closes #79