[milestone] Convert the library to typescript #4700
Comments
mirus-ua
changed the title
|
@martijnrusschen can you pin the issue? |
|
Nice progress so far! |
|
@mirus-ua ( @martijnrusschen ) |
|
refs #4000 |
|
@yuki0410-dev Feel free to claim a file and let it know here so there's no duplicate work done. |
|
@yuki0410-dev hello |
|
I would like to take the portal jsx file in work |
|
I would like to take the week_number.jsx file in work |
|
Added your name to week_number.jsx |
|
6.6% 💪
|
|
@mirus-ua |
|
@mirus-ua |
|
@martijnrusschen hello. Please ask reviews to look at four opened PRs if you can. It'll be much faster if we merge them because the rest of the modules depend on them |
|
Yep, I'll expect them to complete this soon. Normal turnaround time is ~2-4 hours. |
|
It looks like I underestimated the amount of work. Almost all tests have types issues, so I don't think that I can do it relatively fast alone |
|
Is this something that could be split up somehow? |
I can push the branch with basic config, and then we can use it as PRs target for this activity |
|
sounds good |
|
I'll do it today UPD: |
|
@mirus-ua |
|
@mirus-ua @martijnrusschen |
|
Are we safe to cut a major release now we've converted the last tests? |
I think so. We've done everything possible to integrate types safely into the existing code base and save the future feature development from type degradation |
|
Cool, for the release notes, we should capture the breaking changes. |
|
Here's the changelog: https://github.com/Hacker0x01/react-datepicker/releases/tag/v7.0.0 |
|
That was a good teamwork. Thanks all. I think the issue should be open because we have some work with docs to do |
|
I only had one custom component interfacing with ReactDatePicker but I encountered a lot of breaking changes that weren't listed in the release.
I had an interface as below: interface DateInputProps extends Partial<ReactDatePickerProps> {
style?: React.CSSProperties;
}With an onChange with below def: function handleChange(date: Date | null)
In the end my interface looks like this: type CustomDatePickerProps = Omit<
DatePickerProps,
'onChange' | 'onSelect' | 'selectsRange' | 'selectsMultiple'
> & {
onChange?: (
date: Date | null,
event?: React.MouseEvent<HTMLElement> | React.KeyboardEvent<HTMLElement>,
) => void;
onSelect?: (
date: Date | null,
event?: React.MouseEvent<HTMLElement> | React.KeyboardEvent<HTMLElement>,
) => void;
excludeScrollbar?: boolean;
selectsRange?: boolean;
selectsMultiple?: boolean;
};
type DateInputProps = CustomDatePickerProps & {
style?: React.CSSProperties;
};And my handleChange like this: function handleChange(
date: Date | null,
event?:
| React.MouseEvent<HTMLElement>
| React.KeyboardEvent<HTMLElement>
| undefined,
) |
|
@bsal649 ( @mirus-ua @martijnrusschen ) I will answer as far as I am aware.
I think you forgot to put this in the "breaking changes" section.
I think this is not "breaking changes" because this is a change from @types/react-datepicker, which is originally managed by someone outside this Repository member.
I could not find that Props in this current Repository.
It must be uninstalled. |
|
@yuki0410-dev Thanks for the explanation, and fair enough. Maybe it'd be worth putting a note in the release that people who were using @types/react-datepicker might have a lot more breaking changes. |
|
@yuki0410-dev For "ReactDatePicker name changed to DatePicker.", that doesn't seem like an intended change and will be causing everyone to make changes. Can we reduce the breaking changes by reverting to the original name? I don't see a need to force change that here. Thoughts? Same counts for "ReactDatePickerProps name changed to DatePickerProps." |
The right way, IMO, is to add these in the list of the breaking changes rather then violating semver rules |
|
That would be the alternative, but it forces everyone to update their code for just a name change. |
|
@martijnrusschen @mirus-ua Currently, class names have not been changed since v6.9.0. react-datepicker/src/index.jsx Line 80 in 02ce53f |
Contribution is welcome
Why?
Everything started here from the willing to merge a separate package with the corresponding type definitions into this repo.
The idea is great, but we, as a community, can go further and migrate the entire code base into typescript.
Any benefits?
Our steps to achieve the goal
.tsand.tsxmodules [typescript-migration] initial ts config and the first calendar_container.jsx module #4704ts-jest@mirus-uaModules to migrate and how to contribute
Basic rules and advice:
calendar_container.jsxanyor other loose types if you don't have strong argumentsSteps to contribute
[typescript-migration] calendar.jsxetc.Breaking changes so far:
newDatehelper always returns a date, if the initial params were invalid, then it returns just anew DateLine; PRThe text was updated successfully, but these errors were encountered: