TreeDataGrid refills itself every time I click or expand some row

Hi there,
Could anyone explain to me why my TreeDataGrid regenerates every single column for the row I click or toggle its collapse button? As I understand, Jmix/Vaadin marks these rows as ‘dirty’ and tries to repaint them, even if the values are the same and only the style changes. Am I wrong?

This logic is encapsulated deep inside Vaadin. I found the first reference to “dirty rows” in this method: com.vaadin.server.communication.UidWriter#write. I tried to find any public API to access the DataCommunicators. The one that contains “dirty rows” is “HierarchicalDataCommunicator”. However, I failed to find a public API to access these communicators.

Is there any way to change this behavior? This greatly slows down my UI, especially when I use ComponentRenderer in one of my columns. The more rows I have, the more time it takes for each repaint, making the UI look terrible for the user.
Jmix version: 1.3.5.

In the related video you can see a small table, and it spends almost a second loading every time I expand a row. And if you look carefully, you’ll notice a brief loading period even after I just click on a row.

Hello Ignat!

I’ve tried to configure the TreeDataGrid like in your example (column generator and styleProvider) and the TreeDataGrid does not refill itself.

treedatagrid

I guess, in your case TreeDataGrid is manually marked as “dirty”. Could you check is repaint() method used? If not could you share the TreeDataGrid configuration (XML, code from controller)?

1 Like

Hello, Roman!
Maybe it’s working too quickly for you to notice the repaint? Have you tried setting debug points on the column generator events?

Anyway, here’s a simple example:

Entity
Controller
UI Descriptor

Even in this simple example, you can catch brief moments when the table is repainted. And if you set a debug point on a column generator handler, you’ll see that the method is called every time you click on a row.

Yes, this is default behavior of Vaadin Grid component. I meant that creating custom component in renderer is not time consuming task and should not affect the visual part.

The column generators are invoked several times and it is not recommended to place code for hard calculating or making database requests.

Thanks, Roman. Unfortunately, as I saw in real code, generating a several visual components per row can strongly affect the performance.
So we gotta figure out another way but using visual components in cells