Ternary Operator - Is there a possible bug in React's conditional rendering?

Question

Currently, I am developing with Node.js and React and got a strange problem where I am not sure if I am missing something or if it is a bug on React's side.

What I want to do is to use the ternary operator to render conditional HTML like this:

...
{
  missingTradingSystemNameError
  ?
    <div>
      ...
    </div>
  :
    duplicateTradingSystemNameError
    ?
      <div>
        ...
      </div>
    :
      null
}
...

Both ternary operator conditions are stateful variables in my JSX.Element function. However, doing it like that leads to multiple errors in the following form:

Error:

React Hook "React.useEffect" is called conditionally. React Hooks must be called in the exact same order in every component render

Funny enough, if I add a third (useless) nested condition in place of null , then everything is working as intended:

...
{
  missingTradingSystemNameError
  ?
    <div>
      ...
    </div>
  :
    duplicateTradingSystemNameError
    ?
      <div>
        ...
      </div>
    :
      <<condition3>>
      ?
        null
      :
        null
}
...

condition3 is a third stateful variable, but as you can see the additional condition does nothing and it should therefore be possible to omit it. Is this a React bug or am I missing something crucial here?

(PS: Please forgive me the code's unusual indentation but for me this is currently the most readable solution to more complex JSX code blocks)

Edit 1:

To provide some further requested details, here is my simplified useEffect() code block:

const [missingTradingSystemNameError, setMissingTradingSystemNameError] = React.useState(false);
const [duplicateTradingSystemNameError, setDuplicateTradingSystemNameError] = React.useState(false);

...

React.useEffect(() => {
    if (props.tradingSystemDialog && resetTradingSystemDialogOnNextOpen) {
      ...
      
      setMissingTradingSystemNameError(false);
      setDuplicateTradingSystemNameError(false);
      
      ...
    }
  }, [
    props.tradingSystemDialog,
    resetTradingSystemDialogOnNextOpen,
    tickFields,
    consolidatedFields
  ]);

missingTradingSystemNameError is set via setMissingTradingSystemNameError and duplicateTradingSystemNameError is set via setDuplicateTradingSystemNameError . As you can see, these stateful variables are potentially altered in useState() but they are not in the dependencies of useState().

Answer 1

Providing a minimal reproducible example would be the best, but the context is too complex in my case. However, what I did is to remove more and more code to examine if one small part is causing the issue. Now I came to the conclusion that the following code snippet at some other location in the file is problematic and causes the mentioned code to fail or at least behave in a strange way:

...
{
  basicShortSettingsError
  ?
    <div className={classes.error}>
      <ErrorOutline
        className={classes.errorIcon}
      />
      <Typography className={classes.sectionError} variant="body2">
        {
          parseFloat(positionSizeShort) > parseFloat(maxContractsShort)
          ?
            "Position size > maximum contracts"
          :
            "Set position size and maximum contracts"
        }
      </Typography>
    </div>
  :
    null
}
...

For some reason, the conditional part inside the Typography tag worked before but is now causing errors if I extend the code at some other point in the file by the content which I mentioned in the question.

To clarify, this is the code snippet causing problems:

<Typography className={classes.sectionError} variant="body2">
  {
    parseFloat(positionSizeShort) > parseFloat(maxContractsShort)
    ?
      "Position size > maximum contracts"
    :
      "Set position size and maximum contracts"
  }
</Typography>

positionSizeShort and maxContractsShort are also stateful variables and I am not sure why the code was working just fine before and is now failing, but at least I have found the problem's root now where I can probably do a workaround.

If anyone has a better idea why exactly this code is problematic, it is more than welcomed to share your thoughts here as I have no real answer for my issue.