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

[core] Continue eslint sync with main repo #2004

Merged
merged 3 commits into from Jul 28, 2020

Conversation

oliviertassinari
Copy link
Member

@oliviertassinari oliviertassinari commented Jul 18, 2020

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.

@oliviertassinari oliviertassinari added the core Infrastructure work going behind the scene label Jul 18, 2020
@vercel
Copy link

vercel bot commented Jul 18, 2020

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/mui-org/material-ui-pickers/3czavooqp
✅ Preview: https://material-ui-pickers-git-fork-oliviertassinari-eslint-core.mui-org.vercel.app

package.json Outdated
Comment on lines 65 to 71
"/docs/",
"/e2e/",
Copy link
Member Author

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

@cypress
Copy link

cypress bot commented Jul 18, 2020



Test summary

78 0 3 0


Run details

Project material-ui-pickers
Status Passed
Commit 5acd758
Started Jul 27, 2020 11:19 PM
Ended Jul 27, 2020 11:20 PM
Duration 01:23 💡
OS Linux Debian - 10.0
Browser Chrome 80

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

Copy link
Member

@dmtrKovalenko dmtrKovalenko left a 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/

Comment on lines +100 to +112
const {
className,
day,
inCurrentMonth,
isEndOfHighlighting,
isEndOfPreviewing,
isHighlighting,
isPreviewing,
isStartOfHighlighting,
isStartOfPreviewing,
selected,
...other
} = props;
Copy link
Member

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?

Copy link
Member Author

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.

Comment on lines +34 to +37
children: PropTypes.node,
} as any;

export default withDefaultProps({ name: 'MuiPickersLocalizationProvider' }, LocalizationProvider);
export default LocalizationProvider;
Copy link
Member

Choose a reason for hiding this comment

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

Accidental changes?

Copy link
Member Author

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.

lib/src/index.ts Outdated Show resolved Hide resolved
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) => (
Copy link
Member

Choose a reason for hiding this comment

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

Why index2?

Copy link
Member Author

Choose a reason for hiding this comment

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

lib/src/DateRangePicker/DateRangePickerViewDesktop.tsx Outdated Show resolved Hide resolved
Copy link
Member Author

@oliviertassinari oliviertassinari left a 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) => (
Copy link
Member Author

Choose a reason for hiding this comment

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

Comment on lines +100 to +112
const {
className,
day,
inCurrentMonth,
isEndOfHighlighting,
isEndOfPreviewing,
isHighlighting,
isPreviewing,
isStartOfHighlighting,
isStartOfPreviewing,
selected,
...other
} = props;
Copy link
Member Author

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.

Comment on lines +34 to +37
children: PropTypes.node,
} as any;

export default withDefaultProps({ name: 'MuiPickersLocalizationProvider' }, LocalizationProvider);
export default LocalizationProvider;
Copy link
Member Author

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.

lib/src/index.ts Outdated Show resolved Hide resolved
@dmtrKovalenko
Copy link
Member

I don't understand the reasoning of your argumentation

I have provided 3 arguments:

  1. Implicit renames that could be buggy and provide unobvious
  2. The clearness in the module dependencies
  3. Easier refactoring
  4. More solid imports sections
  5. Ability to avoid unnecessarily "verbal" convention

Ok, I`ll open RFC for the core repository. On Monday 😎

@oliviertassinari
Copy link
Member Author

Ok, I`ll open RFC for the core repository. On Monday 😎

Perfect

@oliviertassinari
Copy link
Member Author

oliviertassinari commented Jul 19, 2020

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.

@oliviertassinari
Copy link
Member Author

@dmtrKovalenko Can I merge before we get a conflict?

@dmtrKovalenko
Copy link
Member

Yes you can :)

@oliviertassinari oliviertassinari merged commit 537dc6e into mui:next Jul 28, 2020
@oliviertassinari oliviertassinari deleted the eslint-core branch July 28, 2020 11:51
@mui mui deleted a comment from aamirafridi Jul 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Infrastructure work going behind the scene
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants