Existe um momento crítico em todo projeto front-end que pouca gente percebe. Não é o deploy. Não é o primeiro bug em produção. É antes disso.

É quando as decisões de arquitetura estão sendo tomadas — muitas vezes sem muita reflexão — e vão determinar se o sistema será estável, escalável… ou um campo minado de problemas difíceis de resolver.

Com o React moderno, esse momento ficou ainda mais importante, porque o nível de abstração aumentou, mas também aumentaram os riscos de decisões erradas.

Este artigo é um checklist direto e prático com 10 decisões arquiteturais que você deveria validar antes do primeiro deploy, especialmente se quiser evitar bugs invisíveis e dores futuras.

1. Você separou corretamente Server State e Client State?

Misturar esses dois tipos de estado é um dos erros mais comuns e mais caros no longo prazo. Quando dados de API são tratados como estado local simples, você perde controle de cache, sincronização e revalidação, o que leva a inconsistências e retrabalho.

Abordagem recomendada

// server state com React Query
import { useQuery } from '@tanstack/react-query';

function Users() {
  const { data, isLoading } = useQuery({
    queryKey: ['users'],
    queryFn: () => fetch('/api/users').then(res => res.json()),
  });

  if (isLoading) return <p>Carregando...</p>;

  return data.map(user => <p key={user.id}>{user.name}</p>);
}

Aqui você deixa claro que esse dado vem do servidor e precisa de tratamento específico.

2. Seu app tem estratégia de cache e invalidação?

Sem cache bem definido, seu sistema pode parecer lento, inconsistente ou ambos. O problema geralmente aparece quando múltiplas telas dependem dos mesmos dados e não existe uma estratégia clara de atualização.

Exemplo de invalidação

import { useMutation, useQueryClient } from '@tanstack/react-query';

function useUpdateUser() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (user) =>
      fetch(`/api/users/${user.id}`, {
        method: 'PUT',
        body: JSON.stringify(user),
      }),
    onSuccess: () => {
      queryClient.invalidateQueries(['users']);
    },
  });
}

Sem isso, você inevitavelmente terá dados desatualizados na UI.

3. Você definiu limites claros para renderização com Suspense?

Suspense é poderoso, mas sem estratégia vira gargalo de UX. Se você envolver toda a aplicação em um único boundary, qualquer carregamento bloqueia tudo.

Abordagem recomendada

<Suspense fallback={<p>Carregando perfil...</p>}>
  <UserProfile />
</Suspense>

<Suspense fallback={<p>Carregando pedidos...</p>}>
  <UserOrders />
</Suspense>

Isso permite carregamento progressivo e melhora a percepção de performance.

4. Seu código está preparado para concorrência?

No React moderno, você não pode assumir execução linear ou síncrona. Isso afeta desde requisições até atualização de estado.

Exemplo seguro

setCount((prev) => prev + 1);

Em vez de:

setCount(count + 1);

Essa pequena decisão evita bugs difíceis em cenários concorrentes.

5. Você isolou efeitos colaterais corretamente?

Efeitos mal posicionados são fonte de bugs silenciosos. Qualquer lógica que interage com o mundo externo precisa estar protegida contra múltiplas execuções.

Exemplo correto

useEffect(() => {
  const controller = new AbortController();

  fetch('/api/data', { signal: controller.signal });

  return () => controller.abort();
}, []);

Isso evita vazamento de memória e condições de corrida.

6. Seu app está preparado para SSR (ou evita problemas de hidratação)?

Se você usa Next.js ou qualquer SSR, precisa garantir que o HTML do servidor e do cliente sejam consistentes.

Anti-pattern

const value = Math.random();

Correto

const [value, setValue] = useState(null);

useEffect(() => {
  setValue(Math.random());
}, []);

Isso evita erros de hidratação e inconsistências visuais.

7. Você controla re-renderizações desnecessárias?

Re-renderizações excessivas não quebram o sistema, mas degradam a experiência e aumentam custo computacional.

Exemplo

const handleClick = useCallback(() => {
  setCount((c) => c + 1);
}, []);

Isso evita recriação de funções a cada render.

8. Seu projeto tem uma estratégia de divisão de código (code splitting)?

Carregar tudo de uma vez não escala. Mas dividir demais também pode prejudicar.

Exemplo equilibrado

const Dashboard = lazy(() => import('./Dashboard'));

<Suspense fallback={<p>Carregando...</p>}>
  <Dashboard />
</Suspense>

O ideal é dividir por domínio ou rota, não por micro-componentes.

9. Você definiu claramente o que roda no cliente vs servidor?

Com Server Components, essa decisão virou essencial.

Exemplo

// Server Component
export default async function Page() {
  const data = await fetch('https://api.com/data').then(res => res.json());

  return <List data={data} />;
}

// Client Component
'use client';

export function List({ data }) {
  return data.map(item => <p key={item.id}>{item.name}</p>);
}

Separar bem essas responsabilidades reduz bundle e melhora performance.

10. Seus testes cobrem fluxos críticos (e não só componentes)?

Testes isolados não garantem comportamento do sistema. Você precisa validar fluxos reais.

Exemplo

test('usuário completa fluxo de compra', async () => {
  render(<Checkout />);

  await userEvent.click(screen.getByText('Comprar'));

  expect(await screen.findByText('Pedido confirmado')).toBeInTheDocument();
});

Isso garante que o sistema funciona como esperado.

O padrão por trás de tudo isso

Se você observar bem, todas essas decisões têm algo em comum: elas forçam você a pensar no sistema como um todo, e não apenas em componentes isolados.

Arquitetura não é sobre tecnologia.

É sobre evitar problemas antes que eles existam.

Conclusão: bugs não nascem no deploy

Eles nascem nas decisões iniciais. Cada escolha que você faz no começo define como o sistema escala, define onde os bugs vão aparecer e define o custo de manutenção.

Se você valida esse checklist antes do primeiro deploy, você não elimina todos os problemas. Mas elimina os mais caros. E isso é o que separa código funcional de sistema robusto.