Enable lazy loading for trees

[moi90]

Quasar Tree provides a way to lazily load children when a node is expanded. It would be great to expose this functionality in the nicegui API.

[falkoschindler]

Hi @moi90,

That would be a nice addition to the ui.tree element. The main limitation is that, currently, normal event handlers don't send any return value back to the client.

One workaround is to use a JavaScript event handler:

ui.tree([{'id': 'A', 'lazy': True}], label_key='id') \
    .on('lazy-load', js_handler='''({ node, key, done, fail }) => {
        done([
            { id: `${node.id}.1`, lazy: true },
            { id: `${node.id}.2`, lazy: true },
        ]);
    }''')

Of course, this only makes sense if all information about nested nodes can be expressed as a JavaScript function.
Alternatively, if you need to request data from the server, you can fetch them from a dedicated HTTP endpoint:

@app.get('/children')
def get_children(node_id: str):
    return [
        {'id': f'{node_id}.1', 'lazy': True},
        {'id': f'{node_id}.2', 'lazy': True},
    ]

ui.tree([{'id': 'A', 'lazy': True}], label_key='id') \
    .on('lazy-load', js_handler='''({ node, key, done, fail }) => {
        fetch(`/children?node_id=${node.id}`)
            .then(response => response.json())
            .then(data => done(data))
            .catch(fail);
    }''')

Wrapping this approach into a nice API would be great, but not necessarily straightforward. Especially creating and pruning the additional endpoint needs to be done correctly to avoid memory leaks.

[aabrodskiy]

@falkoschindler I'm trying this approach and so far it seems working great.
What would be my strategy if I wanted to refresh data from a selected node down (refresh the node itself and its children, or collapse them all back into lazy)? Would I just delete children data and set the node again to Lazy=True? Is there a less hacky approach to this?

[aabrodskiy]

@falkoschindler one more thing I noticed and haven't found a solution so far - both event handlers (on_select, on_expand) interfere with lazy-loading. It seems the lazy-loading doesn't update internal state of the tree, so whenever the on_select or on_expand fire, they get the tree into some kind of inconsistent state, trying to set "selected" to an id that "doesn't exist" in the ui.tree. Also the lazy-loading stops working when the event handlers are assigned.

            self.tree = ui.tree(
                nodes=await self.get_home_node(), 
                # nodes=[data], 
                node_key="id", 
                label_key="name", 
                children_key="children",
                # on_select=lambda event: self.on_tree_node_selected(event),
                # on_expand=lambda event: self.on_tree_node_expanded(event)         
            ).props(add='selected-color=primary no-transition').classes('png-tree-icon')

            self.tree.on('lazy-load', js_handler='''({ node, key, done, fail }) => {
                         console.log('lazy-load', node)
                fetch(`/tmodel/get-tree-children?object_type=${node.type}&object_id=${node.id}`)
                .then(response => response.json())
                .then(data => done(data))
                .catch(fail);
            }''')

this code above works as it is and does the lazy-loading as expected, but the moment I uncomment the "on_expand" handler, the lazy-loading stops working.
And the moment I uncomment "on_select" handler, if I select a node, it disappears from the tree - I checked in the event handler, the "nodes" props only contains the initial node, not those nodes which were loaded later by lazy-load.

[aabrodskiy]

The only handlers work so far are those custom handlers, defined in the header slot that you suggested above:

        self.tree.on('lazy-load', js_handler='''({ node, key, done, fail }) => {
                         console.log('lazy-load', node)
                fetch(`/tmodel/get-tree-children?object_type=${node.type}&object_id=${node.id}`)
                .then(response => response.json())
                .then(data => done(data))
                .catch(fail);
            }''')

            self.tree.on('update:selected', js_handler='''(event) => {             <<<------- This doesn't fire and nothing prints into console
                console.log('select event:', event)
            }''')

            self.tree.add_slot('default-header', '''
                <span :props="props" 
                 @click="() => props.tree.$emit('node_selected', props.node)"
                 @update:expanded="(expanded) => props.tree.$emit('node_expanded', {node: props.node, expanded: expanded})">
                  Node <strong>{{ props.node.id }}</strong>
                    <q-menu touch-position context-menu>
                        <q-item clickable v-close-popup @click="() => props.tree.$emit('click_open', props.key)">
                            <q-item-section>Open</q-item-section>
                        </q-item>
                    </q-menu>
                </span>
            ''')

            self.tree.on('click_open', lambda e: ui.notify(f'Open "{e.args}"'))
            self.tree.on('node_selected', lambda e: self.on_tree_node_selected(e.args))    <<<<<----- This fires ok
            self.tree.on('node_expanded', lambda e: self.on_tree_node_expanded(e.args)) <<<<<< ------ This doesn't fire

[falkoschindler]

Sorry, @aabrodskiy, I haven't found the time to look into this more closely. I haven't worked with lazy-loading trees yet, but from the looks of it, it's getting pretty complicated.
Can anyone else help?

[aabrodskiy]

@falkoschindler It's ok, whenever you have any thoughts or ideas.
For now i'm doing "double loading" - i catch lazy-load both with JS Handler and with Python. And load the next level in both places. That allows me to sync up the state of the tree and fire all normal event handlers for it.

I could have avoided doing the JS Handler, but it doesn't work that way as it requires a direct data response on that event, which I can't figure out with python handler. So it stays in the loading state even if I load the data on the python side.

[moi90]

Thanks for your suggestions!

Would it be hard to enable event handlers to send a return value back to the client? Maybe it could be useful in other places, too. (I have not yet used the library, so I don't have a feeling for that. But I'm about to use it :))

[falkoschindler]

Yes, support for event handlers with return values would be helpful. But I guess it would require some kind of code introspection to check if an event handler will return something, so that the client can be instructed to wait for the return value. This needs to happen before calling the handler. And when thinking about it, it's probably not possible in every case, because a Python function could return something in some cases only. Alternatively we could introduce another parameter for event subscriptions...

[moi90]

Yes, I would guess that explicit is better than implicit.