DataTable: Virtual scrolling doesn't work when rowGroup mode is enabled

[Tamas-hi]

Describe the bug

As the title says, I'have used your official example (https://primevue.org/datatable/#rowgroup_subheader), but added :virtualScrollerOptions="{ itemSize: 46 }" to the DataTable. After that rowGroup is messed up when we scroll.

Reproducer

https://stackblitz.com/edit/43cdnh?file=src%2Fservice%2FCustomerService.js,src%2FApp.vue

PrimeVue version

3.29.2

Vue version

3.x

Language

TypeScript

Build / Runtime

Vite

Browser(s)

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

[NaturesRadar]

I ran into the same problem.

    <DataTable :value="importedPlots" scrollable scrollHeight="calc(100vh - 180px)" v-model:selection="selectedRow"
        selectionMode="single" showGridlines @rowSelect="onRowSelect" resizableColumns columnResizeMode="expand"
        class="mt-3 p-datatable-sm" dataKey="featureId" rowGroupMode="subheader" groupRowsBy="filename"
        sortMode="single" sortField="filename" :sortOrder="1" :virtualScrollerOptions="{ itemSize: 50 }">

The rows are messed up and have a big gap, also row group is missing when scrolling after 50 items. It looks like the row group header is trying to set itself inside after every row.

I believe this is more than an enhancement it is a big problem for the performance of the browser with big datasets.

PrimeVue Version 3.52.0

[0xkalle]

Same problem here with 4.2.4. Did someone find a solution for it?

[SevenLab-nl]

Any plans to fix this? Or did anyone find a workaround?
It has been 1 and a half years since this issue was opened...

[saenzramiro]

Same here using version 4.3.6.

[d11-hqcasanova]

Same situation here. We have patiently waited for the project to fix this issue and I completely understand it is by no means trivial to solve... I have tried to do it myself by monkey-patching the shouldRenderRowGroupHeader and its counterpart for the group footer and, while it partially works, it is a very nasty hack that I would rather avoid... And it is getting close to a point that it is not tenable anymore, having to do all sorts of theoretically unnecessary optimisations on the side to make up for the higher number of DOM elements that would not be there in the first place if virtual scrolling was reliable (for various reasons, our tables can be fairly big and complex and we cannot do pagination).

In the meantime, I have to fend off legit questions in the team on whether PrimeVue was a wise choice 2 years ago, at least as far as tables are concerned. I still believe it was a wise choice due to the wealth of features and, especially, the flexibility provided by the pass-thru, which is quite unique in the Vue ecosystem as far as I know. So, if you could be a tad more diligent with this long-standing issue (@tugcekucukoglu just providing more frequent feedback about its progress and expected timelines would be a significant improvement) then you will make the job much easier for those of us who can see the library's huge potential.

[VirtualZer0]

@d11-hqcasanova do you have a publicly available solution or can you share one? I also encountered this problem on a commercial project, and so far, the simplest solution I've seen is disable virtual scrolling when grouping. Unfortunately, virtual scrolling currently causes a lot of problems, and because of this, our team is also having doubts about choosing PrimeVue, at least for tables.

[oliversluke]

Adding a precise diagnosis after digging into the source on v4.5.5 — the bug has two distinct drift sources, and I think only one is commonly understood.

Two-part spacer drift

Source 1 — collapsed body rows occupy items[] slots but don't render. VirtualScroller computes total height at virtualscroller/index.mjs:556 as items.length × itemSize, but DataTable's body render gates each row through isRowGroupExpanded (around datatable/index.mjs:1803) when expandableRowGroups is set. Collapsed-cluster rows still count in items.length but contribute 0 px to the rendered DOM. Result: spacer over-estimates used space → flex container stretches surviving rows to ~145 px.

Source 2 — rowGroupMode="subheader" injects <tr class="p-datatable-row-group-header"> rows that aren't in items[]. The spacer subtraction at datatable/index.mjs:6599 is slotProps.spacerStyle.height - slotProps.rows.length × slotProps.itemSize. Group headers render on top of the windowed items but the formula doesn't account for them.

Empirically on 4.5.5, the auto-injected subheader row's computed height is 39.75 px with itemSize: 36 — so even with all groups expanded (Source 1 inert), every group boundary in the rendered window adds ~3.75 px of unaccounted drift. With 40 visible cluster boundaries on a long-scrolling page, that's ~150 px of accumulated drift — enough to produce visible gaps between rendered rows and, on fast scroll, full-window blanks.

Why the "disable VirtualScroller when grouping is active" workaround is correct

A consumer-side reshape — only including content rows for currently-expanded clusters in the items array — fixes Source 1 cleanly. I verified this on 4.5.5: it eliminates the collapsed-row component of the drift entirely.

But Source 2 is unfixable downstream: the subheader rows are auto-injected by DataTable, never enter items[], and PrimeVue's spacer formula has no hook to account for them. The drift returns the moment the window spans more than one cluster boundary.

Minimal repro on 4.5.5

<script setup>
import { ref } from 'vue'
import DataTable from 'primevue/datatable'
import Column from 'primevue/column'

// 500 rows across 5 representatives. Tall enough to scroll;
// few enough groups that drift is visible per boundary.
const rows = ref(
  Array.from({ length: 500 }, (_, i) => ({
    id: i,
    name: `Item ${i}`,
    rep: ['Amy', 'John', 'Maria', 'Anna', 'Bernardo'][i % 5],
  })),
)
const expandedRowGroups = ref(['Amy', 'John', 'Maria', 'Anna', 'Bernardo'])
</script>

<template>
  <DataTable
    :value="rows"
    row-group-mode="subheader"
    group-rows-by="rep"
    expandable-row-groups
    v-model:expandedRowGroups="expandedRowGroups"
    scrollable
    scroll-height="400px"
    :virtual-scroller-options="{ itemSize: 36 }"
  >
    <template #groupheader="slotProps">
      <strong>{{ slotProps.data.rep }}</strong>
    </template>
    <Column field="id" header="ID" />
    <Column field="name" header="Name" />
  </DataTable>
</template>

Scroll up and down inside the table. You'll see rows stretched to ~145 px in places where the rendered window has accumulated header-overhead drift, and full-window blanks on faster scroll. Setting itemSize: 40 shifts but doesn't eliminate the drift (data rows then drift the other direction).

Update — PR #8579

PR open: #8579

The approach: add an optional getItemSize(index: number): number callback prop to VirtualScroller so it can be made variable-row-height aware. DataTable supplies a getItemSize that returns itemSize plus an auto-measured group-header height at cluster boundaries, and 0 for hidden rows inside collapsed clusters. That corrects both Source 1 (collapsed contributions = 0 in the cumulative total) and Source 2 (boundary rows contribute their full header height). The default getItemSize: null keeps the existing uniform-height code path byte-for-byte unchanged for all current VS consumers.

Two pre-existing related bugs surfaced once the spacer math was correct and are addressed in the same PR — group-boundary detection in BodyRow (mixing windowed value with absolute row index in VS mode) and position: sticky group-header stacking when many small groups share one sticky threshold. Details in the PR description.

A future enhancement not in scope: a single floating "currently-active group" header overlay would restore sticky-header UX in VS mode without the multi-element stacking pitfall.