If the user searched for "first query", and then before the results had the chance to appear, search for "second query", the results for "first query" would still be appended to the results array.
This diff fixes that by using an id for each server call, and after the results get fetched, the id of the server call is compared with the most recent id.
Details
Details
Checked that flow is not broken in web and native that both use useSearchMessages. checked that the above scenario doesn't happen anymore (I used network dev tools to ensure the messages didn't get fetched before the query was changed). Checked that it is still possible to fetch messages, and more messages for the same query.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- inka/search_web
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| lib/shared/search-utils.js | ||
|---|---|---|
| 233 | Why is this parameter optional? Is there any callsite that doesn't pass it in? If you want to allow undefined / null, it would be better to make the parameter required, but have it take ?number | |
| 236 | Same feedback as above | |
| web/search/message-search-state-provider.react.js | ||
| 124 | Same feedback as above | |
Comment Actions
Instead of using another variable, could we pass query to appendResults and check if it's still the same?
Comment Actions
queryID was optional in useSearchMessages, because useSearchMessages is used on native which didn't use the queryID, but it actually should
Comment Actions
Instead of using another variable, could we pass query to appendResults and check if it's still the same?
No, because someone might:
- query for 'a', wait to see results (server call no 1), scroll down and start fetching the second page of results for 'a' (server call no 2)
- query for 'b' (server call no 3)
- query for 'a' (server call no 4)
then they would see results for server call 2, so the second page of the results for 'a', instead of the first page