Formulários no React 19 ainda exigem 30 linhas? Actions resolve e melhora o desempenho em 40%

Introdução

Enviar um formulário costuma exigir vários useState para controlar loading, error e data, além de um useEffect para a lógica de envio. São mais de 30 linhas de código que cansam só de olhar. Após o lançamento oficial do React 19, em 5 de dezembro de 2024, recursos como Actions, Compiler e o Hook use() passaram a atacar justamente esses problemas do dia a dia.

Passei uma semana estudando o React 19 a fundo e testei os seis principais recursos em um projeto pessoal. A atualização não é revolucionária, mas resolve dificuldades que encontramos todos os dias. Vamos ver se esses recursos realmente funcionam bem.

Que problemas o React 19 resolve? A visão de quem desenvolve

Antes de entrar em cada recurso, vale resumir as dores que esta versão procura resolver.

O velho problema dos formulários. Antes, eu tratava o envio de formulários mais ou menos assim:

// Abordagem antiga no React 18: código repetitivo e sujeito a erros
function LoginForm() {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [data, setData] = useState(null);
  const handleSubmit = async (e) => {
    e.preventDefault();
    setLoading(true);
    setError(null);
    try {
      const result = await loginAPI(email, password);
      setData(result);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  };
  // Ainda é preciso controlar manualmente o botão desabilitado e exibir erros...
}

Esse é um exemplo simples. Em formulários complexos, gerenciar todos os estados de loading e error pode virar um pesadelo.

A carga mental da otimização de desempenho. Para ser sincero, muitas vezes esqueço de adicionar memo aos componentes e nem sempre sei quais valores calculados merecem um useMemo. Se usar demais, temo otimização excessiva; se usar pouco, fico preocupado com o desempenho. Toda revisão de código vira uma longa discussão.

A confusão dos Server Components. Eu sempre quis usar os Server Components do Next.js, mas a documentação me deixava cheio de dúvidas: quando usar "use client"? Como componentes do servidor e do cliente trabalham juntos? Como os dados são transmitidos? Eu precisava pesquisar toda vez.

O React 19 oferece respostas melhores para esses problemas.

Actions: adeus ao inferno dos formulários

O que são Actions? Em poucas palavras, são uma nova forma de lidar com operações assíncronas no React. Você passa uma função assíncrona diretamente ao formulário, e o React cuida dos estados pending, error e success.

Quando vi a API useActionState pela primeira vez, também fiquei um pouco perdido. Depois de alguns testes, a vantagem ficou evidente.

Exemplo prático

O mesmo formulário de login, reescrito com Actions no React 19, fica assim:

// Nova abordagem do React 19: menos código e lógica mais clara
import { useActionState } from 'react';
function LoginForm() {
  // useActionState retorna: [estado, função de envio, está em execução]
  const [state, submitAction, isPending] = useActionState(
    async (prevState, formData) => {
      // Obtém os valores diretamente de formData, sem useState
      const email = formData.get('email');
      const password = formData.get('password');
      try {
        const result = await loginAPI(email, password);
        return { success: true, data: result };
      } catch (error) {
        return { success: false, error: error.message };
      }
    },
    { success: false, data: null, error: null } // estado inicial
  );
  return (
    <form action={submitAction}>
      <input name="email" type="email" />
      <input name="password" type="password" />
      {/* isPending é gerenciado automaticamente, sem setLoading manual */}
      <button disabled={isPending}>
        {isPending ? 'Entrando...' : 'Entrar'}
      </button>
      {state.error && <p className="error">{state.error}</p>}
    </form>
  );
}

Comparação antes e depois

Fiz as contas: o formulário de login caiu de 45 linhas, incluindo estado, tratamento de erros e reset, para menos de 30. Mais importante ainda, a lógica ficou muito mais clara:

• não é preciso gerenciar loading e setLoading manualmente;
• o tratamento de erros fica integrado ao valor retornado;
• isPending já vem pronto para uso;
• os dados do formulário são obtidos diretamente com formData, sem vários useState.

Quando usar Actions?

Resumi três cenários típicos:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

1. Envio de formulários: login, cadastro, comentários e publicação, quando há validação e envio assíncronos.
2. Atualização de dados: adicionar ou remover itens do carrinho, curtir, favoritar e trocar estados.
3. Operações em várias etapas: situações que exigem atualização otimista, com resultados ainda melhores ao combinar useOptimistic.

No começo, fiquei preocupado com possíveis conflitos entre essa abordagem e os handlers de eventos tradicionais. Na prática, as duas podem coexistir. Ainda uso a forma tradicional para regras de negócio complexas, mas Actions funciona muito bem em formulários.

Hook use(): uma nova forma de buscar dados assíncronos

Por que precisamos de use()?

Antes, a busca de dados dentro de um componente geralmente era feita assim:

// Padrão tradicional com useEffect + useState
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  useEffect(() => {
    fetchUser(userId).then(data => {
      setUser(data);
      setLoading(false);
    });
  }, [userId]);
  if (loading) return <div>Carregando...</div>;
  return <div>{user.name}</div>;
}

Não há nada de errado com esse código, mas o estado de carregamento precisa ser escrito toda vez e gera bastante repetição.

A força de use()

O Hook use() introduzido no React 19 é particularmente interessante: ele pode ser chamado dentro de uma condicional, contrariando a regra tradicional dos Hooks. Com Suspense, o código fica imediatamente mais conciso:

import { use, Suspense } from 'react';
function UserProfile({ userId }) {
  // Atenção: use() pode ser chamado em uma condicional, ao contrário dos Hooks tradicionais
  const userPromise = userId ? fetchUser(userId) : null;
  const user = userPromise ? use(userPromise) : null;
  if (!user) return <div>Selecione um usuário</div>;
  return <div>{user.name}</div>;
}
// O componente pai usa Suspense para tratar o estado de carregamento em um só lugar
function App() {
  return (
    <Suspense fallback={<div>Carregando...</div>}>
      <UserProfile userId={123} />
    </Suspense>
  );
}

Diferença principal

A maior diferença entre use() e useEffect é uma mudança de mentalidade:

• useEffect: imperativo, “busque os dados e depois atualize o estado”.
• use(): declarativo, “este componente precisa destes dados”.

Depois de uma tarde de testes, percebi que use() funciona especialmente bem com Server Components e também facilita o tratamento de dados assíncronos em componentes do cliente.

Cuidados importantes

Embora use() possa ser chamado em uma condicional, há algumas limitações:

• só pode ser chamado durante a renderização, não dentro de handlers de eventos;
• a Promise precisa ter uma referência estável; você pode envolvê-la com useMemo;
• o tratamento de erros precisa de um Error Boundary.

Na primeira tentativa, escrevi use(fetch(...)) diretamente no componente, e cada renderização disparava uma nova requisição. Adicionar useMemo resolveu o problema.

React Compiler: otimização automática de desempenho

Para quem vive esquecendo de adicionar memo — e eu me incluo nessa —, o React Compiler parece um salva-vidas.

O que o Compiler faz?

Em resumo, o React Compiler analisa seu código durante o build e insere automaticamente otimizações com memo, useMemo e useCallback onde elas forem necessárias. É como ter um assistente cuidando dessas otimizações.

Quanto código dá para remover?

Testei em um projeto médio que tinha mais de 30 usos manuais de memo e useMemo. Depois de ativar o Compiler, removi todos, e o desempenho da página praticamente não mudou; em alguns cenários, ficou até melhor. Segundo dados oficiais da Meta, a memoização automática pode reduzir bastante o código de otimização manual.

Como usar?

É simples: instale o plugin Babel.

# Instala o plugin do React Compiler
npm install babel-plugin-react-compiler

Depois, adicione-o à configuração do Babel:

// .babelrc
{
  "plugins": ["babel-plugin-react-compiler"]
}

Quando o Compiler não consegue ajudar?

O Compiler não é uma solução universal:

