-
-
Notifications
You must be signed in to change notification settings - Fork 131
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
Bi-Directional Infinite Scrolling Pattern Limitations #293
Comments
Would love to help/collaborate on any work you may have up for the problem you are solving. Have this existing PR so far - #287 |
I'll see if I can push up the hook work I was doing this afternoon. I'm pretty sure I've got the semantics of some of the promises wrong, though. And I'm struggling a bit with extending the test suite in the library--very different patterns/techniques than my projects have. |
PS: I've been reading #287 as it goes along--it'll be good improvements when we get there, as long as those of us who don't use paged APIs can still get along! |
|
If that commit works I'll be surprised. That's basically exactly what I attempted to do in my app, in the subclass. Edited to note: the exception was thrown once I attempted to use the service inside the class. |
Update: I'm using 1.2.4 now as I picked back up my feature branch in progress. Lots of good changes there. However, to combine bidirectional loading (which can even be concurrent) with cursor/keyset pagination correctly required a number of adaptations to both the infinityModel and infinityService classes (subclassed them in our app). I'll be looking at our changes to figure out if there's a good abstraction I can push back upstream. One of the key concepts is that we can't rely on a single |
Ooh. Next problem. Race condition on |
So as I work on a branch for #292 (and the feature that gave rise to it) I've run into some thought problems.
I'm working with an app using non-linear paging (keyset pagination rather than limit&offset), heavily using the new subclass of
InfinityModel
pattern, and the next feature is likely to use bidirectional loading with two InfinityLoader instances, as outlined in the readme.afterInfinityModel
andinfinityModelLoaded
always presume that loading appending to the set. It'd be good to pass direction (and trackcanLoadMore
separately, perhaps) for 'up' as well as 'down', for the bidirectlonal-loading case. Maybe there are no more results 'after' the current point, but there might be some 'before'.Anyone have thoughts on the above? Some of this would affect interfaces somewhat...
The text was updated successfully, but these errors were encountered: