add support for changing years

[terebentina]

It would be nice if we could switch the years somehow, without spamming the next/prev month links.
Either an extra pair of <</>> where the next/prev months are, or maybe a select box for years in the caption, or even a click on the caption to show an year sort of calendar (with just clickable years).
Something like:

| 2011 | 2012 | 2013 |
| 2014 | 2015 | 2016 |
| 2017 | 2018 | 2019 |

[gpbl]

Hi this is not the first time I get this request ... I'm not sure how we should implement it. The example of the year calendar is an idea. How often enough would a user want to change the year? Could you provide some use case? :)

[terebentina]

In my app I need it to pick the year a friend was born and to add historic events (this day in history kind of trivia).

I can also see something like a resume building app where you pick the month+year for when you started/ended some job. If we default to today and the job started 5 years ago and ended 3 years ago it's going to be a real pain to add the 2 dates.

The year calendar idea could have an extra step:
You click on the normal calendar caption (August 2015) and you get a month calendar first:

| < ____ 2015 ____  > |
| Jan  | Feb | Mar | Apr |
| May | Jun | Jul  | Aug |
| Sep | Oct | Nov | Dec |

and then, clicking on the 2015 caption, you get the year calendar:

| < ____________ > |
| 2011 | 2012 | 2013 |
| 2014 | 2015 | 2016 |
| 2017 | 2018 | 2019 |

[gpbl]

Hi @terebentina, I believe I've seen this UI pattern already in another date picker, however I don't like it in terms of usability 😌

In your case, for example, you may better provide three day/month/year selects and use perhaps the day-picker as an aid to select the day. A date picker is not the only nor the best way to input a date, and I'd like to avoid complex solutions that don't provide good usability. What do you think?

[terebentina]

Ughh, selects...and 3 of them? Yuck! :)
In general, I think picking a date should be ...umm...an atomic action. Or, in other words, when I decided on a date, all 3 components (day, month, year) should be set at once. This way, the value I have for the date is either null/undefined or a valid date.
With 3 separate selects there's the risk of picking, say, 31 February so I'd need validation and a way to display these errors. It would be smart of me to abstract this away into a <ThreeSelectDayPicker /> component so it only sends the full date to my app. But with selects I'd also need a 'Save' button. This already sounds like a date picker alright, only with a worse UX (imho).

How about this:
You already have the showMonth() and onCaptionClick() methods. How about adding showYear() which would render the months of the current year as in my example above? You don't have to link the clicking on caption to showYear, you can leave this to the developer. If clicking on the caption isn't desired for this, they could implement it in a different place, but they'd still have the option.
Similarly you could have a showDecade().

Not sure about your concerns regarding usability...I am a windows & android user and on both the calendar is pretty much using this pattern. Maybe I got used to it...

[TomGallon]

Hi

👍 We need it.

A common simple use case would be to select a birth date.

Regards,

[gpbl]

To be honest I believe this is not the component you are looking for: date pickers like these help to identify a day inside a month (e.g. by looking to its weekday), or to select a range, or to understand which days are "enabled" or not. How should the weekday help the user? "Yes, it must be this day because i was born on Sunday"? Selects or even text fields (maybe with type="date") work much better for such use cases.

In particular this one is called day-picker because it was born to select a day, not a month or even a year :-) Adding the ability to select month/year implies a lot of work: layout, styling, unit tests, keyboard navigation... if it's not worth it we have no reason to make this component more complex.

I'd like however to see some good implementations including this feature.

[gpbl]

(There is however a onCaptionClick prop that you can use to display a custom month/year selector, e.g. with a layer over the navigation bar)

[gnrlbzik]

@gpbl, i really like your date picker. But i will have to layer it up with year/month selection as well in my case. It seems like most date pickers require this functionality no matter if you agree with user experience or not.

[jkillian]

I understand where you're coming from @gpbl, but I agree that a faster way to change months/years would be good. I think the challenge here is making a good design. And I wonder if it's possible to fit in nicely with this component or not.

Just for the sake of discussion, you can try this link out in Chrome to see how they do date selection: http://jsfiddle.net/mhmq3mkz/.

[gpbl]

Very interesting @jkillian, browsing the internet I've never used a date picker like that. I believe the amount of work for doing something like that is not worth it.

Wouldn't be a better design to show two <select>s when clicking the month caption, e.g.:

[terebentina]

@gpbl your example is certainly acceptable for me.
I am not sure about < and > at the same time with the 2 selects though because then it would raise the need for << and >> and it looks crammed anyway.

[gpbl]

So maybe we have found a solution 🙌

But when should we make the selects disappear? I'm thinking to remove the < and > buttons, and add a ✕ button to go back to the previous view (I wouldn't put a button with a label Close because i18n).

[gpbl]

Example with close button:

[terebentina]

Not very related to this issue but since you brought close into discussion, there are 2 more buttons that I miss, besides close: today and clear. Clear being for clearing the input which holds the date. I suppose clear could call onDayClick with null instead of a day.
Today is self-explanatory.
I think close should be toggle-able (in case someone doesn't want to close the picker but have it always visible) and in this case so should be the other 2 should you chose to implement them. It's not complicated for us to create a wrapper around react-day-picker to provide these buttons but I feel they belong with your picker rather than being external.

Regarding i18n you could add closeLabel/todayLabel/clearLabel as props to react-day-picker with English defaults.

And showing/hiding selects could be done with props like selectMonths/selectYears, no?