-
-
Notifications
You must be signed in to change notification settings - Fork 208
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
API change (V2 roadmap) #22
Comments
@thebrodmann I like this approach but for now, bumping the version to 2.x is not intellectual. Therefore, I'd like to wait for some other feature requests besides multiselection. |
We will support gregorian date in v2 as well!🎉(actually, it will be version 1! the package will be renamed) |
🎉 A new feature has been requested, and I will add a custom way for rendering a single day item for customization purposes. |
🎉 the package has been renamed and republished! |
Hello, this feature is not ready yet? |
@Aryan-mor Hey, Unfortunately, not yet. I will consider adding it soon(working on an efficient way for this) |
Currently, as component's functionality grows, API grows too (as in #21). So maybe it would be an API reconsideration symptom.
Maybe we can determine all 3 types of date pickers based on the input value and there is no need for the extra properties. So in this way, we can make API simpler.
Single Date Selection
Range Date Selection
Multiple Dates Selection
As the above API suggests we can differentiate between 3 types of date pickers by the type of
value
property that has been sent to the component.undefined
/null
: single-day selection{ from: undefined, to: undefined }
: range-day selectionArray
: multiple-dates selectionChanges that should be considered in moving from the current API to the suggested API is as follow:
selectedDay
andselectedDayRange
withvalue
property (Also there is no need forselectedDays
property for multiple-days selection).isDayRange
property (Also there is no need forisMultiSelectable
property for multiple-days selection).As the suggested API is similar to related HTML tags (e.g.
<input type="date">
and<select>
) maybe it would be better to use conventional interface forminimumDate
andmaximumDate
which aremin
andmax
respectively in HTML<input type="date">
tag.BTW, this is a huge breaking change for the API but I think the simpler API will worth it.
The text was updated successfully, but these errors were encountered: