React-calendar-timeline: How to set intial zoom

[MocanuMarius]

Hi,i want to lock the zooming in possibility and i managed to lock it for only "days" view by adjusting minZoom and maxZoom. Problem is i first need to play a little with the zoom until it decides to lock on that. Would it be possibly to initialize inital zoom with the minZoom property ? Thanks

[VincentN]

Being able to set an initial zoom level would be very useful! +1 for that feature.

I'd imagine it would be a plain configuration setting like 'initialZoom'.
If set to {minute: 15} for example, it would zoom to a point where the quarters of an hour are visible... Or does anyone else have a better proposal? :)

const options = {
     initialZoom: { minute: 15 }
}

<Timeline ...options />

[MocanuMarius]

@VincentN Yeah, but seemsilke this repo isn't maintaned anymore ... too bad. I managed to se intial zoom by computing visibleTimeStart/end date with moment. Apparently it does the zoom adjustment too. Also with this repo there are problems with CTRL+ zoom and ALT+zoom ...i swapped them because ctrl + zoom should soft zoom in and al+zoom should go to day zoom...i made a fork on my company's profile. I would submit some PR's but as i said i don't think the repo owner even looks there anymore.

[signalwerk]

@MocanuMarius hey! don't give up on us. I just got maintainer status like 2 weeks ago and I try to work through the issues and PRs. I'm not super fast since I try to do it better right than quick. So if you have any PR's for me I would be happy to merge them. Just give me a bit time. I first merge all the outstanding PRs for bugs then features.

But coming to this Issue:
like @MocanuMarius said: right now you have to do the initial zoom with visibleTimeStart and visibleTimeEnd. maybe @MocanuMarius could share his code and we place it somewhere other people can take advantage from it as well.

[MocanuMarius]

@signalwerk unfortunately i have 'finished my business' with this module, but i could contribute i guess in my free time. I will submit a PR request regarding the Ctrl+zoom and Alt+zoom behavior if you wish, some code changes are already there in my fork. We'll see about other things if you are active :) .Regarding initial zoom feature, i set it by blocking the size from somewhere else. It should be pretty easy to have a PR for initialZoom also :)

[MocanuMarius]

@signalwerk however i find the units in how the times and all (min-max) very counter-intuitive and not making a lot of sense, to get this package straight we would have to have a breaking version bump to fix all that logic.

[signalwerk]

@MocanuMarius We are more or less done with all the outstanding PRs. So I start to work on the bugs now. I made a code example where you see how to set the initially "zoom" by using visibleTimeStart& visibleTimeEnd (Line 59/60 in app.js on webpackbin) and how you fix it then to that with minZoom and maxZoom (Line 166/167).

The reason why we don't have a initialZoom level at the beginning is the reason to have full control over the view. Imagine your alternative. if you would do an initialZoom. Where would the view start and where would it end? So you would also need a visibleTimeStart anyway. Since visibleTimeEnd is in your terms visibleTimeStart + initialZoom it should be easy to handle that.

If you have other PRs for us I'm more than happy to review it.

[signalwerk]

Feel free to reopen the Issue if you have further questions or suggestions.

[MocanuMarius]

@signalwerk you want me to open a pull request on the cltr+ mousewheel / ctrl+alt issue ? I find that being a bug.. i don't know how you feel about it...ctrl + zoom is too much , and alt+ wheel also moves up and down .... , i forked on my company's org. and it worked fine for me..only like 5 lines of code changed tops.

[signalwerk]

@MocanuMarius If I read it right from the code and by testing; there are right now three handlers for the mouse wheel:

shift + mousewheel = move timeline left/right
alt + mousewheel = zoom in/out
ctrl + mousewheel = zoom in/out 10× faster

plus there is a handling for pinches (two touch points) to zoom in/out.

What was your suggestion to change?
In general we are open to improve the quality and the convenience. So if you have improvements for us you are more than welcome to participate.

[MocanuMarius]

@signalwerk yes my suggestion is to swap the zooming from alt and ctrl ,because most people intuitively use CTRL and not alt, and the zooming factor is waay to big and you might consider that is all you get. Also, last time i used the module, while using ALT+zoom in a scrollable window would move the whole window up and down too while zooming ( there was an event prevent default missing somewhere in code i remember ) .. is that fixed ? Because there was no way to get a normal zooming going on except ctrl which jumps too fast to years and so on while you might only want to consider weeks.

[mariusandra]

Hey, my 2 cents. On macOS, CTRL+zoom is by default mapped to the system zoom, which zooms in the entire desktop... so almost nobody can use it. That's why the standard zoom went to ALT+zoom.

[MocanuMarius]

@mariusandra oh , i forgot about that part of the world.. but still..what about the scrolling thing ? Usually this calendar is not the main and only thing in a page ... it's somewhere in a div or so.

[mariusandra]

Indeed, the whole window scrolling with ALT+zoom is a bug. Feel free to submit a PR to fix it ;).

[signalwerk]

@MocanuMarius @mariusandra
I think both of you are right. But probably we didn't find the right solution right now. What about that:

shift + mousewheel = move timeline left/right
alt + mousewheel = zoom in/out 10× faster (instead of 1×)
ctrl + mousewheel = zoom in/out 3× faster (instead of 10×)
⌘ + mousewheel = zoom in/out 3× faster (new – for the mac-users)

The basic Idea is that we do what @MocanuMarius told us plus we do for the mac users a new check on the ⌘. With this solution Mac+PC get both the two modes. Because the pinch gesture gets mapped by the browser to ctrl + mousewheel I suggest to make it faster than 1×. I randomly selected 3×.

[MocanuMarius]

@signalwerk sounds like a very good idea for me, but don't disregard the event.preventDefault missing on alt scroll that has to be added still.

[mariusandra]

Hey, I'm going to make things even more complicated 😁

I just tested and the reason why CTRL+scrollwheel is 10x as fast as the other zooms is because of chrome's "pinch to zoom = ctrl + wheel" logic. This is the speed at which the pinching feels natural on a Mac - the calendar zooms in about as much as your fingers pinch... like it would naturally on a tablet/phone. Setting this to 1x or 3x (instead of 10x) makes it too slow and unusable.

So for now I did not change this logic.

I did however release v0.14.9 via PR #120, which these changes:

• added event.preventDefault() for ALT+zoom - no more window scrolling
• added META+wheel (⊞+wheel or ⌘+wheel) that does the same as alt+wheel (1x zoom).
• refactored the code a bit

The problem with the zooming in general is that different users have different devices. Mac users are a minority for whom everything is more-or-less the same... but Linux and Windows users all use different mouse wheels, trackpads, touchpads, trackballs, etc... so it's hard to build something that satisfies everyone.

While @MocanuMarius complained that the default CTRL+zoom is really fast, in our experience, with a Linux desktop and a mouse with a "clicky" scroll (not a smooth one that just keeps turning), it was just perfect.

Perhaps the solution is to move away from the "speed" of the scroll itself, but base it around the duration of the scrolling? E.g. 500ms of scrolling = 1 screen, taking the maximum "scroll per 10ms" into account to make it smooth? Anyone willing to invest time into figuring this out? 😀

[mariusandra]

Actually, small change. v0.14.10 via PR #121 changes the new META+wheel to 3x the default zoom speed. I hope with this everyone will find some compromise that works. If not, we will need to investigate the time-based zoom approach, a'la Google Maps or Leaflet.

[MocanuMarius]

@mariusandra Nice job btw, regarding the other thing ... hmmm scrolling is not a continuous event, so i'm not sure how your suggestion would work. maybe making it work with throttling/debounce like how RxJs works, but the thing is you would want it to be very responsive anyways. I have had problems with how fast it scrolls on windows, but since it depends a lot on the configuration of the device as you say....would it be smart to allow for a scaling factor that the user can customize based on whatever their target audience is.. and move that responsibility of the package user ?

Hmm what if we use an exponential easing function that should be the same for all, im guessing that would adapt to all sort of devices if we get the parameter just right and enough steps from min-max.

I'm thinking making this zooming exponentially grow via a 'keep-stream-alive' debounce time ala RxJS of like 50 ms, might make this usable for any platform if done right., would work like this:

• on winows, first 2 scrolls does too much zoom, so i use one
• on linux, i need 4 scrolls to get it right
• Mac is different because it likes to be different, so 5 scrolls will be needed.

Problem is.. UX-wise it would need a lot of experimenting....dunno about this approach.

[mariusandra]

@MocanuMarius I'm not sure it's wise to delegate the responsibility of setting the correct zoom speed to the library users.

I believe as library developers we have the responsibility and overview to ensure sane defaults for the widest array of devices. If every library user needs to go through the same discussion as we did here to figure out the best modifier+speed combinations, it will just confuse everyone.

So let's still try to make something work! :)

As far as I understand, the main problem is that sometimes the zoom happens way too fast, especially with the CTRL modifier that is the natural zoom key on non-Mac systems. Thus it should be somehow limited to e.g. max 1000px of zoom per 500ms (just a random guess).

I would probably do it somehow like this:

• When a wheel event arrives, add the "scroll amount" (pixels) to a variable that says how much we want to have scrolled in 300ms. Let's call it scrollTarget
• Always keep this variable in some bounds, e.g. between -500 and +500 pixels. Everything over/under gets cut.
• Use window.requestAnimationFrame to ask for the next moment when we can update the screen.
• See how much time has passed and zoom accordingly (using some easing function for smoothness). Decrease scrollTarget as needed.

I once wrote something similar for my react map component pigeon-maps. Although in that component, the zoom speed is not limited, the smoothness/easing logic can possibly be emulated.

Feel free to take a crack at it if you wish ;).

[mcMickJuice]

Closing this issue as the "set initial zoom" can be achieved with the suggestion here.

The rest of the issue discusses how to alter the zoom gesture/action from a user which is out of scope. If an enhancement or fix is requested or worked on in the future, we can use this discussion as a reference

[pencilcheck]

The code and the link to the reference has expired, let me try my best to describe how I set initialZoom,

1. Set minZoom to the unit of time you want to zoom to
2. Set defaultTimeStart and defaultTimeEnd ONLY (no visible*) to the duration that is suitable to what you want to display given the minZoom
3. Viola