Comments (2)
Hi @vishalgspaceo,
I carefully examined the issue reproduction steps you provided.
Actually this behaviour caused by an intended memory optimization. To avoid running out of device memory during the aggressive hits scrolling, the pagination engine keeps in memory 3 pages of hits before the first visible result and 3 pages of hits after last visible result. The value 3 is a hardcoded empirically derived value.
Let's examine the cases you reported one by one.
First of all, these issues are not related to multi-index search. You can reproduce them in the single index search experience as well by setting the same parameters values.
Given:
Search result screen presenting 3 result hits at once (the case of multi-index demo).
1. First case
Query.hitsPerPage = 1
means that 1 page of results is equivalent of 1 hit
HitsInteractor(infiniteScrolling(.on(withOffset: 10)))
means that the pagination engine might ensure the presence of 10 hits before the first visible hit and 10 hits after the latest visible hit and trigger the corresponding network request if needed.
pageCleanUpOffset = 3
means that the pagination engine when the page with index n
is loaded, removes the pages with indices less than n-3
and more than n+3
.
- The multi-index search example presents 3 hits on the screen at once with indices 0, 1, 2.
- Three search requests will be instantly performed to ensure their appearance.
- The first presented hit has index 0, so the pagination engine doesn't request the 10 preceding hits.
- The latest presented hit has index 2, so the pagination engine might ensure the presence of hits at indices 3...12.
- Since the
hitsPerPage
parameter is set to 1, it will perform 10 more network requests to fetch pages/hits at indices 3...12 (by the way, each of them counts as a separate search operation). - The problems start when you get the hit/page with index
4
. SincepageCleanUpOffset
is equal to 3, the pagination engine will purge the pages with indices less than 4-3 = 1 and 4+3 = 7. As result, the page/hit 0 will be purged. But the hit 0 is visible right now, so it will be requested again. - When the page/hit 0 is fetched, the pagination engine will purge the pages with indices greater than 0 + 3 = 3, so the page/hit 4 will be purged.
Here we have an infinite loop due to concurrency between the infinite scrolling offset value and the page clean-up offset due to smallhitsPerPage
value.
2. Second case
Query.hitsPerPage = 10
HitsInteractor.infiniteScrolling(.on(withOffset: 40)
pageCleanUpOffset = 3
- When the latest visible hit at index
2
appears it asks the pagination engine to ensure the presence of hits with indices 3...42. - The hits 0...9 are already fetched during the initial search request, so the hits to request have indices 10...42.
- Since
hitsPerPage
is set to 10, it will require 4 additional network requests to fetch 4 pages of 10 hits (10+10+10+ one more page of 10 from which the pagination engine only requires first 3 hits). - And once again, when the 4th page is fetched and since
pageCleanUpOffset = 3
, the pagination engine will purge the pages with indices less than 4 - 3 = 1 and 4 + 3 = 7. So the first page with index 0 will be removed. But this is the first page which appears on the screen right now, so the pagination engine will request page at index 0 again and once it's fetched, will cleanup the page4
. One more inifinite loop.
Conclusion
Since from the InstantSearch side we cannot control or predict the number of visible hits due to different rows/cell sizes or even dynamic autolayout sizing, we decided to keep the pagination parameters configurable.
The default configuration:
- 20 hits per page
- 5 hits required before the first visible hit and after the last visible hit
is reasonable for most mobile search experiences to ensure a decent performance. You can fine tune these parameters to ensure the best performance in your application. The fact that they are exposed doesn't mean that everything might work flawlessly with any set of values of these parameters.
Briefly:
- It's not a good idea to set the
hitsPerPage
value less than the number of hits appearing on the screen. You might want to present at least one page of hits on you screen at once. - It's not a good idea to set the infinite scrolling offset value greater than
hitsPerPage
value. The reason of this parameter is to request 1 more page before/after the visible area to ensure the smooth infinite scrolling.
We expect that if a developer alters the default values of these parameters, he knows what he is doing.
The only problem I see here is the private and hardcoded pageCleanUpOffset
parameter and the missing warning in the documentation to be careful with pagination parameters
If you have a concrete infinite scrolling/pagination issue with your implementation where such specific pagination parameters make sense, I would be glad to discuss it and to find an optimal solution.
from instantsearch-ios.
Hi @vishalgspaceo,
Thank you for reporting this issue.
It is prioritized in our roadmap, I'll notify you when the patch is ready.
from instantsearch-ios.
Related Issues (20)
- Compile error, Variable used within its own initial value HOT 1
- Insights: expired events in a batch make the server decline the whole batch
- Xcode 13 RC Instansearch Errors HOT 4
- InstantSearch not working with Swift 5.5 HOT 5
- Unable to load instantsearch-ios in Xcode 13 project via SPM HOT 1
- Paqq HOT 1
- HighlightedString support in SwiftUI HOT 2
- Cannot Build InstantSearch Using Carthage HOT 5
- InstantSearch iOS Numeric Range Iteractor/Connector not refreshing when searcher search changed HOT 1
- Infinite requests when using LazyVGrid on MacOS HOT 3
- Not able to set log level HOT 2
- Recommendation like Get Trending Global Items in iOS
- Add custom JSONDecoder property to HitsInteractor HOT 2
- Pagination for HitsController not working sometimes in iOS HOT 3
- Incorrect facet selected attribute value on Hierarchical filter HOT 1
- Incorrect number of hits on HitsInteractor when using pagination (infinitescroll) HOT 4
- Wrong issue
- Add the possibility to map the index data model to a custom data model when fetching hits HOT 2
- Empty queries conditional display not working in HitsObservableController
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from instantsearch-ios.