Após algum tempo trabalhando como desenvolvedor React Native, percebi a tendência das pessoas em estruturarem as sua árvore de componentes com renders condicionais baseados em ifs ternários.

Por gostar muito de falar sobre legibilidade de código irei falar um pouco mais sobre o motivo pelo qual acredito que esta não seja a melhor abordagem na maioria dos cenários e quais as alternativas para uma melhor estruturação do código.

Lembrando que essa é uma opinião pessoal baseada em experiências prévias sobre o assunto. Quero que você tire as suas próprias conclusões adequando cada um dos cenários para a realidade de código dos seus projetos.

Chega de enrolação vamos direto ao ponto.

Vamos utilizar um fluxo onde verificaremos se o usuário é um admin e então fazer um render condicional em cima dessa variante, exibindo ou não uma funcionalidade em específico.

Com if ternário:

return user.isAdmin ? <AdminComponent /> : <DefaultUserComponent />;

Com if + return:

if (user.isAdmin) {
  return <AdminComponent />;
}
 
return <DefaultUserComponent />;

Em um primeiro momento parece uma boa ideia utilizar o if ternário já que é um desvio simples e bastante direto, porém, na prática nunca é tão simples assim. Neste caso, teríamos que, por exemplo, buscar os dados do usuário antes de exibí-los, com isso, faremos mais um desvio condicional para exibir um loader ou o conteúdo da página, dependendo do estado em que estamos.

Com if ternário:

return isGettingUserData ? (
  <Loader />
) : user.isAdmin ? (
  <AdminComponente />
) : (
  <DefaultUserComponent />
);

Com if + return:

if (isGettingUserData) {
  return <Loader />;
}
 
if (user.isAdmin) {
  return <AdminComponent />;
}
 
return <DefaultUserComponent />;

Aqui ja podemos ver que a abordagem com ifs ternários começou a ficar um pouco mais difícil de ser lida do que a anterior, além disso, não é possível simplesmente bater o olho e identificar todos os possíveis cenários de render desse fluxo. Agora vamos dizer que além das verificações já existentes você precisa verificar o tipo de admin que ele é e também se ele está autenticado ou não.

Com if ternário:

return !isAuthenticated ? (
  <LoginComponent />
) : isGettingUserData ? (
  <Loader />
) : user.isAdmin ? (
  user.isHigherLevelAdmin ? (
    <HigherLeverAdminComponent />
  ) : (
    <AdminComponent />
  )
) : (
  <DefaultUserComponent />
);

Com if + return:

if (!isAthenticated) {
  return <LoginComponente />;
}
 
if (isGettingUserData) {
  return <Loader />;
}
 
if (user.isAdmin) {
  if (user.isHigherLevelAdmin) {
    return <HigherLeverAdminComponent />;
  }
 
  return <AdminComponent />;
}
 
return <DefaultUserComponent />;

Neste ponto, o código com ifs ternários já se tornou complexo o suficiente para que toda vez que você bater o olho seja necessário pensar por alguns instantes o que está acontecendo, já o outro, apesar de ser mais verboso, deixa muito mais claras as intenções de cada um dos cenários e o fluxo de leitura do código é muito mais linear.

Agora imagine todos esses componentes recebendo diversas props, o que, na prática, é muito comum. A legibilidade e o custo para uma possível manutenção nesse código seriam bastante elevados.

Conclusão

O if ternário é uma ferramenta poderosa que pode nos ajudar muito no dia a dia como desenvolvedores, porém, eles necessitam do bom senso da nossa parte para serem utilizado de forma adequada.

Ao meu ver é a opção ideal para desvios simples, sem muita complexidade. Quando as coisas começam a ficar mais complexas ou extensas acabo sempre optando pela opção if + return por me entregar um código mais linear, limpo e de fácil entendimento e manutenção.

Eae, qual a sua opinião sobre esse padrão? Bora discutir sobre!