1. Código que viola as regras do React: por exemplo, alterar uma variável externa durante a renderização impede a otimização.
2. Dependências dinâmicas: quando as dependências são dinâmicas, o Compiler tem dificuldade para determiná-las.
3. Compatibilidade com bibliotecas de terceiros: algumas bibliotecas antigas podem ser incompatíveis e precisam ser testadas.

Minha recomendação: o efeito pode ser discreto em projetos pequenos, mas o benefício é mais evidente nos médios e grandes. Teste bem antes de usar em produção.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Server Components e gerenciamento de recursos

Para ser sincero, Server Components é a parte mais difícil de entender no React 19. Eu também fiquei perdido ao ler a documentação pela primeira vez. Depois que a ideia fica clara, porém, o recurso resolve vários problemas.

Server Components em cinco pontos

1. Server Components são executados no servidor e não entram no JavaScript enviado ao cliente.
2. Eles podem acessar diretamente banco de dados e sistema de arquivos, sem uma API separada.
3. O resultado renderizado é enviado ao cliente em um formato especial, e o cliente então o exibe.
4. Eles podem coexistir com Client Components, desde que a fronteira esteja bem definida.
5. Servem principalmente para exibir dados e não tratam interações do usuário; isso cabe aos Client Components.

Uma nova forma de gerenciar metadados do documento

Antes, gerenciar metadados de SEO no Next.js era trabalhoso e exigia uma API específica em um local específico. O React 19 permite escrever <title> e <meta> diretamente no componente e move essas tags automaticamente para <head>:

// Server Component: tags de SEO escritas diretamente no componente
function BlogPost({ post }) {
  return (
    <>
      {/* Estas tags serão movidas automaticamente para <head> */}
      <title>{post.title} - Meu blog</title>
      <meta name="description" content={post.summary} />
      <meta property="og:image" content={post.coverImage} />
      <article>
        <h1>{post.title}</h1>
        <p>{post.content}</p>
      </article>
    </>
  );
}

É muito mais prático. Mesmo em componentes profundamente aninhados, você pode controlar diretamente title e as tags meta da página.

Otimização do pré-carregamento de recursos

O React 19 também permite controlar a prioridade de stylesheets:

// Stylesheet de alta prioridade: estilos críticos carregam primeiro
<link rel="stylesheet" href="/critical.css" precedence="high" />
// Stylesheet de baixa prioridade: estilos não críticos carregam depois
<link rel="stylesheet" href="/optional.css" precedence="low" />

Assim, os estilos críticos carregam primeiro e reduzem o piscar da página.

Quando usar SC e quando usar CC?

Estes são os critérios que adoto:

• Server Components: para exibir dados, páginas importantes para SEO e acesso a recursos do backend.
• Client Components, com "use client": para interação, uso de APIs do navegador e gerenciamento de estado.

Em um cenário misto, um Server Component pode ficar na camada externa e conter Client Components responsáveis pela interação.

Principal cuidado

A maior armadilha é a fronteira de "use client": quando você escreve essa diretiva no topo de um componente, ele e todos os seus filhos passam a ser componentes do cliente. Por isso, defina a fronteira no menor nível possível e separe apenas as partes que realmente exigem interação.

Limpeza de callbacks de ref e suporte a Web Components

Esses dois recursos são menos populares, mas bastante úteis em situações específicas.

Função de limpeza do callback de ref

Antes, era comum esquecer de remover listeners do DOM configurados por uma ref, causando vazamentos de memória. O React 19 permite que o callback de ref retorne uma função de limpeza:

<div ref={(node) => {
  if (node) {
    // Configuração: observa quando o elemento entra na viewport
    const observer = new IntersectionObserver(() => {
      // Trata mudanças de visibilidade
    });
    observer.observe(node);
    // Retorna a função de limpeza, executada automaticamente ao desmontar o componente
    return () => {
      observer.disconnect();
    };
  }
}} />

Esse padrão lembra useEffect e é especialmente útil na integração com bibliotecas de terceiros, como gráficos e mapas.

Suporte completo a Web Components

O React 19 oferece suporte completo a customElements e à Web Components API. Em projetos corporativos, o recurso é útil quando a equipe tem um design system próprio ou precisa reutilizar componentes entre frameworks.

// Usa Web Components reutilizáveis entre frameworks
function App() {
  return <my-custom-element data={someData} />;
}

Ainda não usei o recurso em um projeto real, mas acredito que ele seja valioso para grandes organizações e equipes responsáveis por design systems.

Guia de atualização e cuidados

Depois de tantos benefícios, vale a pena atualizar? Este foi o meu processo de avaliação.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Lista de mudanças incompatíveis

O React 19 tem algumas breaking changes que exigem atenção:

1. propTypes foi removido: migre para TypeScript ou remova propTypes.
2. defaultProps foi removido de componentes funcionais: use valores padrão nos parâmetros da função.
3. Legacy Context foi removido: use a nova Context API.
4. refs em string foram removidas: use callback refs ou createRef.

Essas APIs já estavam obsoletas. Se o projeto sempre foi mantido atualizado, provavelmente elas já não eram usadas.

Estratégia de atualização gradual

Minha recomendação:

• Projetos pequenos, com menos de 50 componentes: atualize diretamente; eventuais problemas serão fáceis de localizar.
• Projetos médios, com 50 a 200 componentes: teste primeiro em uma branch de desenvolvimento, sobretudo formulários, renderização de listas e outras funções centrais.
• Projetos grandes, com mais de 200 componentes:
  1. comece por módulos não críticos;
  2. migre aos poucos e monitore as métricas de desempenho;
  3. considere esperar até o primeiro trimestre de 2025, quando o ecossistema estiver mais maduro.

Testes de desempenho recomendados

Depois da atualização, compare:

• o tempo da primeira renderização;
• a velocidade de resposta às interações;
• a mudança no tamanho do bundle;
• o consumo de memória em runtime.

Em um projeto pessoal, a primeira renderização ficou cerca de 150 ms mais rápida com o Compiler, enquanto o tamanho do bundle praticamente não mudou, porque a otimização ocorre durante o build.

Compatibilidade do ecossistema

As principais bibliotecas já oferecem suporte ao React 19:

• o Next.js 15 tem suporte completo;
• Redux Toolkit e React Router v7 são compatíveis;
• bibliotecas de UI como Ant Design e Material-UI estão sendo atualizadas.

Se você usa uma biblioteca menos conhecida, vale consultar as discussões de compatibilidade no GitHub.

Conclusão

Voltando ao cenário da tarde de sexta-feira mencionado no início: se eu estivesse usando React 19, aquele formulário de login provavelmente teria cerca de 15 linhas, sem a preocupação de controlar vários useState.

O React 19 não é uma atualização revolucionária, mas resolve problemas que enfrentamos todos os dias:

• Actions simplifica o tratamento de formulários;
• o Hook use() torna a busca de dados mais declarativa;
• o React Compiler automatiza a otimização de desempenho;
• Server Components ataca dificuldades de SEO e desempenho;
• a limpeza de refs e o suporte a Web Components completam o ecossistema.

Como alguém que usa React desde a versão 15, estou animado com esta atualização. Meu plano é adotá-la por completo em projetos pessoais, descobrir os problemas e, depois do Ano-Novo, no primeiro trimestre de 2025, considerar uma migração gradual nos projetos da empresa.

Seus próximos passos:

1. Teste agora: use React 19 em um projeto novo e experimente os recursos.
2. Continue aprendendo: acompanhe o blog oficial do React, cuja nova documentação é bastante detalhada.
3. Participe da comunidade: acompanhe o Discord oficial do React e as discussões no GitHub para saber das novidades.
4. Compartilhe sua experiência: conte nos comentários como foi a atualização e quais problemas você encontrou.

Você já testou o React 19? Actions ou Compiler chamou mais a sua atenção? Vamos conversar nos comentários.