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

feat(DateRangePicker): limit start year #3151

Closed
wants to merge 11 commits into from
Closed

Conversation

loposkin
Copy link
Contributor

@loposkin loposkin commented Apr 7, 2023

CHANGES

Added limitStartYear prop to DateRangePicker. Usage:

<DateRangePicker
          limitEndYear={1}
          limitStartYear={5}
          ...
>

This looks like:
limit_start_year

If unset, the start year still defaults to 1900

ISSUE

close #3145

@vercel
Copy link

vercel bot commented Apr 7, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
rsuite-nextjs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 17, 2023 2:23pm
1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
rsuite-v4 ⬜️ Ignored (Inspect) Apr 17, 2023 2:23pm

@vercel
Copy link

vercel bot commented Apr 7, 2023

@loposkin is attempting to deploy a commit to the rsuite Team on Vercel.

A member of the Team first needs to authorize it.

@codesandbox-ci
Copy link

codesandbox-ci bot commented Apr 7, 2023

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 9e9d1d6:

Sandbox Source
rsuite-tp-ci Configuration

@codecov
Copy link

codecov bot commented Apr 10, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01 🎉

Comparison is base (786e930) 93.43% compared to head (a184e82) 93.44%.

❗ Current head a184e82 differs from pull request most recent head 9e9d1d6. Consider uploading reports for the commit 9e9d1d6 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3151      +/-   ##
==========================================
+ Coverage   93.43%   93.44%   +0.01%     
==========================================
  Files         562      563       +1     
  Lines       20395    20415      +20     
  Branches     2739     2740       +1     
==========================================
+ Hits        19056    19077      +21     
  Misses        694      694              
+ Partials      645      644       -1     
Flag Coverage Δ
ChromeCi 93.40% <100.00%> (+0.01%) ⬆️
Firefox 92.70% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/Calendar/CalendarContainer.tsx 100.00% <ø> (ø)
src/DateRangePicker/Calendar.tsx 96.55% <ø> (ø)
src/Calendar/Calendar.tsx 90.00% <100.00%> (+0.34%) ⬆️
src/Calendar/MonthDropdown.tsx 100.00% <100.00%> (+2.22%) ⬆️
src/Calendar/test/CalendarMonthDropdownSpec.tsx 100.00% <100.00%> (ø)
src/DatePicker/DatePicker.tsx 94.63% <100.00%> (ø)
src/DateRangePicker/DateRangePicker.tsx 88.03% <100.00%> (ø)
...DateRangePicker/test/CalendarMonthDropdownSpec.tsx 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@loposkin
Copy link
Contributor Author

loposkin commented Apr 10, 2023

@simonguo, do I need to do something else? Looks like the authorization is missing on some test stage.

Copy link
Member

@SevenOutman SevenOutman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @loposkin, thank you for contributing this edit!

As this PR adds new APIs, please add test cases to ensure the API work as expected.

@loposkin
Copy link
Contributor Author

loposkin commented Apr 11, 2023

@SevenOutman, I've added a test for a MonthDropdown's limitStartYear and limitEndYear props. I've also added missing propTypes.

Comment on lines +23 to +29
expect(getAllByRole('row', { hidden: true })).to.be.lengthOf(2);
expect(getAllByRole('rowheader', { hidden: true })[0].innerText).to.be.eq(
previousYear.toString()
);
expect(getAllByRole('rowheader', { hidden: true })[1].innerText).to.be.eq(
currentYear.toString()
);
Copy link
Member

@SevenOutman SevenOutman Apr 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me confirm this. Does it mean that limitStartYear={1} results in the earliest year be 1 year before current, while limitEndYear={1} results in the latest year be just current year? If so, I don't think it's consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, yes, you're right and yes, it's not consistent. The limitStartYear={1} results in the earliest year that is 1 year before current, while limitEndYear={1} results in the current year. The problem is that I only propagate the props to existent MonthDropdown-API. Should I change this API? I think it would mean a breaking change for people who already use MonthDropdown.

@simonguo
Copy link
Member

Hi @loposkin

If the limitEndYear and limitStartYear props are to be exposed, I hope he can make some adjustments in the design to make it more reasonable to use.

limitStartYear?: number | ((activeDate: Date) => number);
limitEndYear?: number | ((activeDate: Date) => number);

where the number value should be a year.

<DateRangePicker limitStartYear={1990} limitEndYear={2023} />
<DateRangePicker
  limitStartYear={(activeDate: Date) => {
    return addDays(getYear(activeDate), -5);
  }}
  limitEndYear={(activeDate: Date) => {
    return addDays(getYear(activeDate), 5);
  }}
/>;

Also limitEndYear and limitStartYear props should be supported on both DatePicker and Calendar.

@loposkin
Copy link
Contributor Author

@simonguo @SevenOutman , I've changed the API according to @simonguo suggestion. I've also updated Calendar's and DatePicker's API accordingly. limitStartYear and limitEndYear are now consistent and the api looks like:

<DateRangePicker
          limitEndYear={2018}
          limitStartYear={2023}
          ...
>

I've updated the english documentation accordingly, unfortunatelly, I am missing required language skills to update the documentation in Chinese.

As for functional values for limitStartYear and limitEndYear props, this exceeds the original issue and I have no resources to implement it right now.

@SevenOutman
Copy link
Member

Hi, yes, you're right and yes, it's not consistent. The limitStartYear={1} results in the earliest year that is 1 year before current, while limitEndYear={1} results in the current year. The problem is that I only propagate the props to existent MonthDropdown-API. Should I change this API? I think it would mean a breaking change for people who already use MonthDropdown.

@loposkin, MonthDropdown is an internal component that's not exported as a public API, so I think it's OK to either change it's limitStartYear behavior, or simply leave it as is and change the value that DateRangePicker passes to MonthDropdown. That way limitStartYear of DateRangePicker (as a public API) is consistent with limitEndYear, and minimum changes have to be made.


If the limitEndYear and limitStartYear props are to be exposed, I hope he can make some adjustments in the design to make it more reasonable to use.
where the number value should be a year.

<DateRangePicker limitStartYear={1990} limitEndYear={2023} />

@simonguo, the limitEndYear prop already exists on DateRangePicker, so a direct change like this is breaking. I don't think it's appropriate to introduce this change in the current major release. I agree that limitStartYear and limitEndYear should have been more straightforward, we can make this change in next major release with migration guidance for users.

@loposkin
Copy link
Contributor Author

@SevenOutman, so if I change the api to be consistent to existent limitEndYear APIs, such that <DateRangePicker limitStartYear={1} limitEndYear={1} /> will only show current year and <DateRangePicker limitStartYear={2} limitEndYear={2} /> will show the years from 2022 to 2024, would it be possible to merge this in the next release? Or would you rather implement it properly in the next major release?

@SevenOutman
Copy link
Member

@SevenOutman, so if I change the api to be consistent to existent limitEndYear APIs, such that <DateRangePicker limitStartYear={1} limitEndYear={1} /> will only show current year and <DateRangePicker limitStartYear={2} limitEndYear={2} /> will show the years from 2022 to 2024, would it be possible to merge this in the next release? Or would you rather implement it properly in the next major release?

It's going to be merged.

@loposkin
Copy link
Contributor Author

@SevenOutman, I've opened another PR with requested changes.

@loposkin loposkin closed this Apr 17, 2023
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

Successfully merging this pull request may close these issues.

Limit start year for DateRangePicker
3 participants