inter-track dragging

[ebrensi]

Hi @shybovycha I have been checking out gantt-chart components and I came across yours. It looks fairly simple, light and fast, which is what I'm looking for. I will need to make a few modifications though, and I'd like your suggestions if you have time. If I end up doing this I'll submit a PR.

It needs to be fast because I will be working with thousands of tasks that can get moved around between workers with a few rules (and we have some code on the backend that optimizes a schedule). It's actually two linked gantt charts, where each task in second chart cannot happen until a corresponding task on the first one is done. All this stuff needs to work close to instantaneously.

Anyway, thanks!

Basically I need to improve the zooming functionality, and add inter-track dragging. That means, dragging a task block from one "thread" to another. I am currently at a loss as to how I'd go about doing it. I could figure it out with enough time but any suggestion would be helpful since you know the codebase.

[shybovycha]

Hi, @ebrensi

Sorry, did not have time to look into your issue in depth today, but here are few points you can look into, when implementing moving the bars vertically:

• you would want to reorder the underlying data blocks - bars are essentially rendered in the same order as the objects in the initial data passed to the constructor
• check out the onMouseMove method - it has three sections you might be interested in: setting the selected bar, moving the bar horizontally, re-rendering the chart
• you might want to implement bar "sticking" to each row, so instead of just simply copying the behavior for horizontal movement (literally this.selectedBar.y += deltaY), you would want to calculate the vertical row offset similarly to how it is done for each bar in the initializeBars method and then simply set the this.selectedBar.y instead of adding / subtracting deltaY from it
• for the "sticking" behavior, you would want something like if (mouseY >= prevRowY && mouseY <= prevRowY + (DEFAULT_ROW_HEIGHT + DEFAULT_ROW_PADDING * 2)) this.selectedBar.y = prevRowY; where prevRowY is the y coordinate of the row above current bar; might need to calculate it relative to this.seletedBar.y
• alternatively, you could use division to make this.selectedBar.y fit into the multiplies of (DEFAULT_ROW_HEIGHT + DEFAULT_ROW_PADDING * 2)
• be aware of the edge cases (that is, when y < 0 || y > canvasHeight)
• the connecting arrows should be updated once the chart is re-rendered

I am not sure what your case is for zoom, but I guess I can answer your questions if you have any.

Hope this helps!

[ebrensi]

haha I'm back here again! I ended up implementing mine as horizontal drag-and-drop html LI elements, using Sortable.js. It is pretty fast like I wanted, but not ideal. One big problem is that since each row is just a list, empty spaces must be blank blocks. Whenever a user moves blocks around, I have to re-compute the sizes of the invisible blocks. I thought once again to try doing it with Canvas and found your component again. It looks like it has changed a bit since then. CSS grid now? I will look into that.

[shybovycha]

Hey @ebrensi ! Yes, I have merged whatever I had in my working drafts into master yesterday. The idea being the CSS Grid allows for both custom content in lane titles and supports arbitrary width of a lane without too much hassle / computation. So a much more flexible solution overall.

I am curious in what is the use case you are trying to implement? Since in my mind a Gantt chart is supposed to represent a single scope of tasks on a timeline. Considering that, maybe it would be a better idea to combine the two charts into one? Stacking them on top of each other. Then managing the drag and drop should become easier.

[ebrensi]

@shybovycha it is for visualization of drilling/fracking schedule for use in the oil & gas industry. There is a drilling schedule and a fracking schedule. One of several drilling rigs drills some wells, and then one of several completion crews fracs them. The drilling must be done before fracking. There are some spatial constraints as well. Fracking floods a region with water and affects production of any nearby wells so the operator needs to be made aware of any scheduling conflicts in that regard.

But this sort of scheduling logic applies to any operation (I guess manufacturing as well) where you have a product that takes time for one worker to complete before moving on to another worker for its next phase.