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

Drop the jsx-quotes eslint rule #40

Closed
84564221 opened this issue Jul 21, 2016 · 8 comments
Closed

Drop the jsx-quotes eslint rule #40

84564221 opened this issue Jul 21, 2016 · 8 comments

Comments

@84564221
Copy link

84564221 commented Jul 21, 2016

I am the originator of the idea to split the react and jsx eslint rules into separate packages.

The jsx-quotes eslint rule should be entireley dropped.

The rule is bloat here. The suggested enforcement to use double quotes in the upcoming release #564 inevitably results in an infringement of the »single quotes for strings« rule.

Following #27 , some comments

(...) the overwhelming majority of JSX out there uses double quotes because that is the preferred convention for XML and HTML (which JSX mimics).

Excuse me, Sir. What majority are you talking about @pluma? Have you shown us some evidence or are you simply using your superior GitHub reputation as an argument? And no, you are wrong.

(...) because that is the preferred convention for XML and HTML (which JSX mimics).

Wew. Here we go again: JSX is intended to be used by various preprocessors (transpilers) to transform DOM tokens into standard ECMAScript and that's it. Nothing more. It's not a proposal to incorporate with the HTML spec itself.

Please change it back to prefer-double default value. That's the common convention in React community for JSX attributes (in opposition to JS strings).

I am sorry @dverbru. Is this some exclusive club you are talking about? Again: JSX is not restricted to only one framework.

(...) Also, to reiterate what the AirBnB style guide points out

You are making up a big story here @pluma. Who or what is AirBnB and why is it important here? This is not a beauty competition. This project is about coding-style. Some people prefer single quotes, others double quotes. Some prefer spicy meatballs over tendies.

But here's the good news: The original idea of standard was to define a common, simplified coding standard, based on a few simple rules. Very simple rules. @feross made it as simple as it gets.

And the rule states to use single quotes. Point. That's it. And if you have trouble to use double and single quotes in one string, you are always welcome to use template literals. And please don't worry. The preprocessor will take care of it.

Everyone is free to define his prefered configuration, I see no reason to include this rule by default.

{
  "rules": {
    "jsx-quotes": [2, "whatsoever"]
  }
}
@pluma
Copy link

pluma commented Jul 21, 2016

I have neither the interest nor the energy to debate this all over again. I don't even care anymore. You obviously have stronger feelings about this than I do at this point, so feel free to do whatever you want. If you think syntactic purity is more important, whatever.

I'm having a hard enough time defending standard as it is. I'm not interested in debating other standard users too. Just keep me of out of this and address the actual arguments so other people have a fair chance to have a discussion.

@joshmanders
Copy link

@askmatey Drop the attitude. No need for it.

@feross
Copy link
Member

feross commented Jul 21, 2016

@askmatey Please be civil. We're all volunteers here, just doing our best. There's no need to be so aggressive.

You're the first person to raise this objection since the v8 beta. I'll keep my eyes open to any further objections before the v8 release. I don't think that most people feel very strongly about the change. And since it's fixable with standard --fix, the migration cost will be pretty low.

1 similar comment
@feross
Copy link
Member

feross commented Jul 21, 2016

@askmatey Please be civil. We're all volunteers here, just doing our best. There's no need to be so aggressive.

You're the first person to raise this objection since the v8 beta. I'll keep my eyes open to any further objections before the v8 release. I don't think that most people feel very strongly about the change. And since it's fixable with standard --fix, the migration cost will be pretty low.

@feross feross closed this as completed Jul 21, 2016
@84564221
Copy link
Author

84564221 commented Jul 22, 2016

(...) since it's fixable with standard --fix, the migration cost will be pretty low.

Please don't get me wrong @feross. The debate amongst developers on whether one should use double quotes or single quotes in ECMAScript has been around for ages. You know it. And with standard you have developed a solution. The rules form the basis. But there should be no exception to the norm by default, especially when there's no obvious reason - like using double quotes for JSX.

(...) If you think syntactic purity is more important, whatever.

Yes, I think so @pluma. Again, JSX is not intended to incorporate with the HTML spec. And let's take it the other way around: The HTML spec itself says, that single and double quotes are interchangeable, there is no difference

By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa.

https://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2

Drop the attitude. No need for it.

Excuse me, this is not a safe space @joshmanders

@joshmanders
Copy link

Excuse me, this is not a safe space @joshmanders

Has nothing to do with safe spaces and all to do with you being a dick. You can get your point across without the latter.

@pluma
Copy link

pluma commented Jul 22, 2016

@askmatey neither the community nor the maintainers owe you (nor anyone else for that matter) any attention or affordances. I suggest you adjust your tone. There may be a worthwhile discussion here but it's not going to happen if you're being disrespectful and hostile.

@dcousens
Copy link
Member

dcousens commented Jul 22, 2016

Continue discussion in #27 (with which, this is a duplicate anyway), this thread doesn't appear to be constructive.

@standard standard locked and limited conversation to collaborators Jul 22, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

5 participants