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

Feature Request: InputDate/InputDateRange enhancements #653

Open
brian-c-ogorman opened this issue May 17, 2024 · 7 comments
Open

Feature Request: InputDate/InputDateRange enhancements #653

brian-c-ogorman opened this issue May 17, 2024 · 7 comments

Comments

@brian-c-ogorman
Copy link
Contributor

Overview

I'd like to propose some enhancements to the InputDate and InputDateRange controls.

Support for a monthly date resolution

With many reporting applications, it is common to be interested in monthly data. The InputDate and InputDateRange 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. The solara.v.DatePicker accepts a type parameter that supports a monthly granularity (by specifying type='month'), so this parameter would map directly to that one.

Support for controlling the min/max allowed dates

By default, the InputDate and InputDateRange 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 and max_date parameters to allow the developer to place limits on the allowed dates. The solara.v.DatePicker accepts min and max 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 the InputDateRange:

  • None (the default) would preserve the current behavior (i.e., not sorted)
  • True would sort ascending
  • False would sort descending
@mikegiann01
Copy link
Contributor

hello!!can i work on this?

@brian-c-ogorman
Copy link
Contributor Author

I was planning to make this update myself 😄 (after getting the go-ahead from the core developers).

@iisakkirotko
Copy link
Collaborator

Hey @brian-c-ogorman!

We really like your ideas for for improvements! A couple of comments to think about:

Support for monthly date resolution

Is 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 (InputDateRange only)

Do you have a particular use case in mind for descending sorting? Would it maybe make more sense to have a parameter sort that would default to False, and sort ascending when set to True? Converting from sort=True to descending should be a simple enough for the user to implement, and it makes the API a bit more friendly to work with (in my opinion).

@brian-c-ogorman
Copy link
Contributor Author

brian-c-ogorman commented May 21, 2024

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 'date' and 'month' (for "daily" and "monthly" granularity). (I think that API documentation is for the Vuetify 2 API.)

As for Vuetify 3, I couldn't find exactly the same page, but I see there is a VDateInput that has the same type property (with the same limitation). The VDatePicker does not have a type parameter. I see that it has a view-mode parameter, but I'm not sure exactly what it is for. The description says:

Determines which picker in the date or month picker is being displayed. Allowed values: 'month', 'months', 'year'.

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 InputDateRange, I don't have a use case in mind for descending order. I figured allowing both sort orders was more flexible, but you make a good point that just using sort=False/True would work and would be simpler.

@brian-c-ogorman
Copy link
Contributor Author

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.

@maartenbreddels
Copy link
Contributor

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.

@brian-c-ogorman
Copy link
Contributor Author

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 InputDate and InputDateRange components (which are already in solara.lab) to add a few optional parameters and handle some date parsing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants