I’m currently doing a spike on setting up custom scrolling logic in Elm.
The idea is that if you have a large file to display, perhaps a log or a large file in an editor, rendering the full view for it each time, can be slow. The default way of using overflow: scroll on the div works, but is not optimal. Instead scroll bars are set up in separate divs to the one showing the content, their scroll events are hooked up, and custom logic will take a slice of the content and render a smaller view just for what is visible.
Has anyone done this before?
I had done a similar thing, scrolling a list with 100000 entries. It works, as long the displayed lines or entries have the same height. I used an idea, I found somewhere on github, implemented in jquery, but I can not find the original source anymore.
Thinking about it, do I even need the big divs before and after the viewport? I was going to use “position: absolute” on each line div anyway. So if I just position the lines correctly within the overall container div, and then scroll that? I’ll give it a go anyway.
Thanks for that tip. I was searching for “custom scrolling” which only turns up hits for how to customize the look of scroll bars with CSS or other techniques - was thinking it is hard to search for what I am after as a result.
So I’ve done all that and updated the demo, seems to work pretty nicely:
I made use of Html.Lazy and Html.Keyed and I could see that made a small but barely discernable difference in performance.
The only other thing I would like to do is to override the arrow key and page up/down events, so that they always scroll by an exact integer number of lines. When going down, the last visible line of text should appear whole at the bottom, when going up the first visible line should appear whole at the top.
We have an infinite sc[quote=“rupert, post:9, topic:6403”]
The only other thing I would like to do is to override the arrow key and page up/down events, so that they always scroll by an exact integer number of lines.
If you are writing a text editor I might be worth capturing all keyboard events to have full control of what is going on, specially if it is going to be an advanced text editor. Check elmMPS, for instance; I think that it would be impossible to create it without taking full control of use input.
Implemented this too. Now arrow keys or page up/down always move in increments modulo the line height with the top or bottom line always holding a full line, depending on which direction you are scrolling towards. That really helped make the scrolling look smooth. I also found that rendering above and below 1 full page of lines removed any flicker on page up and down:
I think @Janiczek and @kraklin have something similar in app the’re working on at work. just in that case it’s not a text but a table and it also performs network requests per cells with scrolling both on x and y axis.