Fixed Calendar next/back arrows disabled when date is out of bounds #6156
Conversation
|
just some comments and behavior i noticed when testing: the bounds is 07/02/2020 to 07/31/2020: when i input 01/01/2020, the next arrow is not disabled as expected. however, i was a bit confused when i hit the arrow and it immediately jumped to 07/01/2020. in my mind, the next arrow would take me to 02/01/2020 where all of the dates would still be disabled and the next arrow button would still not be disabled, allowing me to move to the next date until i am in bounds. with the voiceover buttons currently, it announces when a user focuses on the next button "move to february 2020" which aligns with the above expectations. we would need to update this in some way to allow users with assistive technology to understand the sudden jump. i think that jumping to the dates in bounds can be a little jarring but is an understandable approach. @jcfilben thoughts? |
I agree, the behavior is confusing. In all other cases the left and right arrows on the calendar are moving by 1 month so having the same button move us by multiple months is a bit jarring. However, I can see the reasoning for doing this. If a user selects a date that is way outside of the bounds then getting back could take a lot of clicks. However, in this case I think the user would likely just re-enter a new date into the date input if they are found outside the bounds. For now I am leaning towards having the left and right button continue to advance or move back by 1 month if the date is out of bounds, but I am open to discussion on this if anyone else has thoughts. |
|
Hey @joaoGabriel55 I just chatted about this with another member of the team and we are in agreement that the left and right arrows should advance or move back by 1 month instead of jumping backwards or forwards to a date that is within bounds. This will keep the arrow button behavior consistent so that we don't confuse users. Let us know if this sounds okay or if there are any objections. |
I think that makes sense. I can provide some solution tomorow @jcfilben. |
798030a to
c08641f
Compare
| disabled={disabledCalendarPreviousMonthButton( | ||
| previousMonth, | ||
| reference, | ||
| bounds, | ||
| )} |
There was a problem hiding this comment.
| disabled={disabledCalendarPreviousMonthButton( | |
| previousMonth, | |
| reference, | |
| bounds, | |
| )} | |
| disabled={!betweenDates(previousMonth, bounds) && | |
| (reference && bounds[1] | |
| ? !sameDayOrAfter(reference, new Date(bounds[1])) | |
| : true) | |
| } |
Could we remove disabledCalendarPreviousMonthButton and simplify to something like this?
There was a problem hiding this comment.
Hi @jcfilben. I am using the methods disabledCalendarPreviousMonthButton and disabledCalendarNextMonthButton to keep disabled one of the change month buttons when the current month is a boundary. And keep not disabled their buttons when a month is out of bounds.
Examples:
Was I clear? I can try to explain it in another way.
There was a problem hiding this comment.
Yeah that makes sense, I think
disabled={!betweenDates(previousMonth, bounds) &&
(reference && bounds[1]
? !sameDayOrAfter(reference, new Date(bounds[1]))
: true)
}and
disabled={!betweenDates(nextMonth, bounds) &&
(reference && bounds[0]
? !sameDayOrBefore(reference, new Date(bounds[0]))
: true)
}are achieving the same behavior (but I could be missing something?)
There was a problem hiding this comment.
Yes. The differences between checkers are only the bounds item passed and the sameDayOrAfter/Before validation, used to make one of the month change buttons disabled when end-users are in the first month of the bounds or in the last month of the bounds.
|
Hey @joaoGabriel55! I just wanted to check in on this PR, and see if you're still interested in working on this or if you had any questions. I think it is super close to being done! |
…ndar-next-back-arrows-disabled-when-date-is-out-of-bounds
@jcfilben, I updated my current branch, I hope that pipeline does not fail. |
What does this PR do?
Fixed issue #6150 which consists of when the user types in a date that is outside of the bounds (instead of using the calendar) and then brings up the calendar, sometimes the calendar forward/backward arrows are disabled if the date is in a month that is outside the bounds.
Where should the reviewer start?
Just access the Storybook story section, the second example.
localhost:9001/?path=/story/input-dateinput-format-inline--format-inline
What testing has been done on this PR?
How should this be manually tested?
Do Jest tests follow these best practices?
screenis used for querying.userEventis used in place offireEvent.asFragment()is used for snapshot testing.Any background context you want to provide?
No
What are the relevant issues?
No
Screenshots
Do the grommet docs need to be updated?
No
Should this PR be mentioned in the release notes?
No
Is this change backwards compatible or is it a breaking change?
No