-
-
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
support multiple directions #55
Comments
This sounds a lot more like pagination than infinite scroll. However, you could use the Let me know if this doesn't properly answer your Question! |
This request is a nice one .. basically to have infinityLoader accept either next page and append to model or previous page and prepend to model. I'm doing something similar to OP. In which we keep page in query params. So on a refresh it will start with the proper page on the route model hook. And we know when we reach top of scroll so we want to fetch and scroll to page -1. Infinite scroll functionality shouldn't be a forward only limitation. Thanks for the great addon. |
For people who want this functionality out of a component, I recommend looking at https://github.com/runspired/smoke-and-mirrors which is a more scalable scroll view and is direction-agnostic - supports loading in the front or end of the list, and even loading 2d grids. |
Yes @davidgoli the funny thing is I'm using both together as I love the mixin used with ember-infinity |
This is kind of a crazy idea, but I might end up implementing it.
The idea would be, in the route, instead of
_currentPage
we have a_minPage
and a_maxPage
. Whenever we refresh the model, they both start asoptions.startingPage
.We also have
_canLoadNextPage
and_canLoadPrevPage
. These are computed by comparing_maxPage
to_totalPages
and_minPage
to1
, respectively.Finally,
_infinityLoad
would take a direction, which would control whether we do_maxPage++
or_minPage--
and whether we domodel.pushObjects
ormodel.unshiftObjects
.On the component side, I would have two infinity loaders, one at the top of my list and one at the bottom, and the scroll checks would be different for each. Alternatively I might implement it in a component that wraps my list and just checks its scroll offset.
So, this is kind of a crazy idea and I'm not sure if it's generally useful enough to be included in this library, but if it were possible to make it work backwards-compatibly (no pun intended) with the current
ember-infinity
interface, would anyone be interested in including it as part of this library?This is still pretty speculative but it does solve some business needs I'm up against, and if we end up deciding to implement two-way infinite scroll it might be a nice thing to contribute.
The text was updated successfully, but these errors were encountered: