Elizabeth Holmes e React: quando a interface engana

Elizabeth Holmes pegou 135 meses de prisão por fraude, e a história dela voltou ao debate por causa de um documentário. O newsletter The Profile publicou um texto com um título direto: o documentário "You Can See Everything" engana. Eu não vou julgar o filme aqui. Vou falar do que me interessa como dev: Theranos é o maior caso que eu conheço de interface que prometia mais do que o sistema entregava. E quem escreve React toma esse tipo de decisão toda semana, em escala bem menor.

O que aconteceu com a Theranos?

Um resumo rápido, para quem chegou agora.

A Theranos prometia rodar centenas de exames com poucas gotas de sangue, numa máquina compacta. A empresa chegou a valer cerca de US$ 9 bilhões. Em 2015, John Carreyrou publicou no Wall Street Journal que a tecnologia não fazia o que a empresa dizia. Parte dos exames rodava em máquinas comerciais de outros fabricantes.

Em janeiro de 2022, um júri condenou Holmes por fraude contra investidores. A sentença saiu em novembro do mesmo ano. Depois disso, veio uma ordem de restituição de US$ 452 milhões, dividida com Sunny Balwani, ex-presidente da empresa.

O ponto que importa para este texto é outro. Segundo o livro Bad Blood, de Carreyrou, numa demonstração para a Novartis o aparelho falhou e a equipe mandou um resultado falso, de longe, para aparecer como se tivesse saído da máquina. Na tela, tudo funcionou.

Quem estava na sala viu um resultado. Ninguém viu de onde ele veio.

Por que isso importa para quem escreve React?

Calma, eu sei a diferença entre fraude e um skeleton na tela. Ninguém vai preso por causa de um useState. Holmes foi condenada por mentir para investidores, com dinheiro e pacientes reais no meio. Comparar isso com um dashboard atrasado seria ridículo.

Mas o mecanismo técnico é parecido, e é por isso que vale olhar. A camada de apresentação não sabe se o dado é verdadeiro. Ela renderiza o que recebe. Um componente React desenha um número falso com a mesma tipografia bonita de um número real.

E o front-end é onde as pessoas formam a crença sobre o sistema. Seu cliente não lê o log do servidor. Seu gestor não abre a aba Network. Se a tela diz "salvo", a pessoa acredita que salvou.

Demo bonita só prova que a demo funciona.

Isso dá uma responsabilidade chata ao front-end: a tela precisa dizer o que realmente sabe, inclusive quando sabe pouco.

Onde a interface React mente sem você perceber

Quase nunca é má-fé. Costuma ser pressa, prazo e um mock que ficou.

O caso clássico é o dado de exemplo que sobrevive até a produção. Veja este trecho com TanStack Query:

const { data } = useQuery({
  queryKey: ['vendas'],
  queryFn: buscarVendas,
  initialData: vendasMock,
})

return <Total valor={data.total} />

Parece inofensivo. Só que initialData entra no cache como dado de verdade. Enquanto a busca não termina, ou se ela falhar, o usuário vê R$ 48.320,00 de um arquivo que alguém escreveu numa tarde de março. Nada na tela avisa.

Se você quer mesmo mostrar algo provisório, use placeholderData e deixe isso visível:

const { data, isPlaceholderData, isError } = useQuery({
  queryKey: ['vendas'],
  queryFn: buscarVendas,
  placeholderData: vendasMock,
})

if (isError) return <ErroVendas />

return <Total valor={data?.total} provisorio={isPlaceholderData} />

São três linhas a mais, e a tela passa a ter três estados honestos em vez de um só muito confiante.

Outros lugares onde vejo isso acontecer:

• catch que devolve array vazio. A API caiu e a tela diz "nenhum pedido encontrado". O usuário conclui que não tem pedido. É uma informação falsa, com boa aparência.
• Toast de sucesso antes da resposta. O botão dispara o fetch e o toast aparece na mesma linha. Se o servidor devolver 500, o aviso de sucesso já foi embora.
• Barra de progresso de mentira. Um setInterval que sobe até 90% e espera. Todo mundo já fez, inclusive eu. Em upload de 3 segundos, tudo bem. Em processamento de 10 minutos, vira promessa sem lastro.
• Status sem data. "Sistema operacional" com um verde fixo no código. Se ninguém mede, esse verde é decoração.

useOptimistic também é mentira?

Essa é a objeção boa. O React 19 trouxe useOptimistic, um hook feito para mostrar o resultado antes de ele existir. Isso não é justamente o problema?

Na minha visão, não. A diferença é que a suposição tem prazo e tem saída:

const [curtidas, somarOtimista] = useOptimistic(
  post.curtidas,
  (atual, delta: number) => atual + delta,
)

function curtir() {
  startTransition(async () => {
    somarOtimista(1)
    await curtirPost(post.id)
  })
}

Quando a transição termina, o valor volta a ser o que veio do estado real. Se a chamada falhar e post.curtidas não mudar, o número retorna ao anterior. Você ainda precisa tratar o erro e avisar o usuário, mas a arquitetura já parte da ideia de que a tela pode estar errada por um instante.

A régua que eu uso é o custo do erro. Curtida otimista? Pode. Se falhar, ninguém perde nada. Pagamento, exame, transferência, envio de nota fiscal? Espere a confirmação do servidor. O usuário aguenta um spinner de 2 segundos. Não aguenta descobrir no dia seguinte que o boleto nunca foi gerado.

O que muda no seu fluxo de trabalho

Nada disso exige biblioteca nova. Exige hábito.

Modele os estados de propósito. Todo componente que depende de rede tem pelo menos carregando, erro, vazio e sucesso. "Vazio" e "erro" são coisas diferentes, e a tela precisa tratá-las de forma diferente.

Trave os mocks no ambiente de desenvolvimento. Se o mock nunca precisa ir para produção, faça o build falhar quando ele aparecer. O MSW ajuda bastante aqui: os dados falsos ficam na camada de rede, fora dos componentes, e você só liga o worker em desenvolvimento.

Demo com dado falso precisa dizer que é falso. Uma faixa "dados de exemplo" no topo resolve. Protótipo no Figma ninguém confunde com produto. Protótipo em React, com deploy e domínio bonito, confunde todo mundo, inclusive o diretor que vai prometer aquilo para um cliente na sexta.

Mostre a idade do dado. Um "atualizado há 4 minutos" custa uma linha e muda a leitura de qualquer painel. O TanStack Query já entrega dataUpdatedAt de graça.

Teste o caminho ruim. Abra o DevTools, coloque a rede em offline e clique em tudo. Faça um teste com a API devolvendo 500. Se a tela continuar sorrindo, você achou um bug.

A pergunta que eu faço antes do deploy

A Theranos é um caso extremo, com pessoas reais recebendo resultados de exame nos quais não podiam confiar. Ninguém aqui está nesse nível, e nem precisa estar para aprender com ela.

Minha opinião: front-end sênior é quem se preocupa com o que a tela afirma, além de como ela aparece. Antes de subir, eu pergunto: "se esse número estiver errado, a interface me deixaria perceber?". Se a resposta for não, volto para o código.

É esse o critério que tento seguir nos meus trabalhos. Se quiser ver como isso fica em produto de verdade, dá uma olhada nos meus projetos.

Elizabeth Holmes pegou 135 meses de prisão, e a Theranos me ensinou algo sobre React.

Segundo o livro Bad Blood, quando o aparelho falhou numa demo, um resultado falso foi enviado de longe para parecer que saiu da máquina. Na tela, tudo funcionou.

Calma, eu sei a diferença entre fraude e um skeleton. Mas o mecanismo é parecido: um componente desenha um número falso com a mesma tipografia bonita de um número real.

Um mock que sobrevive até produção. Um catch que devolve array vazio e diz "nenhum pedido encontrado" quando a API caiu. Um toast de sucesso antes da resposta do servidor.

Quase nunca é má-fé. É pressa. Mas seu cliente não abre a aba Network: se a tela diz "salvo", ele acredita.

Antes de cada deploy, eu me pergunto: se esse número estiver errado, a interface me deixaria perceber?

Escrevi sobre isso no blog, com código e os hábitos que adotei. E você, já achou uma tela mentindo no seu projeto?

#React #Frontend #JavaScript #DesenvolvimentoDeSoftware #Theranos