Eslint-plugin-react: Is there any way to multiline all JSX props if there are more than X props on element?

[Onatolich]

Hello, I want to achieve a behavior when JSX props will all be multiline if amount of props is more than defined value. Currently there is react/jsx-max-props-per-line that is the closest to what I need, but if I set its maximum to 2, it groups props in multiple lines grouped by 2. So this JSX:

<Component prop1="value 1" prop2="value 2" prop3="value 3" prop4="value 4" />

Will be formatted to this:

<Component
  prop1="value 1" prop2="value 2"
  prop3="value 3" prop4="value 4"
/>

While I want to achieve this:

<Component
  prop1="value 1"
  prop2="value 2"
  prop3="value 3"
  prop4="value 4"
/>

Is it possible to add a rule like react/jsx-props-multiline with attribute like after with amount of props after which it should be multiline?

[ljharb]

I think a reasonable thing to add to jsx-max-props-per-line would be to allow maximum to be, in addition to a number x like it is now, an object like { "single": y, "multi": x }. That way, you could configure the rule like this:

"react/jsx-props-multiline": ["error", {
  "maximum": {
    "single": 2,
    "multi": 1
  },
  "when": "always"
}],

which would, for single-line tags, error on 3+ props, and for multiline tags, error on 2+ props.

This object form of "maximum" would only make sense when when is set to "always" or omitted.

Thoughts?

[jzabala]

@ljharb

I think this is a duplicate of https://github.com/yannickcr/eslint-plugin-react/issues/2598.

Regarding the implementation how about if instead of an object we defined two new properties:

"react/jsx-props-multiline": ["error", {
  "maxSingular": 2,
  "maxMulti": 1,
  "when": "always"
}],

We deprecate maximum, and to preserve the current behavior if not set, maxSingular and maxMulti will be equal to maximum.

[ljharb]

What’s the advantage to having the object be flat?

[jzabala]

What’s the advantage to having the object be flat?

We would avoid a breaking change in the next version and it would be easier to validate.

We won't have to evaluate for the maximum too. Something like:

const maximum = (config && config.maximum) || {}`.
const singular = maximum.singular || defaultSingular
const multi = maximum.multi || defaultMulti

If we already have the config object, it would be just:

const singular = config.maxSingular  || defaultSingular
const multi = config.maxMulti || defaultMulti

[ljharb]

What would be a breaking change? We'd support both a number, or an object, under maximum, in my proposal.

I'm more concerned with the cleanliness of the config than with using 2 vs 3 lines in the rule :-)

[jzabala]

What would be a breaking change? We'd support both a number, or an object, under maximum, in my proposal.

Oh sorry. Did not get the part that both would be supported. Awesome. In favor of object too 😁

[iiison]

is anybody working on this? If not, I can give this a shot...

[jzabala]

is anybody working on this? If not, I can give this a shot...

Go for it 👍🏼

[iiison]

@ljharb | @jzabala does it make sense to change the property name single and multi to singleLine and multiLine respectively? It would be more intuitive.

[ljharb]

@iiison what would "single" or "multi" refer to that wasn't pretty obviously "lines"?

[iiison]

well, it is. It didn't make sense to me in the first look. Maybe it's just me. I will keep single and multi 😀

[iiison]

@ljharb I have a small confusion(it may sound obvious), say this is the config for the rule:

"react/jsx-props-multiline": ["error", {
  "maximum": {
    "single": 2,
    "multi": 1
  },
  "when": "always"
}]

And this is user's code:

<App foo bar baz demo val /> 

As this is a single line tag, the rule will throw an error by asking to put 2 props per line to make it look like:

<App 
  foo bar 
  baz demo 
   val 
/> 

But now, if you run the linter again, it with throw the error again to put 1 prop per row, as it's a multi-line tag now. I see 2 ways to tackle this situation, a) To check the code for multi-line tag rule once the single line tag rule is completed. b) To make the user provide only one rule, either single or multi.

Please let me know if this makes sense.

[ljharb]

I believe eslint already does multiple passes on the command line in order to ensure that no further autofixes are needed.

However, it would be ideal for the rule to suggest the correct fix in the first place (ie, your option "a" there).

[iiison]

Okay, few things about the option "a":

• That means single will most likely be overruled by multi. Which, I feel makes single a little redundant(maybe it's my personal opinion).
• This one is a little tricky, suppose the user has this config:

"react/jsx-props-multiline": ["error", {
  "maximum": {
    "single": 1,
    "multi": 2
  },
  "when": "always"
}]

And this the code:

<App foo bar  /> 

In this case, single would ask the user to make one prop each line. But as multi gets verified after single, the actual error(when the fix wasn't triggered) in the console will ask to put two props in a line, and that is already there in the code.

Though I completely understand these configs don't make much sense, but it's a possible option. One solution could be to mandate the user to keep single > multi.

Let me know what you think 😊

[jzabala]

In that case @iiison the rule would ask to put the props in one line but not in the initial line. With the config you are describing and the example code the valid version would be:

<App
  foo bar
/> 

[iiison]

Sounds like a good idea to me! Let me start the implementation then 😊

[ljharb]

I think that there is certainly a possibility of conflict if some folks want single > multi, and others want multi > single.

I think we can implement with this plan, and if folks want to flip the priority, we can add another config option (that defaults to single > multi) that can be set to multi > single.

[jzabala]

I think that there is certainly a possibility of conflict if some folks want single > multi, and others want multi > single.

I think we can implement with this plan, and if folks want to flip the priority, we can add another config option (that defaults to single > multi) that can be set to multi > single.

If we evaluate based on the start and ending line of the component we might avoid any conflicts.

For example, for single line declarations:

<App foo bar  />

there is no need to run the multiline code. It will ask if the number of props is greater than single and if that is the case suggest the corresponding multiline fix.

And for multiline declarations:

<App 
  foo fooz
  bar baz
/>

there is no need to run the single line code. It will ask if the number of props per line is greater than multi and if that is the case suggest the corresponding multi or single fix.

That way we can avoid adding another config option to the rule.

[iiison]

yep, we wouldn't stumble upon the single-multi issue if we start the props from new line. But, say, user doesn't run fix and make changes by themself. And makes the code look like(first prop is next to JSX Opening element):

<App foo 
  fooz
  bar baz
/>

should we show error in this case?

[iiison]

I'm implementing the "props to start from the new line" in the fix function for now. @ljharb | @jzabala Let me know if you think differently 😊

[ljharb]

The priority is to make sure the tests are good, it's not all that important what the implementation is as long as it passes them :-)

[iiison]

@ljharb | @jzabala Created the PR: #2769

Let me know if that works 😊

[burtek]

any progress on this? :)