-
Notifications
You must be signed in to change notification settings - Fork 76
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
More lenient jsx-no-multiline-js rule #50
Comments
How lenient do you think it should be? Should we just allow object literals, or do you think this should allow things like
Also, this rule currently doesn't care about spread attributes, eg
but that's probably a separate issue. |
@adidahiya @markwongsk this is hanging for quite some time, can we push for this change? I really need this configurability and I think that disable for object literals is enough for a start. |
@markwongsk I guess we could break down the use cases into "be lenient on multiline functions / lambdas" and "be lenient on object or array literals". so this rule could have two new options: @piotrwitek open to PRs, as always :) |
Would it be a simpler distinction between JS statements and expressions? It seems like multline expressions (object literals, ternary, function calls, etc) make more sense than multiple statements. |
@MiguelMadero eh, that wouldn't really solve my use case because so much of JS syntax is a valid expression. My primary motivation for using this rule was to ban multiline ternarys and function calls (primarily // bad
<div className={
someComplicatedCondition
? "positive-case"
: "positive-case"}
otherProp={true}
/>
// bad
<div>
{this.props.foo.map((f) => {
return <span>{f}</span>;
})}
</div> I could imagine another option here for stylistic preference, however, |
@adidahiya Could you please recommend a way for the 2 cases you gave above. I got this rules triggered a lot and I'm not sure how to improve them. Thanks. |
Is there any plan or update about this topic? |
Closing due to deprecation, see #210 |
I think the rule should be lenient about these kinds of multiline expressions because they don't hinder readability too much:
update: we should also add more exemptions:
allow-function-call
to ignore function call expressionsallow-literal
to ignore checking object and array literalsallow-element
to ignore JSX elementsThe text was updated successfully, but these errors were encountered: