Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: DatePicker - setting range logic & unable to set the same date as range #2763

Closed
2 tasks done
driskull opened this issue Aug 9, 2021 · 2 comments
Closed
2 tasks done
Assignees
Labels
4 - verified Issues that have been released and confirmed resolved. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. help wanted Issues that the core team needs help with in a sprint.

Comments

@driskull
Copy link
Member

driskull commented Aug 9, 2021

Actual Behavior

It's tough just to get the range correct. Especially since when you hover a range and click, it doesn't set to what it is telling you.

For example:

test

I would expect the range to be what the blue hover is set to but it does the opposite.

I think we should fix:

  • Setting same range date
  • Get hover and setting date range in sync (as seen in gif)

Expected Behavior

  • What you see when you hover a range is what you get when you click down
  • You are able to set the same day as a start and end date

Reproduction Steps or Sample

  1. View https://esri.github.io/calcite-components/?path=/story/components-controls-datepicker--range
  2. Hover over the 14th of december
  3. Notice that it should set the range to the 14-16.
  4. Click on the 14th of december
  5. The range is set to the 12-14.
  6. Try to set the range from the 12th to the 12th.

Relevant Info

#2756 (comment)

Version: @esri/calcite-components@<version>

  • CDN
  • NPM package
@driskull driskull added bug Bug reports for broken functionality. Issues should include a reproduction of the bug. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Aug 9, 2021
@bstifle
Copy link

bstifle commented Aug 9, 2021

  1. This behavior is nice when the datepicker is on its own (outside of an input), or if the range is selected in a single input

  2. The ux needs to be corrected when clicking on explicit start/end date range inputs. start should only select a start date. end should only select an end date

I dont want this changed unless we are talking about point 2

@jcfranco jcfranco added this to the Sprint 8/16 – 8/27 milestone Aug 11, 2021
@jcfranco jcfranco removed the needs triage Planning workflow - pending design/dev review. label Aug 11, 2021
@jcfranco jcfranco added the help wanted Issues that the core team needs help with in a sprint. label Aug 19, 2021
@driskull driskull self-assigned this Aug 26, 2021
@driskull driskull added 1 - assigned Issues that are assigned to a sprint and a team member. and removed 0 - new New issues that need assignment. labels Aug 26, 2021
@driskull driskull added 3 - installed Issues that have been merged to master branch and are ready for final confirmation. and removed 1 - assigned Issues that are assigned to a sprint and a team member. labels Aug 26, 2021
@driskull driskull assigned julio8a and unassigned driskull Aug 26, 2021
@julio8a julio8a added 4 - verified Issues that have been released and confirmed resolved. and removed 3 - installed Issues that have been merged to master branch and are ready for final confirmation. labels Aug 27, 2021
@julio8a
Copy link

julio8a commented Aug 27, 2021

verified on local build

@julio8a julio8a closed this as completed Aug 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - verified Issues that have been released and confirmed resolved. bug Bug reports for broken functionality. Issues should include a reproduction of the bug. help wanted Issues that the core team needs help with in a sprint.
Projects
None yet
Development

No branches or pull requests

4 participants