API change (V2 roadmap)

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

const [date, setDate] = useState(undefined)

<Datepicker value={date}
            onChange={setDate}  />

Range Date Selection

const [dateRange, setDateRange] = useState({ from: undefined, to: undefined })

<Datepicker value={dateRange}
            onChange={setDateRange} />

Multiple Dates Selection

const [dates, setDates] = useState([])

<Datepicker value={dates}
            onChange={setDates}  />

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 selection
• Array: multiple-dates selection

Changes that should be considered in moving from the current API to the suggested API is as follow:

• replace selectedDay and selectedDayRange with value property (Also there is no need for selectedDays property for multiple-days selection).
• remove isDayRange property (Also there is no need for isMultiSelectable 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 for minimumDate and maximumDate which are min and max 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.

[Kiarash-Z]

🎉 the package has been renamed and republished!

[Kiarash-Z]

We will support gregorian date in v2 as well!🎉(actually, it will be version 1! the package will be renamed)