From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pdm-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id 286361FF168
	for <inbox@lore.proxmox.com>; Tue, 21 Jan 2025 10:43:54 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 07D405598;
	Tue, 21 Jan 2025 10:43:52 +0100 (CET)
Message-ID: <20ac82e0-2340-460a-902b-e7a16405e26c@proxmox.com>
Date: Tue, 21 Jan 2025 10:43:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox Datacenter Manager development discussion
 <pdm-devel@lists.proxmox.com>
References: <20250120093006.927014-1-d.csapak@proxmox.com>
 <20250120093006.927014-3-d.csapak@proxmox.com>
 <f99fc19e-32c8-4bb9-b2f0-db496ff03bc0@proxmox.com>
Content-Language: en-US
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <f99fc19e-32c8-4bb9-b2f0-db496ff03bc0@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL -1.231 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
 Validity was blocked. See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
 information.
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [tasks.rs]
 URIBL_DBL_SPAM 2.5 Contains a spam URL listed in the Spamhaus DBL blocklist
 [tasks.rs]
Subject: Re: [pdm-devel] [PATCH yew-comp 2/7] tasks: load more tasks on end
 of list
X-BeenThere: pdm-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Datacenter Manager development discussion
 <pdm-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pdm-devel>, 
 <mailto:pdm-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pdm-devel/>
List-Post: <mailto:pdm-devel@lists.proxmox.com>
List-Help: <mailto:pdm-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel>, 
 <mailto:pdm-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Datacenter Manager development discussion
 <pdm-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pdm-devel-bounces@lists.proxmox.com
Sender: "pdm-devel" <pdm-devel-bounces@lists.proxmox.com>

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@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,
>>   }
> 
> 



_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel