Drag-and-drop and custom IDs with virtualization

I have a runtime object containing more than 10,000 items. I am displaying them in a custom-made Gantt Calendar and using virtualization. When I tested the Gantt Calendar on a smaller sample, without virtualization enabled, drag-and-drop and container widths and heights worked well. Still, after enabling virtualization this does not work anymore.

Some of the containers have custom IDs that are used for querying them later using document.getElementById and then finding the width and height of that container. I have tried logging to the console and nothing shows up in the console.

When dragging a container, the container being dragged offsets to the right and down.

Do you have any tips on how to fix these problems?

container id:

kalender4Uker.timestamp + virtualizationMachineGroup.machine

Attempt at setting the width equal to the container with id “kalender4Uker.timestamp + virtualizationMachineGroup.machine”. (This does not log to the console with virtualization)

try {
    console.log("Width: ",document.getElementById(kalender4Uker.timestamp + virtualizationMachineGroup.machine).offsetWidth )
    return document.getElementById(kalender4Uker.timestamp + virtualizationMachineGroup.machine).offsetWidth
} catch (e) {
    return 45

Video of dragging being buggy: Video

1 Like

Hi Martin!

This sounds a bit too comprehensive to give a simple answer, sounds like the problem can be an lot of things. First off, are you using a coded component, with Gannt Calendar, virtualization and drag/drop? Or have you made this custom Gannt calendar using iterating Containers / combing “Appfarm building blocks and functionality”?

If it’s build with Appfarm UI Components (not coded component) - is it possible to get a screenshot of the view including the Tree-view, where you have marked the container repeating the rows, and the container with the “enabled virtualization”, and the container that is draggable?

I am building it using just Appfarm Building blocks and functionality.

I have multiple machines that I am iterating. For each machine, I iterate the days of the calendar (4 weeks). If the day is Sunday, the border width is set to 2px, for every other day of the week it is 1px. If there exists an order line for the machine on the day, I want to draw a container in the “Day”-container, the width of this needs to be the width of the “Day”-container plus its border in order to look continuous for the user.

I figured out how to calculate the width now, by calculating it using another container that is accessible.

There are still some issues when enabling virtualization though, dragging the container still offsets it. In the screenshot provided the “Day”-container has “Enable Drop Area”, whereas the “Activity (starts)” and “Activity (starts/ends)” have “Enabled Draggable”.
Screenshot 2023-06-30 at 09.04.00

Another thing that should be mentioned is, the offsets depend on whether the filter tab is expanded or not (see screenshots). It is larger when the filter tab is expanded. I have tested it, and it only occurs when virtualization is on.

Screenshot 2023-06-30 at 09.28.49 (2)

@kristian Do you have any thoughts on the drag-and-drop issue?


What I can say is that enabling virtualization comes with potential functional cost. It’s very strict. In you case, the virtualisation should be enabled on the Days repeating container, resulting on the Day container to have a required fixed height (equal to the item height of the virtualization). Having this set correctly, I believe you should be able to drag the Day container. And only one container may have virtualization vertically on one view I believe.

However, combining vertical virtualization with horizontal scroll or more complex drag / drop - I guess you may experience weird behaviour.

I would recommend a pagination approach or lazy loading of the vertical items (“infinity scroll”) as you scroll down - and avoid virtualization.

When it comes to the filter pane width, it might be because the virtualization setting overrides a flex setting or something. But in general, when you collapse a container, the collapsed container has no knowledge of the width of its “hidden and collapsed content”, so to me the behaviour it looks correct and occurs because the “Vis kun tilgjengelige produkter” checkboks (defining the expanded width) is hidden.

1 Like