range search

[tj]

not a big deal right now but once we have more components the initial dom junk will be pretty heavy if we dont do an infinite scrolling sort of display

[buschtoens]

+1 on infinite scrolling

Do we already have a component for that? Haha :D

[ForbesLindesay]

I haven't noticed one, but we should definitely make one rather than just in-lining in this project.

[buschtoens]

Hm, how should we design the API? One function à la scroll([frame], parent, content)? Where content is a function that returns DOMElements that then get appended to parent.frame is optional and defaults to parent and is the DOMElement we listen on for scroll events.

[tj]

infinite(el, loadCallback) should be good enough to get started but it would need flexibility to prime the page etc as well

[buschtoens]

I'm utterly sorry, but what exactly do you mean by "priming the page"?

How can this component be flexible? It's only purpose is to load elements from loadCallback and append them to el. Haha.

[ForbesLindesay]

It should also detect when we get to the bottom of el. Perhaps it would also make sense to have it take responsibility for requesting the first set of elements from loadCallback as well (might be simpler than pre-filling them into the page)

[buschtoens]

infinite would start hitting on loadCallback everytime the user gets near the end. This way we're not bombing the server, but have no visual lag for the user.

What about loadCallback returning an array of 10 to 20 elements?

[tj]

it doesn't need to do much other than detect the scrolling threshold, insertion of the elements could be up to the user

[buschtoens]

Here it is: infinite(el, loadCallback, [margin])

If you're ok with this I'll try to implement it in the search.

[tj]

sweet :D probably worth debouncing the onscroll to ~100ms or so but sounds good!

[vendethiel]

@silvinci nice stuff !

[buschtoens]

@Nami-Doc Thanks. :)

@visionmedia After one load is triggered, all following scroll events are ignored, until loadCallback makes Infinite resume.

infinite(el, function(iteration, resume) {
  resume();
}):

But I can switch to debounce, if you want to. But this might issue some unnecessary calls, as some ajax request might take up longer than 100ms.

[tj]

ah I see, maybe add a counter like ++this.page when it goes to load, then you can compare the offset expected to trigger the next "page" regardless of it being ready or not

[buschtoens]

Uhm, isn't that what iteration is for? Haha. It goes 1 up, everytime loadCallback is issued.

So shall I just remove that resume() callback and then debounce? You'd still be able to Infinite.pause() and Infinite.resume().

[tj]

ah missed that

[buschtoens]

I think debouncing is safe, as all that could possibly happen, is that we load up a bit of data, that isn't used right now, but would be loaded at the next scroll event anyways.

[buschtoens]

Okay, it now debounces 100ms. I'll try to implement it.

[jonathanong]

limited to 25 components now. shit was super slow before, especially when using reactive