Feature list of react-tailwindcss-datepicker

[JefteCaro]

Welcome!

This board will be dedicated for feature requests and suggestions.

If a necessary feature is not yet supported by this package, comment your request in this board.

But, of course, Pull Requests are always welcome.

We want to make this project more helpful. If you see bugs and issues, create a new Issue.

Features and Customizations

• ✅ Theming options
• ✅ Dark mode
• ✅ Single Date
• ✅ Single date use Range
• ✅ Shortcuts
• ✅ TypeScript support
• ✅ Localization(i18n)
• ✅ Disable date
• ✅ Custom shortcuts

[JefteCaro]

[Feature Request]

Let's try to add new prop mode

Ex:

To select range of months or years

// Range of months
<Datepicker
  mode="month" // month | year | null
/>

// Range of years
<Datepicker
  mode="year" // month | year | null
/>

To select single month or year

// Select month
<Datepicker
  asSingle
  mode="month" // month | year | null
/>

// Select year
<Datepicker
  asSingle
  mode="year" // month | year | null
/>

Issue Reference: #3

[JefteCaro]

[Feature Request]

Optionally change all inner component's class names
overrideClass

Ex.

<Datepicker
  overrideClasses={
   input: 'new-input-classnames',
   container: 'new-container-classnames',
   calendar: 'new-calendar-classnames',
   days: 'new-days-classnames',
   months: 'new-months-classnames',
   years: 'new-years-classnames'
  }
/>

[onesine]

[Feature Request]

Optionally change all inner component's class names overrideClass

Ex.

<Datepicker
  overrideClasses={
   input: 'new-input-classnames',
   container: 'new-container-classnames',
   calendar: 'new-calendar-classnames',
   days: 'new-days-classnames',
   months: 'new-months-classnames',
   years: 'new-years-classnames'
  }
/>

This is perfect, but some elements may need special status to add other utilities classes.

Ex:

<Datepicker
  overrideClasses={
   // ...
   input: disabled => `new-input-classnames ${disabled ? 'disabled-input-classnames' : ''}`,
   // ...
  }
/>

[JefteCaro]

Yes.

I think, since we use tailwindcss, we can make use of the pseudo-elements when implemented.

Ex:

<Datepicker
  overrideClasses={
    input: 'new-input-classnames disabled:cursor-none disabled:opacity-70'
    ...
  }
/>

[onesine]

Yes @JefteCaro , you are right. But I think it would still be good to expose some useful variables. If we do that, it will save us from having to answer people who ask that afterwards.

We could even have both options.
Ex:

<Datepicker
  overrideClasses={
    input: 'new-input-classnames disabled:cursor-none disabled:opacity-70'
    ...
  }
/>

Or

<Datepicker
  overrideClasses={
   // ...
   input: disabled => `new-input-classnames ${disabled ? 'disabled-input-classnames' : ''}`,
   // ...
  }
/>

Users can choose to use the string or callback

[JefteCaro]

I see.

How about we open the entire props of the inner components? I think this would result to much more customization posiblilities

<Datepicker
  overrideProps={
    ...
    input: ({disabled, onChange, ...props}) => {
        className: `input-class ${disabled ? 'disabled-input-class' : ''}`,
        onChange: (e) => {
          // set the exact input value
        }
    },
    ...
  }
/>

[onesine]

Indeed, that would be very interesting. I haven't thought about it at all 😅. But can we implement everything from the beginning?

[NoahMLoomis]

[Feature Request]

It would be nice to have a readonly prop so the only way to select dates is by clicking the dates, not entering it manually as text

[NoahMLoomis]

Pr here @onesine : #18

[onesine]

Thanks @NoahMLoomis for the PR. They are always welcome.
This is a very interesting feature. But it should be optional and not mandatory for the user.

[NoahMLoomis]

[Feature Request]

It would be nice to have a formatDisplay prop so the input can be formatted differently

This is addressed in PR #19

[onesine]

This one is also interesting and should also remain optional for the user.
We can set a default value to have the current operation.

I think this will allow those who already use the package not to have an unexpected effect when upgrading. Same thing for the PR #19 .

[NoahMLoomis]

Both props displayFormat and readonly are optional, are they not?

[onesine]

Yes, you are right. They are indeed optional. Thank you @NoahMLoomis .

[handinugroho]

[Feature Request]

Option to change the first weekday to Monday instead of Sunday.

[onesine]

Hello @handinugroho 👋, thank you for your feedback.

Your request is very pertinent. It will be part of the next updates.

[handinugroho]

Thanks! @onesine
Can I make a PR for this?

[onesine]

Of course, all PRs are welcome.

[Algomorph]

[Feature Request] Inline option

Cross-posting from #100.

The inline option should allow to fix the date-picker portion, i.e make it not collapsible. I'm not sure how to handle hiding/showing the input tag in case inline mode is used, but perhaps force_tag_display option can be added to disable hiding tag in inline mode, although maybe there is a more elegant way to go about both tag & picker.

Posting (again) relevant examples from react-datepicker:
Inline Version
Multiple Months Inline Version
Inline version w/ range selection & date exclusion

[designed2use]

[Feature Request] Disable hide calendar on change

I am unable to find a property which stops the popup calendar from closing on changing the date using the shortcuts.

For example adding an option for "disableClose" would keep the calendar open until dismissed by clicking away or confirm.

Thanks,
Ian