-
Notifications
You must be signed in to change notification settings - Fork 147
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
Feature Request: InputDate/InputDateRange enhancements #653
Comments
hello!!can i work on this? |
I was planning to make this update myself 😄 (after getting the go-ahead from the core developers). |
Hey @brian-c-ogorman! We really like your ideas for for improvements! A couple of comments to think about: Support for monthly date resolutionIs it possible to also have a year picker? it seems like Vuetify 2 does not support this, but we couldn't quickly find out if Vuetify 3 does. We are planning to move to Vuetify 3 at some point, and were wondering if this would be possible there. Support for automatically sorting dates (
|
Hey @iisakkirotko ! For the question about a yearly date picker, I think this would be nice functionality to have. However, the type parameter looks like it only accepts the values As for Vuetify 3, I couldn't find exactly the same page, but I see there is a
Which still sounds like it is only a "date" or "month" picker. Edit: It looks like Vuetify 3 still only supports "date" and "month" types. (See the usage here.) For the question about sorting the output of |
Hi @iisakkirotko, Do you have any further thoughts/concerns about me submitting a PR for this change? I actually need the functionality for a monthly date-picker, so I have already developed this on the side and it is basically ready to go. |
I'm in favor for opening the PR, this should definitely first go to lab, but if there is a clear upgrade path for vuetify 3, I do not see an issue accepting a PR for this. It would be nice if you include/leave comments on what the possibly upgrade path for vuetify3 would look like, that would take some risk off the table for us. |
Thanks @maartenbreddels! I'll get the PR ready and submit it soon. The changes I have are pretty small -- I'll just be tweaking the existing |
Overview
I'd like to propose some enhancements to the
InputDate
andInputDateRange
controls.Support for a monthly date resolution
With many reporting applications, it is common to be interested in monthly data. The
InputDate
andInputDateRange
components can support this, but the end-user needs to pick the date at the daily granularity (e.g., by picking the first of the month). This could be confusing for monthly use cases, because it may not be clear if the end-user needs to pick the first of the month, or if they could pick any day in the month (e.g., where the application could truncate/ignore the day-component of the date).Proposed enhancement: add a
date_picker_type
parameter to let the developer specify whether the date picker should use daily granularity (the default) or monthly granularity. Thesolara.v.DatePicker
accepts atype
parameter that supports a monthly granularity (by specifyingtype='month'
), so this parameter would map directly to that one.Support for controlling the min/max allowed dates
By default, the
InputDate
andInputDateRange
place no bounds on the allowed dates that the end-user can select. It would be desirable for the developer to be able to limit this range -- perhaps to the range where there is data, or perhaps to limit the end-user from selecting dates too far in the future or past.Proposed enhancement: add
min_date
andmax_date
parameters to allow the developer to place limits on the allowed dates. Thesolara.v.DatePicker
acceptsmin
andmax
parameters that provide this level of control, so these new parameters would map directly to those.Support for automatically sorting dates (
InputDateRange
only)By default, the
InputDateRange
control does not order the dates that are picked. If the end-user selects a more recent date as the first date and an older date as the second, the dates will be ordered in that same way. I would hazard a guess that most of the time, end-users (and developers) would prefer the dates to be sorted from oldest to newest, regardless of which order they are selected, or at least that the order would be controlled, rather than based on the order they are clicked.Proposed enhancement: add an optional
ascending
parameter to allow the developer to automatically sort the dates chosen with theInputDateRange
:None
(the default) would preserve the current behavior (i.e., not sorted)True
would sort ascendingFalse
would sort descendingThe text was updated successfully, but these errors were encountered: