Devextreme-reactive: Banded columns and virtual table bug

Created on 7 Sep 2018  路  15Comments  路  Source: DevExpress/devextreme-reactive


I use VirtualTable and BandedColumns together, column header cells behave strangely when horizontal scrolling. I think colspan is calculated incorrectly for banded columns. When the first column from group is removed from DOM, its banded header cell it is also removed

  • [x] I have searched this repository's issues and believe that this is not a duplicate.

I'm using ...

  • [x] React Grid
  • [ ] React Chart
  • [ ] Vue Grid
Grid bug

Most helpful comment

We have thoroughly researched the issue and decided to fix it in the next major release because our preliminary solution requires a breaking change.
Let me explain the issue in greater detail: when both virtual table and banded columns are enabled, the virtual table layout depends on the table header rows that the TableBandHeader plugin provides. On the other hand, in order to correctly calculate colspan for columns, the TableBandHeader plugin needs to know the visible table boundaries that the Virtual Table provides.
To resolve this circular dependency we are going to extract a virtualization logic to a standalone plugin named "VirtualScrolling" that will be used in conjunction with the Table plugin:

before:

<Grid>
  <VirtualTable />
  ...
  <TableBandHeader />
  ...
</Grid>


after:

<Grid>
  <Table />
  ...
  <TableBandHeader />
  ...
  <VirtualScrolling />
</Grid> 

All 15 comments

We require more time to research this issue. Currently, we can't promise that we will fix the issue quickly. Anyway, we will update this thread as soon as we have any news.

We have thoroughly researched the issue and decided to fix it in the next major release because our preliminary solution requires a breaking change.
Let me explain the issue in greater detail: when both virtual table and banded columns are enabled, the virtual table layout depends on the table header rows that the TableBandHeader plugin provides. On the other hand, in order to correctly calculate colspan for columns, the TableBandHeader plugin needs to know the visible table boundaries that the Virtual Table provides.
To resolve this circular dependency we are going to extract a virtualization logic to a standalone plugin named "VirtualScrolling" that will be used in conjunction with the Table plugin:

before:

<Grid>
  <VirtualTable />
  ...
  <TableBandHeader />
  ...
</Grid>


after:

<Grid>
  <Table />
  ...
  <TableBandHeader />
  ...
  <VirtualScrolling />
</Grid> 

I have run into this issue as well. Will this fix be included in version 1.11 (currently alpha1)?

@ushkal Any update on this fix?

Hi @vamsi0212,

We're still working on this issue. We'll update the thread once we the problem is fixed.

Do you have workarounds to suggest in the meantime?

This is the workaround I created, when I hit this issue:
https://codesandbox.io/s/virtualtable-banded-columns-workaround-ckzjv

It's a custom plugin that adds the band title as an absolutely positioned element on top of the header cell.
It's not perfect - it only supports a single level of bands, the borders are only partially supported, but it was good enough for our use case.

It works with the same format of columnBands property and also works fine when combined with TableColumnVisibility plugin.

Any feedback welcome :)

It works but the TH style is too generic.
With two grids, one with a column band and other without a column band, If I change the style of the TH, I create a little style problem on the second grid.

Absolutely - the TH style is there only to keep the example shorter. In reality it would be better to either override the header row component to introduce some styling or to add some scoping class for the whole table and use that to only style the relevant cells.

Hello. Any updates on this fix?

Hi @IndigoHollow ,

We are currently working on a solution that would not require a breaking change. We'll update this thread once this issue is fixed.

Inside of issue #2139 is written that it awaits when this issue will be fixed. Issue #2139 was closed recently. Could you please kindly give an update on this current issue?

Hi @IndigoHollow ,

We've found another way to fix issue #2139 . The fix for the current issue is almost ready. We expect to merge it next week.

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests.

Was this page helpful?
0 / 5 - 0 ratings