Executando verificação de segurança...
4

Quando evitar usar "&&" para renderização condicional no React

Uma tradução do artigo de Jakub Kozak

Evite erros e bugs indesejados com uma simples mudança.

Conteúdo :

  • 1. Como o "&&" funciona
  • 2. Por que não usar "&&"
  • 3. O que usar ao invés do "&&"

Como o "&&" funciona ?

Um exemplo clássico em React :

function MyComponent({ condition }) {
  return (
    <div>
      <h1>Title</h1>
      {condition && <ConditionalComponent />}
    </div>
  );
}

Explicando resumidamente o código acima :

  • Se "condition" é um valor verdadeiro, ConditionalComponent é renderizado
  • Se "condition" é um valor falso, ConditionalComponent não é renderizado

Por que isso ? Não é nada específico do React, mas sim um comportamento do JavaScript e outras linguagens de programação chamado avaliação de curto-circuito ( pesquise também por operadores ternários caso nunca tenha visto uma sintaxe semelhante ). Ou seja, se o primeiro operando (condition) for falso, o operador AND (&&) para e não avalia o segundo operando (ConditionalComponent).

Você pode tentar isso em seu navegador executando o trecho de código abaixo no Console:

// Isso vai despertar uma caixa de alerta
true && alert('Hello');
// Isso não vai fazer nada
false && alert('Not hello');

Por que não usar "&&"?

A sintaxe curta de && geralmente é preferida e funciona. Mas! Só porque você pode não significa que você deve.

No nosso caso acima, se a condição for avaliada como verdadeira ou falsa, você obterá o que esperava — ConditionalComponent é ou não renderizado, respectivamente. Tudo bem até agora. No entanto, se a condição não for avaliada como booleana ( true ou false ), pode causar problemas.

  • Se condition é 0 , 0 é exibido na interface do usuário.
  • Se condition é undefined , iremos receber um belo de um erro "Uncaught Error: Error(...): Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null."

O que usar ao invés de "&&"

Para evitar mostrar algo que você não deseja na interface do usuário, como 0, que pode atrapalhar o layout, use o operador ternário do JavaScript. ou seja,

condition ? <ConditionalComponent /> : null;

Conclusão

Para evitar erros de interface do usuário, use o operador ternário JavaScript para renderização condicional de componentes React em vez do operador AND lógico. É um feitiço simples, mas inquebrável 🧙‍♂️

🔴 RUIM
condition && <ConditionalComponent />
🟢 BOM
condition ? <ConditionalComponent /> : null


Este foi um artigo de Jakub Kozak traduzido por Daniel Lima

Carregando publicação patrocinada...
5

No final o problema é tentar avaliar uma condiçao não booleana e não o fato mesmo de usar o &&

Esse tipo de erros podem ser evitados apenas usando o Boolean ou o dobro sinal de exclamação para garantir uma expressão booleana.

Exemplo:

Boolean(condition) && <Component/>
// ou
!!(condition) && <Component/>
2

Concordo, utilizar um ternário completo condition ? ... : null pode deixar o código mais difícil de ler, primeiro porquê ficaria mais verboso e segundo porquê utilizar o && é algo muito comun na comunidade react e é muito natural para lermos.

Gosto muito da ideia do:

!!condition && (
  <Component />
) 

Acho simples, clara e elegante!

1

Gostei muito dessa forma, vou começar a utilizar nos meus projetos.

Eu tenho utilizado o ternário para imprimir algo de acordo com a condição(por exempro, se o usuário está logado ou não), creio q essa forma no fim acaba fazendo sentido.

Mas se houver uma forma mais performática, aceito sugestões.

1

Sem nexo... se o problema for valor indefinido basta usar o !! para converter pra booleano, o operador && é o mais viável pra este tipo de situação., Utilizar ternário além de poluir seu código te obrigaria a retorna um else, entao não, não irei parar de usar &&

1

Opa, fala ae ! tranquilo ?
Javascript abre margem para contextos diferentes, você ainda forçaria condição para booleano, mesmo que propTypes ou TS digam que condição é do tipo booleano? Bem provável que não, mas condição pode ser de um tipo diferente de booleano quando vem de props. Por exemplo, quando condição é obtido da API e você não tem muito controle sobre o tipo obtido ou obtém um tipo diferente do esperado.

Se quiser ver mais sobre essa discussão e diferentes pontos de vista, recomendo que entre no primeiro artigo que listei no post e veja as reply/comments.
Mas,de qualquer forma, você é livre pra fazer o que desejar, weslley.