10 Truques de React ‘Ilegais’ que Funcionam

Hacks, atalhos e ‘truques de mágica’ que desenvolvedores React utilizam secretamente, mas que poucos admitem abertamente.

É preciso ser realista: escrever em React é como estar em um relacionamento interminável com alguém que constantemente muda seu penteado.

Em uma semana, há quem preconize o uso de hooks. Na semana seguinte, são os server components.

E, no entanto, eles funcionam. E eles poupam horas da vida de um desenvolvedor.

A Demandei irá abordar dez desses truques.

Basta envolver a operação em um setTimeout.

setTimeout(() => setState(newValue), 0);

Parece errado. Funciona lindamente.

Isso força o React a se acalmar e lidar com a atualização fora do seu ciclo de batching.

Mas, às vezes, o desenvolvedor precisa de um efeito colateral para rodar uma única vez e nunca mais.

useEffect(() => {
  doSomethingOnce();
}, []);

Claro, o linter irá reclamar.

A regra de ouro do React: “Hooks não podem ser condicionais.”

Mas, às vezes, o desenvolvedor simplesmente… precisa que sejam.

O truque é este: elevá-los e retornar cedo.

if (!enabled) return null;
const value = useHook();

Não se está “condicionalmente” chamando um hook. Apenas se está renderizando condicionalmente.

Uma grande diferença. A “polícia” do React pode se acalmar.

Sim, é possível definir um componente dentro de outro componente.

Isso é bom para o desempenho? Não.

Isso mantém o código do projeto legível em alguns casos? Absolutamente.

function Parent() {
  function Child() {
    return <p>I live inside Parent!</p>;
  }
  return <Child />;
}

Parece um conjunto de bonecas russas.

A documentação do React informa que o estado deve ser “serializável”. Fofo.

Na prática, é possível adicionar qualquer coisa ali.

const [fn, setFn] = useState(() => () => console.log("magic"));

Não é ilegal.

É eficiente quando são necessários callbacks ou closures dinâmicos.

Para reiniciar um componente sem escrever uma função de reset completa?

Basta aplicar um novo key nele.

<Component key={resetId} />

Ao alterar resetId, o React reinicia e remonta o componente.

Reset de fábrica instantâneo.

Todos dizem: “Não é possível ler o estado atualizado logo após o setState.” Mentira.

É possível, se o desenvolvedor usar refs.

const ref = useRef(value);
setValue(newValue);
ref.current = newValue;
console.log(ref.current);

Refs: os códigos de trapaça do React.

É necessária persistência sem uma biblioteca de gerenciamento de estado inchada?

const [theme, setTheme] = useState(() => localStorage.getItem("theme") || "light");

useEffect(() => {
  localStorage.setItem("theme", theme);
}, [theme]);

É rápido, “sujo” e funciona em 99% dos casos reais.

Sim, o nome é assustador.

Mas se o profissional controla a fonte, é seguro.

<div dangerouslySetInnerHTML={{ __html: "<b>Safe</b> text" }} />

Não se deve buscar conteúdo de APIs duvidosas. Mas se for o próprio HTML da aplicação, o desenvolvedor estará seguro.

Não é mágica negra, é apenas a forma do React de dizer: “Ei, não culpe a ferramenta se um malware for colado.”

Às vezes, useState se transforma em “código espaguete”.

É quando o desenvolvedor utiliza useReducer como uma jogada estratégica.

function reducer(state, action) {
  switch (action.type) {
    case "add": return state + 1;
    default: return state;
  }
}
const [count, dispatch] = useReducer(reducer, 0);

Até que o componente não entra em colapso sob o caos de estado. Então parece que se está “trapaceando”.

Estas são “melhores práticas”? Não.

Mas são “práticas reais”? Absolutamente.

E quanto aos desenvolvedores?

Possuem truques de React que parecem ilegais, mas trazem satisfação toda vez que são usados?

Podem ser compartilhados nos comentários. A Demandei gostaria de conhecer as “artes sombrias” que os profissionais têm escondido.