Date Range calendar

[roberbnd]

Describe the bug

I cant find a solution for show the calendar always inside of the view if the column is in the edge, its happening this:

Reproduction

1. No click date range filter
2. Move a column with dateRage filter to be the last column
3. click in the filter (dateRange)

---

No do this when its no the last column and you click filter you are going to see:

and move the column to be de last is not happening the issue

Expectation

the calendar must be totally visible

Environment Info

any browser
you can replicate it here
https://ghiscoding.github.io/slickgrid-react/#/example23

Validations

• [X] Follow our Code of Conduct
• [X] Read the HOWTO - Step by Step.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[ghiscoding]

That's not at all a problem with Slickgrid-React but rather a problem with the external libray Vanilla-Calendar-Pro, I was actually the person who added the auto-positioning in this Vanilla-Calendar-Pro Pull Request but I don't remember if the space calculation is just for the viewport regardless of the scroll or if it calculates with the scroll position. I assume it was probably calculating without the scroll position. I guess the question would be, in your first print screen, does it have enough space to show it on the left of the input?

Also note that I'm currently using a custom fork of Vanilla-Calendar-Pro that I created and named Vanilla-Calendar-Picker. I'm trying to push all my changes to Vanilla-Calendar-Pro, so that I can switch back to that library and eventually delete my custom fork,.. so at this point any fixes would probably have to be in Vanilla-Calendar-Picker (and also copied to Vanilla-Calendar-Pro) but not in Slickgrid-React itself (it would however require a dependency update once a fix is found)

For now you can maybe try to set a fixed position (see Vanilla-Calendar-Pro positionToInput docs)

filter: {
  model: Filters.compoundDate,
  filterOptions: {
    visibility: {
      positionToInput: ['bottom', 'left'], // or "right", I'm not sure which side it is
    },
  } as VanillaCalendarOption
}

Please answer the question I asked in first paragraph though

[roberbnd]

does it have enough space to show it on the left of the input? No I haven't it, I was expecting to see the calendar but I have to scroll

I tried that configuration and I noticed this is happening

then when you want to see the calendar for value ['bottom', 'left'] you going to see

and I was expecting

My first approach was add negative margin to move the calendar

.vanilla-calendar {
  margin-left: -20px
} 

but in the end I created the same issue in the right of the screen

[roberbnd]

I was reviewing your code and I think that I got it, the issue is happening for the scroll Example here as you can see I have 2 scrolls 1.-the common scroll 2.-the slickgrid scroll

the calculation only has in consideration the first scroll its missing the scroll of the slickgrid

[ghiscoding]

then when you want to see the calendar for value ['bottom', 'left'] you going to see

just try the inverse then, like I said I'm not sure which side it needs, just try ['bottom', 'right'] instead, those position names were added by the original author of the Vanilla-Calendar project, he has code or CSS in place to do these bottom/top/right/left options, all I did was to add an auto option which tries to see what is best to use, bottom, top, bottom-left, bottom-right, ...

"relative to the viewport".... I wrote that comment, but I'm still not sure if it includes the scroll position or not. When I wrote that comment, I meant the document.body viewport

[roberbnd]

for ['bottom', 'right'] I got this:

[ghiscoding]

well it's bottom-left then, but it doesn't seem to be correct. However I didn't work on that part, the original author of the lib did that, not me and the auto position won't help either because it just tries to find it should use bottom-left, bottom-right, top-left, top-right, ... that is what I did in the auto feature that I opened on his project. So it looks like bottom-left is broken and I don't know or how it works so, can't help

[roberbnd]

anyway thanks! now I understand what is happening.

[ghiscoding]

the author used Tailwind in his project and I never used Tailwind before, but if you look at the CSS theme, it's probably these lines that makes the calendar stretch that way

https://github.com/uvarov-frontend/vanilla-calendar-pro/blob/7c61e39b754a80c8852348947cffc53ab7fa5a18/package/src/styles/vanilla-calendar.layout.css#L11-L27

I assume it's probably using Flexbox and it is what makes the calendar show like your first print screen, you are right it's a bit weird how it shows but it's really not my code so... I will close this issue since there is nothing to do here, the problem would have to be fixed in the external library, not Slickgrid-React, so closing.

[ghiscoding]

Ok so after investigating a bit, I found the problem is because the Calendar Picker is appended to the document.body and then it calculates the position of the picker by reading the input x,y coordinates, but the problem is that the input position is no longer in the visible viewport but we use these x,y coordinates to change the position of the calendar picker, but this picker is appended to the body not to the grid div. So because the picker is on the body, it tries to use a x,y that is too much to the right, however it doesn't allow it because the body doesn't have any scroll, so it can't go further because it's on the body without any scroll, which is why it doesn't follow the input (because the input is with the grid div, and the picker is on the body, so they are in completely 2 different layers of the DOM, 1 layer has scroll (the grid) but the other layer doesn't have any scroll (the body)).

Also the reason why the calendar picker becomes very tall with both months showing as top and bottom is because it uses Flexbox and because it's appended to the body and it cannot go wider than the body viewport. Flexbox are great when it has enough space, but when it does then it tries to stretch to find enough space to show its content, so it's not always good to use Flexbox

So this issue should be opened on the external project Vanilla-Calendar-Pro, not here, which is why I closed the issue.

[ghiscoding]

@roberbnd ok so I managed to fix the issue in my fork that I just mentioned above in previous comment, you can see this PR to fix that problem. It might not fix all your problems but it will help a lot for sure and it will no longer show the picker with a weird UI with a month on the top and another at the bottom. I will also create a PR to the original library Vanilla-Calendar-Pro soon

you can see with the animated gif below that it helps a lot, it keeps the correct size of the picker because I now detect if the picker new coordinate is outside the document body viewport, I added a condition check for that and if it's outside then I reposition the picker to be just beside the body viewport (it no longer follows the input position when it cannot)

Very Important... to get this fix, you will need to update the Vanilla-Calendar-Picker (that is my project fork of that library), I just released a new version with this fix https://www.npmjs.com/package/vanilla-calendar-picker?activeTab=versions

To update the dependency, you will probably need to delete your lock file (npm, yarn or pnpm lock file) and then run npm install (or other) and it should pick up the latest version. I will wait a few more days or week before pushing a version of Slickgrid-Universal, so deleting your lock file is the easiest way to get this fix.

[ghiscoding]

pushed a new release for another bug fix, so it's now also including the Vanilla Calendar fixes v5.5.1, cheers ⭐