-
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
[core] Continue eslint sync with main repo #2004
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/mui-org/material-ui-pickers/3czavooqp |
package.json
Outdated
"/docs/", | ||
"/e2e/", |
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.
Legacy, no need to handle them
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 |
612f50f
to
761cab7
Compare
761cab7
to
6ffcced
Compare
6ffcced
to
9b3f7b9
Compare
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.
There is one rule that I am strongly want to discard and never use nor in the picker nor in the core code – default exports. We should not use them when we exactly know what we are importing – in all cases except examples.
In short: when we exporting CalendarView
we do want everybody to use them like CalendarView and not like Calendar
or something else. This potential rename through the default exports is always implicit – why not avoid it? Moreover code with only named exports looks much more consistent because all the import lines have the same structure (starting with import {
)
https://medium.com/@rajeshnaroth/avoid-es6-default-exports-a24142978a7a
https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/
const { | ||
className, | ||
day, | ||
inCurrentMonth, | ||
isEndOfHighlighting, | ||
isEndOfPreviewing, | ||
isHighlighting, | ||
isPreviewing, | ||
isStartOfHighlighting, | ||
isStartOfPreviewing, | ||
selected, | ||
...other | ||
} = props; |
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.
What the original motiviation for this kind of change? Is this doing automatically?
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.
The first-order motivation is to match the convention of the main repository. The second-order motivation was to allow quick scanning of the signature of the function. If you see "props" => it means it's a React component.
children: PropTypes.node, | ||
} as any; | ||
|
||
export default withDefaultProps({ name: 'MuiPickersLocalizationProvider' }, LocalizationProvider); | ||
export default LocalizationProvider; |
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.
Accidental changes?
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.
What problem does withDefaultProps
solve? I have removed it as LocalizationProvider
is already a global provider, it duplicates.
const classes = useStyles(); | ||
const calendarClasses = useCalendarStyles(); | ||
|
||
return ( | ||
<div className={clsx(classes.root, className)} {...other}> | ||
{monthMap.map((week, index) => ( | ||
<div key={index} className={calendarClasses.week}> | ||
{week.map((day, index) => ( | ||
{week.map((day, index2) => ( |
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.
Why index2?
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.
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.
Interesting topic on the named vs default imports, thanks for bringing it up. A couple of thoughts:
- I don't understand the reasoning of your argumentation. Would you like to make the case for it with an RFC on the main repository? Detailing the current problems and how this potential new standard could fix them?
- Both articles start by mentioning that both are valid, that it's a coding convention before anything else
- This is opinionated nit picky territory.
- Personal preferences
- Looking at the thread on Twitter: https://twitter.com/slicknet/status/1084101377297506304. It seems that default vs named export isn't the core of the solution of the problems, but the solution is much more about having a convention and following it systematically.
- Looking at the problems raised by the articles, it seems it can be solved with the convention we applying in the main repository for the React components: one component = one file, name of the component = name of the file. As for non-React modules, that's a different story.
const classes = useStyles(); | ||
const calendarClasses = useCalendarStyles(); | ||
|
||
return ( | ||
<div className={clsx(classes.root, className)} {...other}> | ||
{monthMap.map((week, index) => ( | ||
<div key={index} className={calendarClasses.week}> | ||
{week.map((day, index) => ( | ||
{week.map((day, index2) => ( |
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.
const { | ||
className, | ||
day, | ||
inCurrentMonth, | ||
isEndOfHighlighting, | ||
isEndOfPreviewing, | ||
isHighlighting, | ||
isPreviewing, | ||
isStartOfHighlighting, | ||
isStartOfPreviewing, | ||
selected, | ||
...other | ||
} = props; |
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.
The first-order motivation is to match the convention of the main repository. The second-order motivation was to allow quick scanning of the signature of the function. If you see "props" => it means it's a React component.
children: PropTypes.node, | ||
} as any; | ||
|
||
export default withDefaultProps({ name: 'MuiPickersLocalizationProvider' }, LocalizationProvider); | ||
export default LocalizationProvider; |
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.
What problem does withDefaultProps
solve? I have removed it as LocalizationProvider
is already a global provider, it duplicates.
I have provided 3 arguments:
Ok, I`ll open RFC for the core repository. On Monday 😎 |
Perfect |
9b3f7b9
to
68cd77b
Compare
On a side note, there is an important eslint rule that I couldn't fix and I had to put as a warning that will require to rethink the file structure: import/no-cycle. @dtassone Thanks for insisting on this rule. It turns out +23s on the main repository build was worth it for here :). I think that it will be a perfect opportunity to adopt the main repository file structure (folders, index.js, default export, etc). It might also something we want to batch with the tree-shaking reports: #1670. |
68cd77b
to
c55d4c6
Compare
c55d4c6
to
cf7f555
Compare
cf7f555
to
b07e758
Compare
b07e758
to
2906640
Compare
2906640
to
b81f88f
Compare
b81f88f
to
79f0eb1
Compare
79f0eb1
to
a03468b
Compare
I have reverted the changes related to the import, waiting for the outcome of the RFC. It should be ready now
a03468b
to
712de04
Compare
712de04
to
68f2e2e
Compare
68f2e2e
to
ce97a21
Compare
@dmtrKovalenko Can I merge before we get a conflict? |
Yes you can :) |
Follow-up on #1930 and mui/material-ui#21758.
I turned a couple of rules as "warn" as I didn't want to handle them now. We can take care of them progressively, one that is concerning and important to fix is the import/no-cycle one.
Same as mui/mui-x#72. Once merged, we will need to work on solving all the warnings, this is a pre-requisite to be able to move the component in the main repository.