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 :)

[8forty]

TBH I'm more concerned about the bug that requires 1.1 etc. to scroll to the bottom instead of 1.0 which should work. Clarifying the interface is a good idea too. @falkoschindler should I create a separate discussion and/or issue to track that bug? Or are you convinced e.g. that it's a problem in Quasar so not a nicegui issue?

And please note that if the interface is modified so that values greater than 1.0 are treated as whole-number percent values (range 1-100), unless the bug is also fixed that would break my current workaround since 1.1 would be reinterpreted as 1.1% rather than its current interpretation as 110%.

[falkoschindler]

@8forty I just checked and it indeed seems like a Quasar issue. Here is a minimal NiceGUI demo:

def add_label():
    with scroll:
        ui.label('Hello')
    scroll.scroll_to(percent=1)

scroll = ui.scroll_area().classes('w-40 h-40 border')
ui.button('Add', on_click=add_label)

And here is a plain Quasar demo which behaves identially:

<html>
  <head>
    <link href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900|Material+Icons" rel="stylesheet" type="text/css" />
    <link href="https://cdn.jsdelivr.net/npm/quasar@2.17.6/dist/quasar.prod.css" rel="stylesheet" type="text/css" />
  </head>
  <body>
    <div id="q-app">
      <q-scroll-area ref="scrollArea" style="width: 100px; height: 100px; border: 1px solid #ddd">
        <div v-for="(label, index) in labels" :key="index">{{ label }}</div>
      </q-scroll-area>
      <q-btn label="Add" @click="addLabel" />
    </div>
    <script src="https://cdn.jsdelivr.net/npm/vue@3/dist/vue.global.prod.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/quasar@2.17.6/dist/quasar.umd.prod.js"></script>
    <script>
      const app = Vue.createApp({
        setup() {
          const labels = Vue.ref([]);
          const scrollArea = Vue.ref(null);
          const addLabel = () => {
            labels.value.push("Hello");
            Vue.nextTick(() => scrollArea.value.setScrollPercentage("vertical", 1));
          };
          return { labels, scrollArea, addLabel };
        },
      });
      app.use(Quasar);
      app.mount("#q-app");
    </script>
  </body>
</html>

So we might better report it to https://github.com/quasarframework/quasar/.

[8forty]

@falkoschindler thanks for the pointer, I found a reference in the quasar discussions from 2 years ago here

Looks like the response from quasar (pdanpdan) is: "But if your use case is to always scroll to bottom when new content is added then just get the scroll target and set scrollTop add needed"

This sounds like the "UGLY" fix (with run_javascript...) I posted above, right?

Interestingly, setting the percentage higher in your plain Quasar demo helps, e.g. using 2 doesn't show the 6th "Hello" when it should, but then works right for the 7th+. Using 100 makes it work for all.

I wasn't sure what to say in that quasar discussion, since they seem to think it's not a bug but rather incorrect usage (if I'm understanding the discussion correctly, I'm a javascript novice at best). So I replied with your example code and a note about using 100 as the percentage.

[falkoschindler]

I found a reference in the quasar discussions from 2 years ago

Great!

This sounds like the "UGLY" fix (with run_javascript...) I posted above, right?

Yes, indeed.

Given the mentioned debounce time of 100ms (or 110ms to be sure), we can implement another ugly solution:

async def add_label():
    with scroll:
        ui.label('Hello')
    await asyncio.sleep(0.11)
    scroll.scroll_to(percent=1)

scroll = ui.scroll_area().classes('w-40 h-40 border')
ui.button('Add', on_click=add_label)

I think my preferred solution would be to simply scroll to a ridiculous number like 1e6:

scroll.scroll_to(percent=1e6)

This works in all cases, there's no delay, and the code is concise and readable - with a number like 1e6 (one million) as an indicator for "basically infinitely large".

[ed2050]

@falkoschindler sleep prevents the page from doing anything else during that time. What about ui.timer instead?

[falkoschindler]

@ed2050 While time.sleep does indeed block code execution on the current thread, asyncio.sleep doesn't. So it is totally fine to use it to delay code execution in async functions.

[ed2050]

@falkoschindler yes it doesn't block the current thread, but it does block the current page. or at least the current handler. in this case add_label doesn't have anything else to do. in real code, there might be other actions to perform.

I say handler because if user initiates another event on same page while add_label is running (eg clicks a button), perhaps that starts a new handler that runs fine (not sure how nicegui event model handles multiple simultaneous events from same page).

[falkoschindler]

Sure, I assumed scroll_to to be called as the last command in add_label. It pauses the execution of the current task (e.g. the event handler), but it doesn't "prevent the page from doing anything else during that time".

Each event handler runs in a separate task. So awaiting a delay in one handler doesn't affect the execution of another handler.