Our pure JavaScript Scheduler component


Post by bjmac »

This is a followup to my earlier report viewtopic.php?f=44&t=10816

Now that the fix for that issue is released, I'm no longer experiencing the center date issue. However, I'm running into a separate issue.

My use case
I have the scheduler configured with a axis of 2019-Apr-01 to 2019-Jul-01. I'm setting zoom levels of 1 day, 3 day, 7 day, 30 day.

I have zoom levels with arbitrary dates that match those ranges:
{
  1: {
    startDate: new Date("2019-04-01T00:00:00-0400"),
    endDate: new Date("2019-04-02T00:00:00-0400")
  },
  3: {
    startDate: new Date("2019-04-01T00:00:00-0400"),
    endDate: new Date("2019-04-04T00:00:00-0400")
  },
  7: {
    startDate: new Date("2019-04-01T00:00:00-0400"),
    endDate: new Date("2019-04-09T00:00:00-0400")
  },
  30: {
    startDate: new Date("2019-04-01T00:00:00-0400"),
    endDate: new Date("2019-05-01T00:00:00-0400")
  }
}
I zoom using this approach:
const centerDate = this.scheduler.schedulerEngine.viewportCenterDate || new Date();

this.scheduler.schedulerEngine.zoomTo({ ...ZOOM_LEVEL_MAPPINGS[zoomLevel], centerDate });
What I expect
I expect selecting the zoom level to:
  1. Keep the view centered on the currently centered date
  2. Change the zoom level so that the specified number of days (1, 3, 7, 30) is visible in the view exactly.
  3. Maintain the start and end date of Apr 1 and Jul 1 for the overall view, so that the user can scroll left and right to those dates if they choose, after zooming.
What is actually happening
Expectations 1 and 2 from above are met. Expectation 3 is not met. The start and end dates (ie., limits of scrolling) change to unpredictable values.

It seems that after it zooms to the span, it calls 'calculateOptimalDateRange'. That function has an argument userProvidedSpan to prevent setting its own range, but this is not used in this codepath.

Questions
  1. Is this expected behaviour? That zooming to a span will result in unpredictable start and end dates being applied? Or is this a defect?
  2. If it's expected, any other thoughts on how I can achieve my desired behaviour?

Post by pmiklashevich »

Hello,

According to your requirements, viewPreset shouldn't get changed, and only tickWidth should be adjusted. Unfortunately we don't have such a config to fit N-days in visible viewport. But you can try to implement it yourself. Basically what you need is:
scheduler.tickWidth = scheduler.timeAxisViewModel.availableWidth / value; // where value is 1, 3, 7, 30 etc.
I've created a small prototype based on our configuration demo to show you the concept:
configuration(2).zip
(1.5 KiB) Downloaded 157 times
But also there could be another solution. Lets assume that you don't need to have scroll area for 30 days. You can add shift buttons to be able to easily navigate through the timeline. In this case you can create 4 custom viewPresets and define the values you need there. Please check out another proof of concept:
configuration.zip
(1.77 KiB) Downloaded 131 times
Therefore please check out 2 archives, unpack to examples/configuration and see what's done there. I hope it will help you to find the way out.

Best wishes,
Pavel

Pavlo Miklashevych
Sr. Frontend Developer


Post by bjmac »

Hi Pavel,

Thanks for the help. I think I prefer the first option as we prefer a continuous scroll rather than shifts.

Using your example, I was able to fit the correct time period in the window. I am however having an issue with getting center date to work. I thought this was related to the hack of adjusting the tick width at the same time as setting center date, but after simplifying my case by removing the tick width setting, center date is still not working for me.

As it's not directly related to this issue, I'm going to create a new forum post with some details on what I'm experiencing.

Post Reply