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

[typescript-to-proptypes] Allow to represent dates as PropTypes.object #40774

Merged
merged 4 commits into from
Jan 26, 2024

Conversation

flaviendelangle
Copy link
Member

@flaviendelangle flaviendelangle commented Jan 24, 2024

Needed for mui/mui-x#11791

To give some context, on the pickers we are supporting several date libraries (dayjs, moment, date-fns and Luxon)
Date-fns is using JavaScript dates for its values and the other are using custom objects
In mui/mui-x#11791, I'm improving the typing so that when you import an adapter (the utility that unifies all the date library APIs), you also say to the components that the props can receive a value in the date format of your date libraries.
But we have one issue, the proptypes generated are not PropTypes.oneOfType([PropTypes.object, PropTypes.instanceOf(Date)]) due to date-fns. And this is super misleading for people using another date library.

To solve this, I added a new option to the prop-types generation to allow to represent dates as object.

If you have a better idea I'm interested

@flaviendelangle flaviendelangle self-assigned this Jan 24, 2024
@mui-bot
Copy link

mui-bot commented Jan 24, 2024

Netlify deploy preview

https://deploy-preview-40774--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 8ae7c38

@flaviendelangle flaviendelangle changed the title [typescrip-to-proptypes] Allow to represent dates as PropTypes.Object [typescrip-to-proptypes] Allow to represent dates as PropTypes.object Jan 24, 2024
@flaviendelangle flaviendelangle added the scope: code-infra Specific to the core-infra product label Jan 24, 2024
@flaviendelangle flaviendelangle changed the title [typescrip-to-proptypes] Allow to represent dates as PropTypes.object [typescript-to-proptypes] Allow to represent dates as PropTypes.object Jan 24, 2024
Copy link
Member

@alexfauquette alexfauquette left a comment

Choose a reason for hiding this comment

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

But we have one issue, the proptypes generated are not PropTypes.oneOfType([PropTypes.object, PropTypes.instanceOf(Date)]) due to date-fns. And this is super misleading for people using another date library.

I'm not sure to understand. Currently your PR that uses this branch shows PropTypes.oneOfType([PropTypes.object, PropTypes.instanceOf(Date)]). But what was it before the fix? With this method I would expect something like minDate: PropTypes.object, since all date should be replaced by object

Edit: Ok, I see you did not modified the pickers project config. So

  • Currently you have PropTypes.oneOfType([PropTypes.object, PropTypes.instanceOf(Date)]) due to date-fns.
  • By configuring the project you could get PropTypes.object

A more flexible approach could be to export the createAnyType, createInstanceOfType, ... and instead of shouldUseObjectForDate we could have a getProptypesOverride that is called before others. If it return undefined we continue. If it returns an object we use it.

But that might be overkill. I don't see a lot of other types that could be mixed

@flaviendelangle
Copy link
Member Author

I'm not sure to understand. Currently your PR that uses this branch shows PropTypes.oneOfType([PropTypes.object, PropTypes.instanceOf(Date)]).

I'm trying to use this branch on the X repo but I end up with incompatibilities on other parts of the monorepo...
I had the right prop-types before, I should have them again soon.

@flaviendelangle
Copy link
Member Author

A more flexible approach could be to export the createAnyType, createInstanceOfType, ... and instead of shouldUseObjectForDate we could have a getProptypesOverride that is called before others. If it return undefined we continue. If it returns an object we use it.

Maybe it's slightly overkill for a first occurrence of custom behavior indeed.
But to keep in mind if we encounter others

Copy link
Member

@alexfauquette alexfauquette left a comment

Choose a reason for hiding this comment

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

Good for me. Maybe wait to have the PR working on X repo before merging this one

@flaviendelangle
Copy link
Member Author

The PR should be updated on X 👍

@flaviendelangle flaviendelangle merged commit 27c5144 into mui:master Jan 26, 2024
19 checks passed
@flaviendelangle flaviendelangle deleted the date-resolve branch January 26, 2024 07:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: code-infra Specific to the core-infra product
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants