For pagination with PaginatedTableDataProvider the method get_page is called for too much page indexes and repeatedly

[VincentBaijot]

Hello,

Thanks for this promising package. It seems awsome but when i tested it i saw one strange behavior.

I made a simple table very close to the paginated_rest_datasource example and i made it log the calles to get_page and row_count.

impl PaginatedTableDataProvider<Game> for GamesDataProvider {
    const PAGE_ROW_COUNT: usize = 20;

    async fn get_page(&self, page_index: usize) -> Result<Vec<Game>, String> {
        log::info!("get_page {page_index}");
        if page_index == 0 {
            Ok(self.games.clone())
        } else {
            Ok(vec![])
        }
    }

    async fn row_count(&self) -> Option<usize> {
        log::info!("row_count");
        Some(self.games.len())
    }
}

And i displayed the table with this data in a page :

    let games = move || GamesDataProvider::new();

    let pagination_controller = PaginationController::default();
    let container = NodeRef::new();

    view! {
        <div class="lg:flex lg:items-center lg:justify-center m-8" node_ref=container>
            <table class="text-sm text-left text-gray-400">
                <TableContent
                    rows=games()
                    display_strategy=DisplayStrategy::Pagination {
                        controller: pagination_controller,
                        row_count: 20,
                    }
                    scroll_container=container
                />
            </table>
        </div>
    }

With the parameters above row_count 20 and PAGE_ROW_COUNT 20 then only the page with index 0 is necessary, but what i observed is that he get_page function is called for page indexes 0, 1, 2, 3, 4, then again 0, 1, 2, 3, then 0, 1, 2, then 0, 1, and finally 0.

Did i misuded the api ?

I join a minimal example to reproduce the issue.
test-leptos-table.tar.gz

Thanks

[maccesch]

Thanks for the detailed report!

There is some overscan so it should indeed load more than is displayed but what you describe sounds like a bug indeed.

I'm in the process of extracting out the pagination and virtualization logic so I hope to fix this while doing that.

[geofmureithi]

@maccesch any update on this? Any help we can offer?

[maccesch]

Sorry for the silence. Things are going slow because I don't have a lot of bandwidth. If you want to try and fix it I'd be happy to accept a PR.

[geofmureithi]

Do you have a plan/roadmap or guide on how you want the implementation logic to look like.

[maccesch]

Ah sorry. I meant just to fix it in the current code base. It will take a while until I can port everything over to the generalized implementation.

[geofmureithi]

Ok I will pick up this bug and see where I get.

[geofmureithi]

@maccesch The problem comes form the way data is loaded:

leptos-struct-table/src/components/table_content.rs

Lines 454 to 501 in 53a40d4

	let missing_range =
	loaded_rows.with_untracked(|loaded_rows| loaded_rows.missing_range(range.clone()));
	if let Some(missing_range) = missing_range {
	// Ensure missing_range is valid *after* all calculations
	let missing_start = missing_range.start.min(missing_range.end);
	let missing_end = missing_range.end; // Already correct
	let missing_range = missing_start..missing_end;
	if missing_range.is_empty() {
	// Don't proceed with empty ranges
	return;
	}
	loaded_rows.write().write_loading(missing_range.clone());
	let mut loading_ranges = vec![];
	if let Some(chunk_size) = DataP::CHUNK_SIZE {
	let start = missing_range.start / chunk_size * chunk_size;
	let mut current_range = start..start + chunk_size;
	while current_range.end <= missing_range.end {
	loading_ranges.push(current_range.clone());
	current_range = current_range.end..current_range.end + chunk_size;
	}
	// when we got a missing_range which size is less than the chunk_size, add current_range to loading_ranges
	if current_range.end > missing_range.end && current_range.start < missing_range.end
	{
	loading_ranges.push(current_range);
	}
	} else {
	loading_ranges.push(missing_range);
	}
	// TODO : implement max concurrent requests
	for missing_range in loading_ranges {
	let compute_average_row_height = compute_average_row_height.clone();
	spawn_local({
	let rows = Rc::clone(&rows);
	let set_known_row_count = set_known_row_count.clone();
	async move {
	let latest_reload_count = reload_count.get_untracked();
	// TODO: can we avoid this?
	let result = rows
	.borrow()
	.get_rows(missing_range.clone())

It is checking if the all the possible rows are eagerly loaded, This logic affects multiple places in the repo. I think I would need some guidance on where to start because I am touching one part breaks some another part.

I also see a todo there, what was the goal?

// TODO : implement max concurrent requests 

[maccesch]

You can safely ignore the todo for now.