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:

https://github.com/Synphonyte/leptos-struct-table/blob/53a40d46f0210ad88eaaeea93c0acca90fe0cbb3/src/components/table_content.rs#L454-L501

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.