search

chingu-voyages / v24-geckos-team-02

Books Plus | Voyage-24 | https://chingu.io/
GNU General Public License v3.0
1 stars 1 forks source link

TypeError on loading more than 500-650 cards as search results #49

Closed ArunJose closed 3 years ago

ArunJose commented 3 years ago

Describe the bug If around 500-650 cards are loaded as search results, it causes app to crash, sometimes showing an error page and sometimes the page going blank.

To Reproduce Steps to reproduce the behavior:

  1. Go to home page
  2. Make a book search with keyword "test"
  3. Repeatedly click on "more" button
  4. After loading around 550 search results the screen goes blank with the following error message in console.

react-dom.production.min.js:209 TypeError: Invalid attempt to spread non-iterable instance. In order to be iterable, non-array objects must have a [Symbol.iterator]() method.

Expected behavior Keep on loading more search results until it reaches 'totalItems' value given by the API. Even if API isn't giving any response, the app should not go blank or become unusable.

Additional context It appears Google Books API isn't giving any volumes/books data after startIndex query parameter goes over 500-650.

snrelghgub commented 3 years ago

@ArunJose this is just a wild guess, but I think I know what the problem is. The number of results isn't unlimited right? Our infinite scroll doesn't consider that, meaning that we need to find a way to keep track of the total number of results which can be displayed & stop fetching results if there are 'no more results'. And to be able to notify the User when they've reached the end of the list too. Let me know what you think & don't hesitate to correct me if I'm wrong as I haven't looked at the code implementation.

ArunJose commented 3 years ago

@snrelghgub The Google Books API returns a totalItems value with each search query denoting how many books are available for the given query. We were using this value to determine the last page. This proved to be unreliable as value of totalItems changes with different startIndex values for the same search term. But that is not all, the API stops supplying books/volume data when the startIndex starts hitting 500-650 range depending upon the query, regardless of the value of totalItems. The solution now implemented in the fix is to disregard value of totalItems altogether, for pagination. Using other logic to determine whether the given page is last or not - if a page only returns 10 items when asking for 20 we can determine that it is the last page, also if the API unexpectedly returns no book data, we have reached the last page. I couldn't find a way to accurately determine the actual number of total results available beforehand.

isLastPage state variable keeps track whether we have reached last page or not.