Eslint-plugin-react: jsx-curly-brace-presence ignores strings with "{" or "}" in the text

[chestozo]

I have this setup in .eslintrc

"react/jsx-curly-brace-presence": [
  "error",
  {
    "props": "never",
    "children": "ignore"
  }
]

in this case I get

<Box mb={'1rem'} />    // ERROR - all good here I expect this error
<Box mb={'1rem {}'} /> // NO ERROR - this looks like a bug (should be ERROR too)

[jzabala]

Hi @chestozo, from what I see your case is covered at the end of the edge cases in the rule docs.

The rationale is that in some cases it can make the code less readable:

With:

<style type="text/css">{'.main { margin-top: 0; }'}</style>;

Without:

<style type="text/css">'.main { margin-top: 0; }'</style>;

[ljharb]

In that latter case, that seems like it'd actually be invalid.

@chestozo the only way to have curly braces show up in your string is if they're encoded or in quotes; i think the rule is working as intended here.

[chestozo]

@ljharb

@chestozo the only way to have curly braces show up in your string is if they're encoded or in quotes; i think the rule is working as intended here.

would you agree that ' hello {name}' is a totally valid string that does not actually require

• encoding
• quoting
  ?

if yes this means it is still a bug ¯_(ツ)_/¯

[chestozo]

@jzabala not really
my case is for attribute contents not for children

[ljharb]

@chestozo I think that it seems like a programmer bug, which is why the linter rule should be forcing it to be a string inside jsx interpolation ({ }), or, to use HTML encoding - that way it's very explicit that it's intentional.

[chestozo]

@ljharb
it is not a bug at all
here is a life example of such a string when react-intl/FormattedMessage is used:

<FormattedMessage
  id='confirmAction.enterCodeMessage'
  defaultMessage='Enter code from {type}'
  values={{ type: 'email' }}
/>

the linter rule should be forcing it to be a string inside jsx interpolation

I do not understand this part - it is a string in any of this ways of writing it isn't it?:

defaultMessage='Enter code from {type}'
defaultMessage={'Enter code from {type}'}

[ljharb]

ahhh! I agree that in a prop value, you should not be getting a warning from this rule. Sorry I misunderstood your OP.

[jzabala]

ahhh! I agree that in a _prop value_, you should not be getting a warning from this rule. Sorry I misunderstood your OP.

Actually this rule has two tests that specifically guard agains this (disallowed JSX text characters):

https://github.com/yannickcr/eslint-plugin-react/blob/e3e767bd041988d9acb7713874c0632c68408347/tests/lib/rules/jsx-curly-brace-presence.js#L252

https://github.com/yannickcr/eslint-plugin-react/blob/e3e767bd041988d9acb7713874c0632c68408347/tests/lib/rules/jsx-curly-brace-presence.js#L248

Would them happen to be allowed values only on props?

[ljharb]

If the OP’s test cases pass, we can close the issue by adding them. Indeed if they’re prop values they should not be warned on.

[jzabala]

If the OP’s test cases pass, we can close the issue by adding them. Indeed if they’re prop values they should not be warned on.

I opened a PR with the changes and moved the tests.