how to make a ScrollArea autoscroll?

[8forty]

Question

I'm trying to make a ScrollArea auto-scroll vertically to show the bottom line every time it's refreshed. Clicking my "ADD" button always adds another line but the scroll_to() has unpredictable results: sometimes scrolls to the bottom, sometimes to the line before the bottom, sometimes does nothing.

Anybody know what I'm doing wrong?

from nicegui import ui
from nicegui.elements.scroll_area import ScrollArea

numbers = list(range(0, 10))


def setup(path: str):
    @ui.refreshable
    def show_numbers() -> None:
        for i in numbers:
            ui.label(f'scrolling:{i} ')

    def add(scroller: ScrollArea):
        numbers.append(len(numbers))
        show_numbers.refresh()
        scroller.scroll_to(percent=1.0)  # this is unpredictable

    @ui.page(path)
    def index():
        ui.button(text='add', on_click=lambda: add(scroller))

        with ui.row():
            with ui.card().classes('w-32 h-48'):
                with ui.scroll_area() as scroller:
                    show_numbers()
                    scroller.scroll_to(percent=1.0)  # this works on initial display


if __name__ in {'__main__', '__mp_main__'}:
    setup('/')
    ui.run(host='localhost', port=8000, show=False, reload=False)

[ed2050]

Just a guess - I get anomalous behavior like this when DOM content isn't fully loaded yet. Try a short pause before scroll_to, something like :

ui.timer (0.1, lambda : scroller.scroll_to (percent=0.5), once = true)

But note that pausing in nicegui server doesn't guarantee a pause in client browser. You can either increase the pause time, or issue the scroll behavior directly in client with ui.run_javascript.

Or my guess is wrong and cause is something else entirely...

[8forty]

Thanks for the suggestion, I figured it was a timing thing between the server and client. Using the client.connected() method from nicegui's chat example was necessary.

Along with that I found a reliable solution, but it is UGLY, using an invented class as a marker and hard-coded element traversal based on my observations of the internal div structure created by nicegui for a ScrollArea. The getElementsByClassName()[0] finds the "q-scrollarea" element thanks to my hopefully-forever-unique class naming convention, but scrolling that does nothing. It's firstElementChild is a "q-scrollarea__container", but that's obviously an internal detail that I'd rather not rely on if possible.

FWIW I'm def nowhere near a css/javascript expert, so looking for any suggestions that would improve and maybe future-proof this.

(And I'm still wondering if there isn't some way to get ScrollArea's scroll_to() function to work reliably, otherwise what use is it?)

import builtins

from nicegui import ui

numbers = list(range(0, 10))


def setup(path: str):
    @ui.refreshable
    async def show_numbers(scroller_class: str) -> None:
        for i in numbers:
            ui.label(f'scrolling:{i} ')

        # make sure client is connected before doing javascript
        try:
            await ui.context.client.connected(timeout=5.0)
            await ui.run_javascript(code=f"const sdiv = document.getElementsByClassName('{scroller_class}')[0].firstElementChild;"
                                         f"sdiv.scrollTop = sdiv.scrollHeight;")
            # scroller.scroll_to(percent=1.0)  # this is unpredictable, usually scrolls to penultimate item
        except builtins.TimeoutError:
            pass

    def add():
        numbers.append(len(numbers))
        show_numbers.refresh()

    @ui.page(path)
    async def index():
        ui.button(text='add', on_click=lambda: add())

        with ui.row():
            with ui.card().classes('w-32 h-48'):
                sclass = 'kfname-scroll-area-scroller1'
                with ui.scroll_area().classes(add=sclass):
                    await show_numbers(sclass)


if __name__ in {'__main__', '__mp_main__'}:
    setup('/')
    ui.run(host='localhost', port=8000, show=False, reload=False)

[8forty]

For any that are still following this, I found a much cleaner and simpler solution by dropping the @ui.refreshable, and instead explicitly clearing then refilling ScrollArea PLUS setting the scroll_to() percent to 1.1 (or 2.0 or 100.0) solved the problem of scrolling to the penultimate element in the list (maybe a rounding error when translating % to pixels?):

from nicegui import ui
from nicegui.elements.scroll_area import ScrollArea

numbers = list(range(0, 10))


def setup(path: str):
    async def show_numbers(scroller: ScrollArea) -> None:
        for i in numbers:
            ui.label(f'scrolling:{i} ')
        scroller.scroll_to(percent=1.1)

    async def add(scroller: ScrollArea) -> None:
        numbers.append(len(numbers))
        scroller.clear()
        with scroller:
            await show_numbers(scroller)

    @ui.page(path)
    async def index():
        ui.button(text='add', on_click=lambda: add(scroller))

        with ui.row():
            with ui.card().classes('w-40 h-48'):
                with ui.scroll_area().classes() as scroller:
                    await show_numbers(scroller)


if __name__ in {'__main__', '__mp_main__'}:
    setup('/')
    ui.run(host='localhost', port=8000, show=False, reload=False)

[falkoschindler]

@8forty Your solution with percent=1.1 (or even percent=1000) seems to work even with ui.refreshable. It avoids some kind of race condition (which I don't fully understand yet) by simply scrolling "as far as possible". If the scroll area grows in the meantime (maybe while animating the scroll), it won't stop one line short.

Anyway, this made me realize that the percent parameter has a pretty confusing range: I would have expected it to go from 0 to 100. But, like QScrollArea, it expects values from 0 to 1 instead.

[8forty]

Oh cool, I took out refreshable first while debugging this, then discovered the percent value. I agree that "percent" parameter is confusing, but its type being float is a clue. I don't think there's an agreed-on term in English to specify "35%" vs. ".35", e.g.: math.stackexchange. percent_in_its_decimal_form is probably too long :)

[ed2050]

I agree that "percent" parameter is confusing, but its type being float is a clue. I don't think there's an agreed-on term in English to specify "35%" vs. ".35", e.g.: math.stackexchange. percent_in_its_decimal_form is probably too long :)

Per your link, "percent" itself literally means fraction per 100. 100 is denominator, value is numerator 0-100. Seems perfectly clear to me. There's a whole wikipedia page on it that doesn't even mention expressing as range 0.0-0.1. Wiki isn't authoritative but does reflect common understanding.

There's no need for "percent in its decimal form" because 45% == 0.45 by definition. Mathematically they are the same thing. There's no ambiguity because 0.45% is 0.0045 not 0.45. Yes we all know this, my point is -

The problem isn't English, the problem is the function. It says percent, it should take 0-100. As apparently other nicegui funcs do.

If python had a percent data type, this problem would go away. It really should since this issue happens all the time. But it doesn't, so moving on...

Solutions

There are at least a few ways to solve this:

1. By convention, funcs take int for 0 to 100% and float for 0.0 to 0.1. Data type tells you what form to pass. As long as you don't need values between whole numbers, int works fine for most things. Eg progress bar doesn't need to show exactly 45.6%, int is close enough.

If starting from scratch, I would take an int here and be done with it. But given that current nicegui API uses range 0-1, that would break existing apps. So best to find another solution.

2. Another option is to accept either. If value is float from 0-1, interpret as decimal. Otherwise interpret as numerator. Question is what to do with 1 which can go either way. You could treat int 1 as 1% and float 1 as 100%. May cause confusion in some circumstances, but at least the cases are limited.

I like this option best, despite the potential confusion.

3. Or take two separate parameters, an int and a float. Given current API takes float, perhaps int should be second parameter. But sounds like that differs from other nicegui funcs which take int percent as first and only param.

That's what I came up with. Any other ideas?

[8forty]

Thanks for your thoughts. But I think you kinda buried the lead, i.e. that 1.0 with the current implementation doesn't actually show the last line in this case, which from @falkoschindler's answer sounds like it might be a problem in Quasar.

If somebody really wants to change the interface, I'd add that probably a large percentage (whole-number or decimal haha) of use-cases for this function want to scroll to either the top or bottom rather than anywhere in between, so it'd be cool to have functions scroll_to_top and scroll_to_bottom.

[ed2050]

I took a different meaning from falko's post. Not as a problem in quasar, just a difference in what form it expects. Anyway doesn't matter what Quasar wants. Nicegui hides quasar from us and can convert form if needed.

He also mentions a possible race condition. Perhaps that's what you meant by problem. I wouldn't attribute that to quasar yet; could just as well be caused by interactions between nicegui and any other part of the stack.

Anyway we'll see. scroll_to_random FTW! 😄