[pdm-devel] [PATCH yew-comp 2/7] tasks: load more tasks on end of list

[Dominik Csapak]

On 1/20/25 18:29, Thomas Lamprecht wrote:
> Am 20.01.25 um 10:29 schrieb Dominik Csapak:
>> and prevent the list to load multiple times the same data when filters
>> change rapidly (e.g. on first render or when the user enters text in
>> the filters)
> 
> The load debouncing would have been better off as separate commit IMO,
> quite unrelated to the auto-load feature, but already pushed out so to
> late to improve here..
> 
>>
>> reset the list when the filters changed or the reload button is pressed.
>>
>> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
>> ---
>>   src/tasks.rs | 72 ++++++++++++++++++++++++++++++++++++++++++----------
>>   1 file changed, 59 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/tasks.rs b/src/tasks.rs
>> index fa17602..0ef80c6 100644
>> --- a/src/tasks.rs
>> +++ b/src/tasks.rs
>> @@ -6,6 +6,8 @@ use anyhow::Error;
>>   
>>   use pwt::widget::form::{Field, Form, FormContext, InputType};
>>   
>> +use gloo_timers::callback::Timeout;
>> +use serde_json::Map;
>>   use yew::html::IntoPropValue;
>>   use yew::virtual_dom::{VComp, VNode};
>>   
>> @@ -26,6 +28,10 @@ use crate::{LoadableComponent, LoadableComponentContext, LoadableComponentMaster
>>   
>>   use super::{TaskStatusSelector, TaskTypeSelector};
>>   
>> +const FILTER_UPDATE_BUFFER_MS: u32 = 150;
>> +const BATCH_LIMIT: u64 = 500;
>> +const LOAD_BUFFER_ROWS: usize = 20;
> 
> Any reasoning on those sizes? Don't get me wrong, I'm fine with values being
> chosen empirically, hard to do that otherwise here, but some background would
> be still nice to have should one have to adapt those sometimes.

the batch limit is the same as the PVE/PBS (extjs) one, so no real
thought went into here

the filter update buffer ms is a bit dependent on typing speed, so
this was just a value that seemed to work for me (when i typed
not overly fast or slow). I don't think there is really a good
value that fits all sadly

> 
> I.e., could it make sense to make that dependent on the height of the
> component? Or maybe allow overriding the batch-limit from the user, if one
> wants to filter through much more tasks, but that one is not really important
> for this patch now.

the buffer rows has more to do with scroll speed than component height
and i tried to find a good compromise between loading too early
when it's not clear the user wants to look so far back vs
too late when the user is already at the end (while trying to scroll
in a "normal" speed)

i can add some comments here if you want

> 
>>   #[derive(PartialEq, Properties)]
>>   #[builder]
>>   pub struct Tasks {
>> @@ -75,6 +81,7 @@ pub enum ViewDialog {
>>   pub enum Msg {
>>       Redraw,
>>       ToggleFilter,
>> +    LoadBatch(u64), // start
> 
> "start offset" might be a bit more telling, "offset" probably would
> have been the better name for this, but well, that ship has somewhat
> sailed for now (in our released products backends).
> 
>>       UpdateFilter,
>>   }
> 
>