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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[eslint] Enforce jsx-handler-names #3408

Merged
merged 2 commits into from
Mar 27, 2016
Merged

[eslint] Enforce jsx-handler-names #3408

merged 2 commits into from
Mar 27, 2016

Conversation

oliviertassinari
Copy link
Member

This one is for @nathanmarks.
I have done some aggressive clean up. Be careful when reviewing 馃毃.

@nathanmarks
Copy link
Member

@oliviertassinari I wish we had tests for all these handlers right now!

Something to note, unfortunately the eslint rule is only for JSX. Which means there is an opportunity for inconsistency. See here: https://github.com/oliviertassinari/material-ui/blob/eslint-jsx-handler-names/src/DropDownMenu/DropDownMenu.jsx#L286

Maybe a quick search in /src/ for _on is in order? Not sure if you want to enforce the same convention with non-jsx elements, but it'd make sense imo.

@oliviertassinari
Copy link
Member Author

I wish we had tests for all these handlers right now!

Me too. Don't worry, my agressive changes are regarding using the open state to speedup the DatePicker and the TimePicker.

Not sure if you want to enforce the same convention with non-jsx elements, but it'd make sense imo.

I agree with you but the conflict potential of this PR with others is already high. I would say, let's take care of this with another PR.

@alitaheri
Copy link
Member

Farewell ugly underscore 馃槣 馃憤

@nathanmarks
Copy link
Member

@alitaheri React components full of underscore dangle'd class methods is the stuff of my nightmares. Readability is so much better with these changes @oliviertassinari !!

@oliviertassinari oliviertassinari added PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI and removed PR: Needs Review labels Feb 27, 2016
@oliviertassinari
Copy link
Member Author

Ping me when you think I should rebase.

@nathanmarks
Copy link
Member

@oliviertassinari Outside of what I mentioned initially, it looked good to me. Getting this merged would be great, I almost posted an issue by accident today regarding inconsistent use of comma dangled event handler methods 馃槃

@oliviertassinari
Copy link
Member Author

it looked good to me. Getting this merged would be great

馃槃. This PR may have conflict with many others PRs. I think that we should apply this change and the ES6 classes migration in a row.

@newoga
Copy link
Contributor

newoga commented Feb 27, 2016

I think that we should apply this change and the ES6 classes migration in a row.

@oliviertassinari I agree!

@nathanmarks
Copy link
Member

@newoga @oliviertassinari

Is there a PR for that? I can help combine them before merging to master if you'd like

@oliviertassinari
Copy link
Member Author

Is there a PR for that? I can help combine them before merging to master if you'd like

By in a row, I was meaning at the same time, like the same day, not combined 馃榿. We merge this one, then, we run the codemod for the ES6 classe.
The question is, when do we do this move? Let's try to minimize the impact.

@newoga
Copy link
Contributor

newoga commented Feb 27, 2016

The question is, when do we do this move?

I know this sounds crazy but I'm thinking we should save both of these for right before we do the directory restructure. Those three probably represent the biggest code changes in this release that will impact existing PRs.

I'd say do this order:

  1. Tag open PRs that we plan to have fixed for 0.15.0.
  2. Merge those PRs
  3. Apply remaining eslint rules
  4. Run react-codemod to convert to ES6 and replace PureRenderMixin
  5. Reorganize directories

I would like to do steps 3, 4, and 5 in a phase when we aren't merging any other PRs and we can do it in a short time span (same day like @oliviertassinari mentioned).

After that, existing PRs can be resubmitted or updated against the new and moved ES6 class based components.

Edit: It sounds like a lot of work but I think we're pretty close. I think the biggest step is reviewing existing PRs and getting them merged before the migration.

@nathanmarks
Copy link
Member

@newoga That sounds sensible.

When we finally "do it", might want to set it up on a temporary branch before merging it into master.

@mbrookes
Copy link
Member

I think the biggest step is reviewing existing PRs and getting them merged before the migration.

I agree. And while we've been doing a better job with new PRs, do you think perhaps we should take a break from refactoring, and all double-down on catching up with the PR backlog?

I know it's painful, but the longer we leave it, the harder fixing merge conflicts becomes.

@newoga
Copy link
Contributor

newoga commented Feb 28, 2016

break from refactoring, and all double-down on catching up with the PR backlog?

Yeah I think this is a good idea. I think we're just going to have to focus on the existing PRs and decide which ones will get in 0.15.0 and which ones have to get resubmitted after the ES6 and linting migrations.

@oliviertassinari @alitaheri, are you good with this?

@oliviertassinari
Copy link
Member Author

on catching up with the PR backlog

That sounds like an good idea.

and which ones have to get resubmitted after the ES6 and linting migrations.

We have different types of pending PRs. I think that they needs different care:

  • Some are not relevant: let's close them
  • Some needs a minor rebase: we can or the author can take care of it.
  • Some needs work and the author is still active, we can merge them for the 0.15.0 release
  • Some needs work and the author is not longer active: we can take care of them later.

@alitaheri
Copy link
Member

That makes sense 馃憤 I think we should take care of the backlog. It's getting bloated and scary 馃槰

@mbrookes mbrookes added PR: out-of-date The pull request has merge conflicts and can't be merged on hold There is a blocker, we need to wait and removed PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI labels Mar 2, 2016
@oliviertassinari oliviertassinari added this to the 0.16.0 Release milestone Mar 6, 2016
@mbrookes
Copy link
Member

@oliviertassinari - is now the time rebase and apply this? (And any other desired eslint rules?)

@oliviertassinari
Copy link
Member Author

@mbrookes That sounds like the right moment. I will try to rebase before the ES6 classes conversion.

@oliviertassinari oliviertassinari removed the on hold There is a blocker, we need to wait label Mar 23, 2016
@mbrookes mbrookes added this to the 0.15.0-beta.1 Release milestone Mar 23, 2016
@mbrookes mbrookes removed this from the 0.16.0 Release milestone Mar 23, 2016
@@ -86,7 +86,6 @@ export default class TableExampleComplex extends React.Component {
fixedFooter={this.state.fixedFooter}
selectable={this.state.selectable}
multiSelectable={this.state.multiSelectable}
onRowSelection={this._onRowSelection}
Copy link
Member Author

Choose a reason for hiding this comment

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

_onRowSelection is missing.

@oliviertassinari oliviertassinari added PR: Needs Review and removed PR: out-of-date The pull request has merge conflicts and can't be merged labels Mar 25, 2016
@oliviertassinari
Copy link
Member Author

I have just rebased this PR.

@mbrookes mbrookes added PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI and removed PR: Needs Review labels Mar 26, 2016
@oliviertassinari oliviertassinari added PR: Needs Review and removed PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI labels Mar 26, 2016
@mbrookes mbrookes merged commit 4b1b039 into mui:master Mar 27, 2016
@oliviertassinari oliviertassinari deleted the eslint-jsx-handler-names branch March 27, 2016 00:44
@zannager zannager added package: system Specific to @mui/system package: eslint Specific to eslint-plugin-material-ui labels Mar 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package: eslint Specific to eslint-plugin-material-ui package: system Specific to @mui/system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants