React 19

 (github.com/facebook)
2 pontos por GN⁺ 2024-12-06 | 1 comentários | Compartilhar no WhatsApp

19.0.0 (5 de dezembro de 2024)

Novos recursos

React
  • Actions: startTransition agora pode aceitar funções assíncronas. Essas funções são chamadas de "Actions" e atualizam o estado em segundo plano, fazendo o commit da UI de uma só vez. Actions podem executar efeitos colaterais, como requisições assíncronas, e aguardam a conclusão do trabalho antes de a Transition terminar.
  • useActionState: novo hook que permite ordenar Actions dentro de uma Transition e acessar o estado. Aceita um estado inicial e um reducer.
  • useOptimistic: novo hook para atualizar o estado enquanto uma Transition está em andamento. Quando a Transition termina, o estado é atualizado com o novo valor.
  • use: nova API para ler recursos durante a renderização. Aceita Promise ou Context e, quando uma Promise é fornecida, suspende até que o valor seja resolvido.
  • Uso de ref como prop: agora é possível usar ref como prop sem precisar de forwardRef.
  • Pré-aquecimento de irmãos do Suspense: quando um componente é suspenso, o React faz imediatamente o commit do fallback da fronteira de Suspense mais próxima.
Cliente React DOM
  • Prop action de <form>: Form Actions gerenciam o formulário automaticamente e se integram com useFormStatus. Em caso de sucesso, redefinem o formulário automaticamente.
  • Suporte a metadados de documento: agora é possível renderizar nativamente tags de metadados do documento a partir de componentes.
  • Suporte a stylesheets: insere stylesheets no <head> do cliente antes de revelar o conteúdo da fronteira de Suspense.
  • Suporte a scripts assíncronos: agora é possível renderizar scripts assíncronos em qualquer lugar da árvore de componentes.
Servidor React DOM
  • Adição das APIs prerender e prerenderToNodeStream: APIs para geração de sites estáticos, projetadas para funcionar em ambientes de streaming, como streams do Node.js e Web Streams.
React Server Components
  • Recursos de RSC: diretivas, Server Components e Server Functions foram estabilizados. Bibliotecas que incluem Server Components agora podem ter o React 19 como dependência de mesmo nível.

Descontinuações planejadas

  • Acesso a element.ref: o acesso a element.ref foi descontinuado em favor de element.props.ref.
  • react-test-renderer: no React 19, react-test-renderer registra um aviso de descontinuação e muda para renderização concorrente para uso na web.

Principais mudanças

React
  • Nova transformação de JSX obrigatória: é necessária uma nova transformação de JSX para melhorar o tamanho do bundle e permitir o uso de JSX sem importar React.
  • Erros de renderização não são relançados: se um erro não for capturado por um Error Boundary, ele será reportado para window.reportError.
  • Remoção de propTypes: o uso de propTypes passa a ser silenciosamente ignorado. Recomenda-se migrar para TypeScript.
  • Remoção de defaultProps em funções: é possível usar parâmetros padrão do ES6 no lugar.
  • Remoção de refs de string: o uso de refs de string deve ser migrado para callbacks de ref.
React DOM
  • Remoção de react-dom/test-utils: act foi movido de react-dom/test-utils para react. Os outros utilitários foram removidos.
  • Remoção de ReactDOM.render e ReactDOM.hydrate: substituídos por ReactDOM.createRoot e ReactDOM.hydrateRoot para renderização concorrente.

Mudanças dignas de nota

React
  • Uso de <Context> como provider: agora é possível renderizar <Context> como provider em vez de <Context.Provider>.
  • Suporte a custom elements: o React 19 passa em todos os testes de custom elements.
  • Mudanças no StrictMode: useMemo e useCallback reutilizam o resultado memorizado da primeira renderização.
React DOM
  • Diff para erros de hidratação: quando há uma incompatibilidade, o React 19 registra um único erro incluindo o diff do conteúdo incompatível.

Mudanças no TypeScript

  • Retorno implícito proibido: refs agora aceitam apenas funções de limpeza. Retornos implícitos passam a gerar erro.
  • Argumento inicial obrigatório em useRef: o argumento inicial agora é obrigatório.
  • Tipagem mais estrita de ReactElement: as props dos elementos React agora usam unknown por padrão em vez de any.

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-06
Opiniões no Hacker News

  • Não entendo muito bem por que tanta gente aqui odeia React
    Comecei a carreira com Laravel e JS puro, mas depois que usei React, criar apps escaláveis passou a parecer algo realista, e o front-end também ficou divertido
    Mesmo mudando de empresa, é fácil retomar React, e com o suporte a TypeScript e o grande ecossistema, dá a sensação de que é relativamente fácil criar e fazer crescer praticamente qualquer coisa
    Também não entendo por que os novos recursos assustam as pessoas. Ainda dá para criar SPAs ou seguir o jeito antigo, parecido com quando surgiram bancos NoSQL, Spring Boot ou Kotlin: se não quisesse usar, era só não usar
    Eu achava que Jetpack Compose e SwiftUI também tinham sido inspirados no React; acho que vi isso antes na documentação do Android, mas agora não consigo encontrar
    Só que ainda não tenho décadas de experiência, então não sei o quão divertido era, para grandes equipes de antigamente, criar webapps enormes como o Airbnb com jQuery ou JS puro. Hoje ficou até difícil imaginar como resolver gerenciamento de estado, manipulação do DOM e efeitos colaterais em JS puro
    Talvez um dia eu também reclame de um framework novo e diga que React era bom

    • A antipatia contra React geralmente parece vir de pessoas que, na prática, não usaram muito a ferramenta, então não entendo bem
      Em geral, o argumento é algo como “o front-end está sempre correndo atrás da próxima novidade brilhante, e React é uma delas”, mas React existe desde 2013 e já era bem mainstream por volta de 2015
      Também dizem que frameworks e bibliotecas adicionam complexidade, mas quando se pergunta qual complexidade exatamente, quase nunca há resposta. Se você cria uma aplicação significativa sem framework, no fim acaba inventando seu próprio framework, com menos manutenção, testes e documentação
      Também reclamam bastante das etapas de compilação e bundling, mas hoje existem frameworks comprovados como Expo, Next.js e Meteor, então quase não há motivo para configurar webpack ou montar um pipeline de build por conta própria
    • A maioria dos sites nem precisa ser um app para começo de conversa. Alguns precisam, mas nesses casos normalmente é necessária uma solução sob medida
      A tendência de enfiar frameworks web em todo lugar produziu, nos últimos 10 anos, sites lentos e quebradiços, muitas vezes superprojetados e ainda assim sem melhorar muito a experiência de usuário de 2008
      Para alguns desenvolvedores front-end, seja qual for a pergunta, a resposta é alguma combinação de React / Node / Vite / Angular / Vue / Nuxt / Next / Bun / Deno / Svelte / SvelteKit e, se possível, rodando em dezenas de swarms Docker dominados por Kubernetes. É o tipo de coisa: “Quer colocar seu currículo online? Então vamos passar as próximas 3 semanas desenhando o fluxograma de estado do app”
      React parece levar mais pancada em especial porque quem seguia modas de frameworks já foi para a próxima coisa brilhante, e quem sempre detestou esse tipo de framework continuou detestando; então agora não sobrou ninguém para defender essa bagunça. Acho que os outros frameworks terão o mesmo destino com o tempo
    • Acho que o React da era das classes era um framework de UI ok, comum, sem graça, mas útil. Já os hooks são muito difíceis de usar
      Muito do funcionamento real fica escondido, não é intuitivo, é fácil cometer erros e também é fácil escrever UIs de baixo desempenho
      É preciso ficar pensando o tempo todo no que é executado quantas vezes, no que deve entrar no array de dependências, no que colocar em useCallback e em useEffect, o que aumenta bastante a carga cognitiva
      Parte da comunidade também recomenda dependências de React de que o projeto nem precisa, aumentando apenas o overhead e a complexidade
      Também é fácil misturar lógica de negócio com lógica de UI
    • jQuery desmoronava feio quando se começava a criar apps grandes e complexos. Acho que quem realmente viveu aquela época não sente saudade dela
      Por um tempo, SPAs tinham desvantagens em relação a MPAs, mas com os padrões web modernos e a adoção de renderização no servidor por frameworks SPA, esses problemas hoje estão praticamente resolvidos
    • Não é verdade que “ninguém reclamou quando bancos NoSQL surgiram”. Muitos de nós reclamamos bastante do quão ruim era o MongoDB
      https://www.youtube.com/watch?v=b2F-DItXtZs

  • É um lançamento excelente, mas também acho meio triste para quem está começando agora em desenvolvimento frontend
    Explicações como “um novo hook para ordenar Actions dentro de uma Transition e acessar o estado da action e o estado pending; ele recebe um reducer que pode chamar a Action e o estado inicial usado na primeira renderização, e também recebe uma string opcional para oferecer suporte ao aprimoramento progressivo do formulário quando passado para a prop form action” fazem o recurso parecer bom, mas são longas demais
    Se alguém fosse começar a desenvolver sites hoje, imagino que ficaria sem saber por onde começar
    Ainda assim, React continua sendo um framework excelente, e este lançamento também é uma melhoria. A crítica é menos ao React em si e mais ao desenvolvimento frontend como um todo

    • Se eu fosse dar uma dica, começaria evitando React por completo, se possível
      Renderização no servidor à moda antiga com algo como HTMX é muito melhor
      Ganhei dinheiro por 4 anos com desenvolvimento frontend em React e criei meu primeiro site em 2005; agora estou migrando um projeto de cliente de React para HTMX e acho muito melhor
      Há menos bugs e menos armadilhas causadas pelo uso incorreto de hooks
      Se eu precisasse de renderização no cliente, usaria Solid ou Vue, mas evitaria React. Se não houver escolha, boa sorte
    • Acho que React foi uma abordagem interessante, mas desde o começo havia sinais de alerta que foram ignorados
      A premissa básica de binding unidirecional, DOM virtual, rerenderização e cálculo de diferenças nunca me convenceu fundamentalmente. Isso significa usar o dobro de memória do navegador e fazer uma rerenderização completa com cálculo de diferenças a cada interação
      Na época, a resposta era “primeiro vamos tornar estável, depois vamos tornar rápido”, mas hoje está cheio de estruturas meio hackeadas para tentar tornar rápido, e não é nem rápido nem estável
      Um framework honesto de binding bidirecional pelo menos garante velocidade, e a estabilidade vem da experiência. React é simplesmente confuso. Tenho pena dos engenheiros cuja primeira entrada no frontend foi com React, porque desaprender e reaprender parece muito mais difícil do que aprender
      Como alguém que passou por VBScript, JS, jQuery, Mootools, Applets, ActionScript, YUI/Ext/Sencha, Backbone, Knockout, Angular 1, Angular 2, React e Vue 1, eu diria para experimentar Flutter. É realmente revigorante
      O problema é Dart. Se Flutter fosse TypeScript, estaria um pouco mais perto do ideal, mas Dart mantém vivo o espírito de churn infinito do frontend
    • Eu sinto exatamente o contrário. Quando comecei a usar React, ele mudava a cada poucas semanas; hoje a documentação e as APIs são muito mais estáveis e consistentes
      Os padrões web em geral também estão mais estáveis do que nunca. Desenvolvedores mais jovens não precisam aprender centenas de gambiarras de layout para fazer uma página aparecer corretamente em vários navegadores, e às vezes nem precisam de tantos hacks só para acomodar um único navegador
      Entendo a fadiga com JavaScript, mas acho que este é um dos melhores momentos para aprender
    • Fiz principalmente programação de baixo nível e, em geral, detestava meus pontos de contato com frontend web, mas alguns anos atrás peguei React para um projeto pessoal e fiquei bem surpreso
      Tudo parecia desenvolvimento de verdade e, comparado ao que havia antes, foi como uma lufada de ar fresco
    • Acho que começar é fácil. Basta não usar esses recursos opcionais
      Para 99% dos desenvolvedores, eles não serão necessários até que a aplicação cresça bastante, e talvez nunca sejam. React também não obriga ninguém a usá-los

  • Eu já gostei de frameworks client-side como React, mas no fim percebi que eles adicionaram complexidade em todos os lugares possíveis
    A complexidade entrou no backend, no frontend, na stack de DevOps, em todos os lugares, e mais camadas continuarão sendo adicionadas para sincronizar essa complexidade distribuída

    • Quando se passa de aplicações pequenas, frameworks frontend de fato tornam as coisas mais simples
      A UI ser rerenderizada automaticamente quando dados ou modelos mudam é a direção correta
      Dá para discutir os detalhes da abordagem, mas alterar a UI imperativamente sempre que os dados mudam é algo que dificilmente se sustenta por muito tempo em termos de base de código ou tamanho de equipe
    • React foi o motivo que me fez me afastar do frontend web
      Ele adicionou uma complexidade enorme para fazer o navegador renderizar caixas de um jeito para o qual ele não foi originalmente pensado, e, sob o pretexto de mudar o paradigma de programação, também houve uma grande perda de produtividade e de ferramental
      Havia ideias e implementações legais, mas não sei se valeram o custo. Às vezes penso se não foi uma espécie de mecanismo de estabilidade profissional
      Não é um problema exclusivo do ReactJS; o ecossistema JavaScript inteiro enlouqueceu com bibliotecas e ferramentas, mas React era especialmente irritante para começar, a ponto de surgir o create react app para finalmente permitir criar um app hello world em um tempo razoável
    • Acho que desenvolvimento de software financiado por venture capital é um programa de bem-estar social para pessoas inteligentes que também querem se divertir. Tudo bem
    • Gosto de React, mas as mudanças no React depois da v16.8, quando vieram os hooks, parecem exibicionismo técnico
      Parei de tentar entender a razão de transformar a API de componentes de classe em hooks
    • Também vale refletir se a complexidade foi algo que você mesmo adicionou
      Você poderia escolher um framework mais simples e também evitar orquestração no servidor
      Se não houver escolha, também pode iniciar seu próprio projeto acreditando que uma stack simples pode trazer uma vantagem de eficiência

  • Uma das melhores partes deste lançamento é que agora é possível usar ref como prop. forwardRef não é mais necessário

  • O post do blog é mais fácil de ler: https://react.dev/blog/2024/12/05/react-19

    • Não entendo por que updateName retorna um erro em const error = await updateName(newName);
      Não seria melhor simplesmente lançar um Error, como é típico em JS/TS?

  • Se, até agora, entre 45 comentários, “redux” foi mencionado 7 vezes, aqui eu gostaria de mencionar Jotai como representante da família do Recoil. Provavelmente ele já deve funcionar no React 19 sem nenhuma alteração separada
    Quando a complexidade do frontend cresce o suficiente, outras ferramentas de gerenciamento de estado muitas vezes acabam atrapalhando mais do que deveriam
    Se você passou a não gostar de React, mas na verdade está cansado da parede interminável de constantes de actions, do encanamento de props, da luta com providers/contexts aninhados e da fuga para pub-sub, vale a pena experimentar algo como Jotai

    • A equipe que criou o Jotai também criou Zustand e Valtio
      https://github.com/pmndrs/zustand
      https://github.com/pmndrs/valtio
      Jotai parece ter boilerplate manual demais, e Valtio tem muita “mágica” de proxy; pessoalmente eu até gosto, mas não tenho certeza se é uma boa escolha para uma equipe
      Zustand fica no meio-termo entre boilerplate e mágica, então foi a opção que escolhi para o grande projeto em que estou trabalhando agora
    • Não sei por que gerenciamento de estado tem tantos termos estranhos
      Quando comecei a trabalhar em apps React alguns anos atrás, todos os pacotes de gerenciamento de estado que vi eram cheios desses termos, e isso continua igual
      No fim, para escapar disso e focar no trabalho, criei minha própria solução [1], e ela funciona bem em produção. É uma pena não haver uma opção popular que funcione de forma parecida
      [1] https://github.com/facepunch/react-class-model
    • Mesmo olhando a página de documentação do Jotai no npm (https://www.npmjs.com/package/jotai), não fica claro para mim como ele ajuda a escapar do uso de vários context providers ou do Redux
      O bom dos context hooks é que eles são composáveis e, combinados com consultas em cache, permitem criar um padrão bastante manutenível
      Fico curioso para saber que melhoria prática o Jotai oferece aqui
    • Usei Jotai em um projeto relativamente grande e gostei bastante
      Espero de verdade nunca mais ter que lidar com redux ou sagas
    • Seria bom que todos experimentassem https://starfx.bower.sh. É uma nova abordagem para gerenciamento de estado e, mais importante, para gerenciamento de efeitos colaterais

  • Não gostei da maioria dos novos recursos introduzidos
    Actions e os hooks useActionState / useOptimistic parecem uma grande armadilha de complexidade. O nome do hook use é pouco informativo demais, e ele não lida com promises criadas dentro do componente
    Certamente há bons motivos, mas passar uma promise como prop e tratá-la com o hook use parece que vai criar mais complexidade do que as soluções de contorno atuais
    Server Components também parecem bastante complexos, e fico feliz por ainda não ter precisado lidar com eles
    A melhoria nas mensagens de erro de hydration é bem-vinda, e a mudança para usar provider e a mudança para usar ref como prop são boas melhorias de qualidade
    No geral, gosto de React/Preact para criar SPAs. Usando uma biblioteca de componentes rica em recursos como MUI junto com uma solução simples de gerenciamento de estado como Preact Signals, criar SPAs fica bem direto
    Mas me preocupa a complexidade ir se infiltrando aos poucos. Só de ler a descrição dos novos hooks nas notas de lançamento, já sinto uma carga cognitiva grande
    Por outro lado, o React Compiler é uma ferramenta absolutamente necessária. Como o programador não vai precisar escrever otimizações típicas diretamente dentro dos componentes, os componentes devem ficar menos complexos
    Estou ansioso pelo lançamento e pela integração com Vite e afins; pelo que ouvi, também haverá suporte a Preact

  • Seria bom mudar o nome da API use para algo diferente do prefixo comum dos hooks
    Acho que alguém começando agora com React hooks ficaria confuso ao ver que use pode ser chamado condicionalmente, mas hooks comuns não podem

  • Fico realmente feliz que tenham adiado o lançamento para resolver o problema de Suspense paralelo
    Ainda não experimentei, mas minhas expectativas são altas, e no geral é um ótimo lançamento

  • Última hora: suporte completo a custom elements. Ou seja, Web Components