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

API change (V2 roadmap) #22

Closed
the-dr-lazy opened this issue Aug 25, 2019 · 6 comments
Closed

API change (V2 roadmap) #22

the-dr-lazy opened this issue Aug 25, 2019 · 6 comments
Labels
discussion help wanted Extra attention is needed

Comments

@the-dr-lazy
Copy link
Contributor

the-dr-lazy commented Aug 25, 2019

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
Copy link
Owner

@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.

@Kiarash-Z Kiarash-Z changed the title API change API change (V2 roadmap) Aug 30, 2019
@Kiarash-Z Kiarash-Z mentioned this issue Sep 18, 2019
@Kiarash-Z
Copy link
Owner

Kiarash-Z commented Sep 18, 2019

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

@Kiarash-Z
Copy link
Owner

Kiarash-Z commented Oct 9, 2019

🎉 A new feature has been requested, and I will add a custom way for rendering a single day item for customization purposes.

@Kiarash-Z
Copy link
Owner

🎉 the package has been renamed and republished!

@Kiarash-Z Kiarash-Z unpinned this issue Oct 25, 2019
@Aryan-mor
Copy link

🎉 A new feature has been requested, and I will add a custom way for rendering a single day item for customization purposes.

Hello, this feature is not ready yet?

@Kiarash-Z
Copy link
Owner

@Aryan-mor Hey, Unfortunately, not yet. I will consider adding it soon(working on an efficient way for this)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants