Closed sparkison closed 7 years ago
Interesting idea. I guess that’s possible to implement.
+1 superb feature, hope to see that, any idea how to do it meanwhile?
I would just use asynchronous search if the list is too long. Or just use the optionsLimit
prop to limit the options and force the user to use the search.
Yes but how do you know you are at the end of list letssay first 100, is there a easy way to detemine that scroll top botom? I can keep page and pagesize hidenn.
I guess I could implement some events based on current pointer position. Would that work?
I think so, one event with event parameter coming describing the position should be enough..
To cover scenarios, when you scroll to top or bottom last item, to add or replace items. Second one would be that lets say you don't allow to user scroll to end, fire it x items before he reaches end or at some special button at the end..
To put some context around it, like we have lists in db that are 10 000s of them but you want to display like 100 at time. And user is typically searching in drop-down selecting, filtering and going through page by page - paging scenario.
Some time ago Telerik had something like this, when you scroll down and you have the option load mode, or next page and at the end was some kind of label displaying how many items are left. I find idea of paging more, since it saves memory and user can go through all the items if the search brings that result.
Hm, I think what you just suggested is even better! Thanks a lot!
For such cases, I could create a special option (with slot) showing at the end of the list, that can display a message containing how many more records there are or a message like 275 options left. Click to show more or change your search query. (can be anything really) and clicking on it would trigger something like @loadmore
event that would make it possible to push more options to the options list.
What do you think?
That's ok, but I think it's better for the component when it does not implement all possible things. How about creating an additional library that allows infinite scroll?
@pczarn infinite scroll by itself won’t make it as it would require refactoring the whole thing making the library unnecessary large, for little gain as I believe that needing infinity scroll inside a dropdown is an edge-case and is by itself more of a UX problem than tooling. Such cases should be resolved by better search or in worse-case a load more option, that’s easy to implement. However even this should be used carefully because it won’t make it possible to load a really large number of options anyway.
It will be superb feature either way. Just to make it simple and flexible as possible like async search is. Remember some event occurs (like loadmore or scrollend, scroplltop) and you just want to react to it, replacing the list or loading more, showing some one or two buttons. Slot is not bat idea at all to have the possibility to show some dynamic content down there.
The best if you can think of, that developer like me - Can decide between if he ll implement paging (that means he replaces the items and put cursor at begging of list, at the end showing like page 2of 500, there you need probably two buttons back and forward), or load more option with one button. But here you are taking risk to load hole database with some heavy users which I am opposer. They ll complain its slow since their browser just ate all the ram when loading lists.
Search paging - Its very common task especially now days with big data in databases when you search and you go through pages like google does. Just brain storming here, looking for best simple option that would be flexible for us all...
Maybe we should look around first for concrete solutions implemented I dint check them all.
Yeah, that’s why I want to discuss it up to the point we exactly now what we need and make sure it doesn’t introduce additional complexity. Even though I managed to cut the size from 33kB min.js to 15kB min.js + 6kB min.css (before gzip) in the incoming release I still think the component is already big for what it is supposed to do. Also adding features means we have to support them in the long run so it’s better to avoid problematic things in favor of flexible API that makes it possible to implement some features on top of it.
There are already slots like beforeList
and afterList
that could be potentially used to create pagination inside the dropdown. @Jack85 maybe you could explore the usage of those slots and instead of adding a new feature, we could just add an example on the docs for others, if the slots are sufficient enough?
Absolutely. KISS - keep it simple stupid- they taught me... That example would be great.. More extensible it is, more flexible it is for us all. Features like templating the items, with paging inside is the holy grail feature. Thanks for your feedback its great work here.
I managed to have infinite scroll without a button by adding vue-observe-visibility
to the afterList
slot like this:
<multiselect ... >
[ ... ]
<template slot="afterList">
<div v-observe-visibility="reachedEndOfList" v-if="hasNextPage" />
</template>
</multiselect>
and
reachedEndOfList(reached) {
if (reached) {
this.fetchNextPage();
}
}
more info here https://github.com/Akryum/vue-observe-visibility
hope this helps
@teripaquitinho ..very cool
Hi @teripaquitinho, could you please elaborate a little bit more? Where hasNextPage
property is comming from? Is it a value as a response from DB indicating there are more rows to show?
Thanks in advance
@Imboga Just a computed and return a condition. E.g. if you have pagination:
hasNextPage() { return this.currentPage + 1 <=this.totalPages }
@teripaquitinho Could you please elaborate on how did you make the afterList show up as continuation to the multi-select options after the original list of options in the dropdown?
If using the ajax functionality, would be great to have an event for when the user has reached the end of the results to load more, if more exist (similar to how Select2 does it)