Our blazing fast Grid component built with pure JavaScript


Post by mdl »

Hey all -

I know that end dates are not inclusive at all, I see past threads on the topic.

The product I'm working on requires an inclusive end date, however. I have a plan to achieve this myself, but its a huge workaround that touches so many things, so I wanted to instead ask to see if either there's a simple known solution or if I could make a feature request for it.

So I guess the feature request I'm asking for is a new flag, something like inclusiveEndDate, which is only considered if manuallyScheduled=true. If both are true, the end date renders inclusively (i.e., it renders one day further than it would otherwise).

Alternatively, anyone know of a clever/simple way to achieve this? Or will it require, as I assume, juggling dates, modifying tooltips, and such?


Post by Animal »

It's not really inclusive. That's a way of putting it to make it simple to understand.

It's that "Dates" are in fact timestamps of a single point in time.

So when you say startDate : '2010-01-01', endDate : '2010-01-02' that data means that the event has the following time span:

Fri Jan 01 2010 01:00:00 GMT+0100 (Central European Standard Time) to
Sat Jan 02 2010 01:00:00 GMT+0100 (Central European Standard Time)

Those two points are in fact exactly 24 hours (or, if you like, one day) apart.


Post by mdl »

Yes, I understand that. I was using relatively known language to describe the problem, which you clearly understand based on your response. I know that what I'm asking for is not technically an inclusive end date, but that is how it manifests itself in the UI. Feel free to call it something else.

The underlying problem with your example for me is that every tooltip will show the date to be 2010-01-02 and the data that gets pushed back via sync will be 2010-01-02, but on the actual chart, the grid area that represents 2010-01-02 is not filled in.

I'm asking for a feature flag that will allow 2010-01-02 to be filled in, while retaining the same underlying 2010-01-02 that is used in the tooltips and syncing.


Post by Animal »

If it's just the info flagged up on tooltips that is not intuitive for end users, the solution could be configuring a special renderer for the tooltips that you need to change.

I believe that all features which include a tooltip in their operation allow you to configure a renderer to provide custom content.


Post by mdl »

No, the problem is beyond that. This is the issue as I see it:

  • In the database the end date is 2010-01-02. This is the correct date, and the user expects this value and ALSO expects the gantt chart area to include this date (in a very similar way to your calendar solution)
  • For the gantt chart to render correctly per what I'm looking for, it needs the date to be set 2010-01-03, but it needs to be visible to the users as 2010-01-02. So I'll need to override the tooltips (edit: and modify the date either in the JS or in the API, unsure on where to best modify it still, because the API will send 2010-01-02 but it needs to be 2010-01-03 to produce the necessary results)
  • But when a user opens the edit screen, the date that is visible will be 2010-01-03, which is incorrect, and I do not think there is a solution for this.
  • Or when the user drags to resize, the date that is sent back to the API when syncing will be 2010-01-03 + drag distance. So I will also need to create a translation layer in my gantt sync API endpoint that automatically decrements the date being sent back before updating (edit: or do it somewhere in the JS if that option is available)

Or is there some other set of configurations that I'm not familiar with that would help tackle this problem?


Post by arcady »

Have you tried using an 8hrs/day calendar? I think it'll then show dates the way you expect.
You can try that on the advanced demo (even online the demo). Just execute this code in your browser console:

gantt.project.hoursPerDay = 8
gantt.project.calendar = 'business'

Post by mdl »

Interesting idea. I tried it in the demo and on my code, and in both situations using 8 hour day and business calendar shrinks the width of the visible tasks a bit instead of expanding them a bit. But I might experiment with this some to see if I can generate the result I need.


Post by arcady »

Yes Scheduler has fillTicks for that but the Gantt doesn't support it yet.
So far this can be solved w/ a custom renderer function I think. Its renderData argument provides task bar coordinates IIRC. So they can be overridden there.


Post by mdl »

This lead me to a solution that I'm still working on but seems promising. The coordinates that are provided are the css left and width properties. I can modify the width to make the bar as it is rendered on the grid fill up more space.

Problem is when I'm resizing or drag-and-dropping, this extra width causes problems. I might be able to come up with a solution, but I'm still doing much more customization and overwriting than I was hoping for out of this.


Post by arcady »

I'm afraid so far this is the easiest option I see. Or you can wait till we finish with this feature request: https://github.com/bryntum/support/issues/2475

Making of such function looks not that complex to me. These three properties/methods should do all the job:
https://bryntum.com/docs/gantt/#Gantt/view/Gantt#config-timeAxis - to get the time axis w/ ticks
https://bryntum.com/docs/gantt/#Scheduler/data/TimeAxis#function-getTickFromDate - to get a tick for a date
https://bryntum.com/docs/gantt/#Gantt/view/Gantt#function-getCoordinateFromDate - to get coordinate of the date

ps You can also hire us for implementing this for you if you want ..if that's an option for you please contact sales at bryntum.com.


Post Reply