From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 286361FF168 for ; 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 , Proxmox Datacenter Manager development discussion References: <20250120093006.927014-1-d.csapak@proxmox.com> <20250120093006.927014-3-d.csapak@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" 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 >> --- >> 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