-
Notifications
You must be signed in to change notification settings - Fork 831
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 changes #1534
Api changes #1534
Conversation
This pull request is being automatically deployed with ZEIT Now (learn more). 🔍 Inspect: https://zeit.co/mui-org/material-ui-pickers/j765yiwoj |
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
Codecov Report
@@ Coverage Diff @@
## next #1534 +/- ##
=========================================
+ Coverage 91.8% 91.85% +0.04%
=========================================
Files 62 62
Lines 1746 1755 +9
Branches 298 304 +6
=========================================
+ Hits 1603 1612 +9
+ Misses 111 109 -2
- Partials 32 34 +2
Continue to review full report at Codecov.
|
Regarding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you keep track of the API breaking changes somewhere? Maybe we should start a migration guide?
I am following material design guidelines, there it is called |
I'm not sure the developers coming to the component will be aware of how the material design specification calls the label. I think that as long as it's intuitive and consistent, it will be great. No strong preference,
In terms of user experience, I think that:
I think that 2. is a nice tradeoff between the DX and the time required to make it happen. What do you think? |
The migration guide will be done anyway. Like we do for v3 https://material-ui-pickers.dev/guides/upgrading-to-v3 |
I would expect a codemod to take about an afternoon of work or more. But I have never done prop renaming for a codemod (at least I only remember doing import renaming). My estimate could be wrong. |
I have no idea what's wrong with percy 🤔 |
This PR is a part of vNext #1293 development
Description
New props
toolbarFormat
- easily customize date string displaying in toolbar (New property to change the date/time format from the toolbar #1345)disableHighlightToday
- disable highlighting of today date with a circleshowDaysOutsideCurrentMonth
- show days outside of current month in calendardisableMargin
- (onlyDay
prop) disable margin between days, useful for range displaying when days are linked together with background colorRemove props
labelFunc
- completely unusable function with current keyboard input designinvalidLabel
- pretty same, unusable with keyboard input, useerror
andhelperText
insteadRenames
format
=>inputFormat
emptyLabel
=>emptyInputText
initialFocusedDate
=>defaultHighlight
title
=>toolbarTitle
(+ make it accept value fromlabel
as default)Change signatures
renderDay
Motivation:
Better customization of the day displaying, by allowing to spread down and override any props we need, before it was possible only by
React.cloneElement
, but it was not so powerful like spreading props down. This also better from performance perspective when overriding days, because we are not rendering day bides ourself if user will render something different.