From db3911795afce2ca76a5bf756dca4e102bc8858a Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 11:12:20 -0300 Subject: [PATCH 1/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 98 +++++++++---------- 1 file changed, 49 insertions(+), 49 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index aeb677f31..927c84ec7 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,17 +1,17 @@ --- -title: "React Labs: What We've Been Working On – March 2023" -author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, and Andrew Clark +title: "React Labs: No que temos trabalhado – Março de 2023" +author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark date: 2023/03/22 -description: In React Labs posts, we write about projects in active research and development. We've made significant progress on them since our last update, and we'd like to share what we learned. +description: Em posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- -March 22, 2023 by [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) +22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) --- -In React Labs posts, we write about projects in active research and development. We've made significant progress on them since our [last update](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022), and we'd like to share what we learned. +Em posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. @@ -19,87 +19,87 @@ In React Labs posts, we write about projects in active research and development. ## React Server Components {/*react-server-components*/} -React Server Components (or RSC) is a new application architecture designed by the React team. +React Server Components (ou RSC) é uma nova arquitetura de aplicação projetada pela equipe do React. -We've first shared our research on RSC in an [introductory talk](/blog/2020/12/21/data-fetching-with-react-server-components) and an [RFC](https://github.com/reactjs/rfcs/pull/188). To recap them, we are introducing a new kind of component--Server Components--that run ahead of time and are excluded from your JavaScript bundle. Server Components can run during the build, letting you read from the filesystem or fetch static content. They can also run on the server, letting you access your data layer without having to build an API. You can pass data by props from Server Components to the interactive Client Components in the browser. +Compartilhamos nossa pesquisa sobre RSC pela primeira vez em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente — Componentes de Servidor — que são executados antecipadamente e estão excluídos do seu pacote JavaScript. Componentes de Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem a necessidade de construir uma API. Você pode passar dados por props de Componentes de Servidor para os Componentes de Cliente interativos no navegador. -RSC combines the simple "request/response" mental model of server-centric Multi-Page Apps with the seamless interactivity of client-centric Single-Page Apps, giving you the best of both worlds. +RSC combina o simples modelo mental de "request/response" de Aplicações Multi-Páginas centradas no servidor com a interatividade contínua de Aplicações de Página Única centradas no cliente, oferecendo o melhor dos dois mundos. -Since our last update, we have merged the [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) to ratify the proposal. We resolved outstanding issues with the [React Server Module Conventions](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) proposal, and reached consensus with our partners to go with the `"use client"` convention. These documents also act as specification for what an RSC-compatible implementation should support. +Desde nossa última atualização, mesclamos o [RFC de Componentes de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta de [Convenções de Módulos de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e alcançamos um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificação do que uma implementação compatível com RSC deve suportar. -The biggest change is that we introduced [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) as the primary way to do data fetching from Server Components. We also plan to support data loading from the client by introducing a new Hook called `use` that unwraps Promises. Although we can't support `async / await` in arbitrary components in client-only apps, we plan to add support for it when you structure your client-only app similar to how RSC apps are structured. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal forma de fazer a busca de dados a partir de Componentes de Servidor. Também planejamos suportar o carregamento de dados a partir do cliente ao introduzir um novo Hook chamado `use`, que desvencilha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas de cliente, planejamos adicionar suporte a isso ao estruturar seu aplicativo apenas de cliente de forma semelhante à como os aplicativos RSC são estruturados. -Now that we have data fetching pretty well sorted, we're exploring the other direction: sending data from the client to the server, so that you can execute database mutations and implement forms. We're doing this by letting you pass Server Action functions across the server/client boundary, which the client can then call, providing seamless RPC. Server Actions also give you progressively enhanced forms before JavaScript loads. +Agora que temos a busca de dados bem resolvida, estamos explorando a outra direção: enviar dados do cliente para o servidor, de forma que você possa executar mutações em bancos de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ações de Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, fornecendo RPC contínuo. Ações de Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript carregue. -React Server Components has shipped in [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). This showcases a deep integration of a router that really buys into RSC as a primitive, but it's not the only way to build a RSC-compatible router and framework. There's a clear separation for features provided by the RSC spec and implementation. React Server Components is meant as a spec for components that work across compatible React frameworks. +Os Componentes de Servidor do React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatível com RSC. Há uma separação clara para os recursos fornecidos pela especificação RSC e a implementação. Componentes de Servidor do React destinam-se a ser uma especificação para componentes que funcionam em frameworks React compatíveis. -We generally recommend using an existing framework, but if you need to build your own custom framework, it is possible. Building your own RSC-compatible framework is not as easy as we'd like it to be, mainly due to the deep bundler integration needed. The current generation of bundlers are great for use on the client, but they weren't designed with first-class support for splitting a single module graph between the server and the client. This is why we're now partnering directly with bundler developers to get the primitives for RSC built-in. +Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos que fosse, principalmente devido à profunda integração necessária com o bundler. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos colaborando diretamente com desenvolvedores de bundler para obter os primitivos para RSC incorporados. -## Asset Loading {/*asset-loading*/} +## Carregamento de Ativos {/*asset-loading*/} -[Suspense](/reference/react/Suspense) lets you specify what to display on the screen while the data or code for your components is still being loaded. This lets your users progressively see more content while the page is loading as well as during the router navigations that load more data and code. However, from the user's perspective, data loading and rendering do not tell the whole story when considering whether new content is ready. By default, browsers load stylesheets, fonts, and images independently, which can lead to UI jumps and consecutive layout shifts. +[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está carregando, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, sob a perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na UI e sucessivas mudanças de layout. -We're working to fully integrate Suspense with the loading lifecycle of stylesheets, fonts, and images, so that React takes them into account to determine whether the content is ready to be displayed. Without any change to the way you author your React components, updates will behave in a more coherent and pleasing manner. As an optimization, we will also provide a manual way to preload assets like fonts directly from components. +Estamos trabalhando para integrar totalmente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os considere para determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na forma como você escreve seus componentes React, as atualizações se comportarão de uma maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. -We are currently implementing these features and will have more to share soon. +Atualmente estamos implementando esses recursos e teremos mais a compartilhar em breve. -## Document Metadata {/*document-metadata*/} +## Metadados do Documento {/*document-metadata*/} -Different pages and screens in your app may have different metadata like the `` tag, description, and other `<meta>` tags specific to this screen. From the maintenance perspective, it's more scalable to keep this information close to the React component for that page or screen. However, the HTML tags for this metadata need to be in the document `<head>` which is typically rendered in a component at the very root of your app. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista da manutenção, é mais escalável manter essa informação próxima ao componente React para aquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que é tipicamente renderizado em um componente na raiz do seu aplicativo. -Today, people solve this problem with one of the two techniques. +Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -One technique is to render a special third-party component that moves `<title>`, `<meta>`, and other tags inside it into the document `<head>`. This works for major browsers but there are many clients which do not run client-side JavaScript, such as Open Graph parsers, and so this technique is not universally suitable. +Uma técnica é renderizar um componente de terceiros especial que move `<title>`, `<meta>`, e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas existem muitos clientes que não executam JavaScript no lado do cliente, como parseadores Open Graph, e portanto essa técnica não é universalmente adequada. -Another technique is to server-render the page in two parts. First, the main content is rendered and all such tags are collected. Then, the `<head>` is rendered with these tags. Finally, the `<head>` and the main content are sent to the browser. This approach works, but it prevents you from taking advantage of the [React 18's Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream) because you'd have to wait for all content to render before sending the `<head>`. +Outra técnica é renderizar a página no servidor em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Por fim, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você tire proveito do [Renderizador de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todo o conteúdo ser renderizado antes de enviar o `<head>`. -This is why we're adding built-in support for rendering `<title>`, `<meta>`, and metadata `<link>` tags anywhere in your component tree out of the box. It would work the same way in all environments, including fully client-side code, SSR, and in the future, RSC. We will share more details about this soon. +É por isso que estamos adicionando suporte interno para renderizar `<title>`, `<meta>`, e tags de metadados `<link>` em qualquer lugar na sua árvore de componentes por padrão. Funcionará da mesma forma em todos os ambientes, incluindo código totalmente no lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. -## React Optimizing Compiler {/*react-optimizing-compiler*/} +## Compilador de Otimização do React {/*react-optimizing-compiler*/} -Since our previous update we've been actively iterating on the design of [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), an optimizing compiler for React. We've previously talked about it as an "auto-memoizing compiler", and that is true in some sense. But building the compiler has helped us understand React's programming model even more deeply. A better way to understand React Forget is as an automatic *reactivity* compiler. +Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador de otimização para o React. Já falamos sobre isso como um "compilador de auto-memoização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. -The core idea of React is that developers define their UI as a function of the current state. You work with plain JavaScript values — numbers, strings, arrays, objects — and use standard JavaScript idioms — if/else, for, etc — to describe your component logic. The mental model is that React will re-render whenever the application state changes. We believe this simple mental model and keeping close to JavaScript semantics is an important principle in React's programming model. +A ideia central do React é que os desenvolvedores definem sua UI como uma função do estado atual. Você trabalha com valores JavaScript comuns — números, strings, arrays, objetos — e usa idiomas padrão do JavaScript — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React re-renderiza sempre que o estado da aplicação muda. Acreditamos que esse modelo mental simples e a proximidade com as semânticas do JavaScript é um princípio importante no modelo de programação do React. -The catch is that React can sometimes be *too* reactive: it can re-render too much. For example, in JavaScript we don't have cheap ways to compare if two objects or arrays are equivalent (having the same keys and values), so creating a new object or array on each render may cause React to do more work than it strictly needs to. This means developers have to explicitly memoize components so as to not over-react to changes. +O problema é que o React pode às vezes ser *demais* reativo: ele pode re-renderizar em excesso. Por exemplo, no JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), portanto, criar um novo objeto ou array a cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar componentes explicitamente para não reagir em excesso às mudanças. -Our goal with React Forget is to ensure that React apps have just the right amount of reactivity by default: that apps re-render only when state values *meaningfully* change. From an implementation perspective this means automatically memoizing, but we believe that the reactivity framing is a better way to understand React and Forget. One way to think about this is that React currently re-renders when object identity changes. With Forget, React re-renders when the semantic value changes — but without incurring the runtime cost of deep comparisons. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando os valores do estado *mudarem de forma significativa*. Do ponto de vista da implementação, isso significa memoizar automaticamente, mas acreditamos que o enquadramento da reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo em tempo de execução de comparações profundas. -In terms of concrete progress, since our last update we have substantially iterated on the design of the compiler to align with this automatic reactivity approach and to incorporate feedback from using the compiler internally. After some significant refactors to the compiler starting late last year, we've now begun using the compiler in production in limited areas at Meta. We plan to open-source it once we've proved it in production. +Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso do compilador internamente. Após algumas refatorações significativas no compilador a partir do final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo de código aberto assim que tivermos comprovado sua eficácia em produção. -Finally, a lot of people have expressed interest in how the compiler works. We're looking forward to sharing a lot more details when we prove the compiler and open-source it. But there are a few bits we can share now: +Por fim, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar muito mais detalhes quando comprovarmos o compilador e o tornarmos de código aberto. Mas há algumas informações que podemos compartilhar agora: -The core of the compiler is almost completely decoupled from Babel, and the core compiler API is (roughly) old AST in, new AST out (while retaining source location data). Under the hood we use a custom code representation and transformation pipeline in order to do low-level semantic analysis. However, the primary public interface to the compiler will be via Babel and other build system plugins. For ease of testing we currently have a Babel plugin which is a very thin wrapper that calls the compiler to generate a new version of each function and swap it in. +O núcleo do compilador está quase completamente desacoplado do Babel, e a API central do compilador é (aproximadamente) antigo AST entrando, novo AST saindo (mantendo os dados de localização da fonte). Por trás das câmeras, usamos uma representação de código e um pipeline de transformação personalizados para realizar uma análise semântica de baixo nível. No entanto, a principal interface pública para o compilador será através do Babel e outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é um wrapper muito fino que chama o compilador para gerar uma nova versão de cada função e trocá-la. -As we refactored the compiler over the last few months, we wanted to focus on refining the core compilation model to ensure we could handle complexities such as conditionals, loops, reassignment, and mutation. However, JavaScript has a lot of ways to express each of those features: if/else, ternaries, for, for-in, for-of, etc. Trying to support the full language up-front would have delayed the point where we could validate the core model. Instead, we started with a small but representative subset of the language: let/const, if/else, for loops, objects, arrays, primitives, function calls, and a few other features. As we gained confidence in the core model and refined our internal abstractions, we expanded the supported language subset. We're also explicit about syntax we don't yet support, logging diagnostics and skipping compilation for unsupported input. We have utilities to try the compiler on Meta's codebases and see what unsupported features are most common so we can prioritize those next. We'll continue incrementally expanding towards supporting the whole language. +À medida que refatoramos o compilador nos últimos meses, queríamos nos concentrar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades, como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript tem muitas maneiras de expressar cada uma dessas características: if/else, ternários, for, for-in, for-of, etc. Tentar suportar toda a linguagem desde o início teria atrasado o momento em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e algumas outras características. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para experimentar o compilador nas bases de código da Meta e ver quais recursos não suportados são mais comuns para que possamos priorizá-los a seguir. Continuaremos expandindo incrementalmente para suportar toda a linguagem. -Making plain JavaScript in React components reactive requires a compiler with a deep understanding of semantics so that it can understand exactly what the code is doing. By taking this approach, we're creating a system for reactivity within JavaScript that lets you write product code of any complexity with the full expressivity of the language, instead of being limited to a domain specific language. +Tornar o JavaScript comum em componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema para reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com toda a expressividade da linguagem, em vez de ser limitado a uma linguagem específica de domínio. -## Offscreen Rendering {/*offscreen-rendering*/} +## Renderização Offscreen {/*offscreen-rendering*/} -Offscreen rendering is an upcoming capability in React for rendering screens in the background without additional performance overhead. You can think of it as a version of the [`content-visibility` CSS property](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) that works not only for DOM elements but React components, too. During our research, we've discovered a variety of use cases: +A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem carga adicional de desempenho. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos do DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- A router can prerender screens in the background so that when a user navigates to them, they're instantly available. -- A tab switching component can preserve the state of hidden tabs, so the user can switch between them without losing their progress. -- A virtualized list component can prerender additional rows above and below the visible window. -- When opening a modal or popup, the rest of the app can be put into "background" mode so that events and updates are disabled for everything except the modal. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. +- Um componente de troca de aba pode preservar o estado de abas ocultas, permitindo que o usuário troque entre elas sem perder seu progresso. +- Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "background", de forma que eventos e atualizações sejam desativados para tudo, exceto para o modal. -Most React developers will not interact with React's offscreen APIs directly. Instead, offscreen rendering will be integrated into things like routers and UI libraries, and then developers who use those libraries will automatically benefit without additional work. +A maioria dos desenvolvedores React não interagirá com as APIs offscreen do React diretamente. Em vez disso, a renderização offscreen será integrada em coisas como roteadores e bibliotecas de UI, e, em seguida, os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. -The idea is that you should be able to render any React tree offscreen without changing the way you write your components. When a component is rendered offscreen, it does not actually *mount* until the component becomes visible — its effects are not fired. For example, if a component uses `useEffect` to log analytics when it appears for the first time, prerendering won't mess up the accuracy of those analytics. Similarly, when a component goes offscreen, its effects are unmounted, too. A key feature of offscreen rendering is that you can toggle the visibility of a component without losing its state. +A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a forma como você escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não comprometerá a precisão dessas análises. Da mesma forma, quando um componente vai para offscreen, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. -Since our last update, we've tested an experimental version of prerendering internally at Meta in our React Native apps on Android and iOS, with positive performance results. We've also improved how offscreen rendering works with Suspense — suspending inside an offscreen tree will not trigger Suspense fallbacks. Our remaining work involves finalizing the primitives that are exposed to library developers. We expect to publish an RFC later this year, alongside an experimental API for testing and feedback. +Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native para Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará os fallbacks do Suspense. Nosso trabalho restante envolve finalizar os primitivos que são expostos para os desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. -## Transition Tracing {/*transition-tracing*/} +## Rastreio de Transição {/*transition-tracing*/} -The Transition Tracing API lets you detect when [React Transitions](/reference/react/useTransition) become slower and investigate why they may be slow. Following our last update, we have completed the initial design of the API and published an [RFC](https://github.com/reactjs/rfcs/pull/238). The basic capabilities have also been implemented. The project is currently on hold. We welcome feedback on the RFC and look forward to resuming its development to provide a better performance measurement tool for React. This will be particularly useful with routers built on top of React Transitions, like the [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Rastreio de Transição permite que você detecte quando as [Transições React](/reference/react/useTransition) ficam mais lentas e investigue por que elas podem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente em pausa. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta melhor de medição de desempenho para React. Isso será particularmente útil com roteadores construídos sobre Transições React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -In addition to this update, our team has made recent guest appearances on community podcasts and livestreams to speak more on our work and answer questions. +Além dessa atualização, nossa equipe fez recentes aparições em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were interviewed by [Kent C. Dodds on his YouTube channel](https://www.youtube.com/watch?v=h7tur48JSaw), where they discussed concerns around React Server Components. -* [Dan Abramov](https://twitter.com/dan_abramov) and [Joe Savona](https://twitter.com/en_JS) were guests on the [JSParty podcast](https://jsparty.fm/267) and shared their thoughts about the future of React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes de Servidor do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. -Thanks to [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), and [Sophie Alpert](https://twitter.com/sophiebits) for reviewing this post. +Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) por revisar este post. -Thanks for reading, and see you in the next update! +Obrigado por ler e até a próxima atualização! \ No newline at end of file From 405ca534983ef7f0d95382c5cb85adc0c5002754 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias <badivia.f@gmail.com> Date: Mon, 20 Jan 2025 11:33:31 -0300 Subject: [PATCH 2/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 84 +++++++++---------- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index 927c84ec7..8c1443444 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,17 +1,17 @@ --- title: "React Labs: No que temos trabalhado – Março de 2023" -author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark +author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage e Andrew Clark date: 2023/03/22 -description: Em posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. +description: Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- -22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) +22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) --- <Intro> -Em posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. +Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. </Intro> @@ -19,87 +19,87 @@ Em posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ## React Server Components {/*react-server-components*/} -React Server Components (ou RSC) é uma nova arquitetura de aplicação projetada pela equipe do React. +Os React Server Components (ou RSC) são uma nova arquitetura de aplicativo projetada pela equipe do React. -Compartilhamos nossa pesquisa sobre RSC pela primeira vez em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente — Componentes de Servidor — que são executados antecipadamente e estão excluídos do seu pacote JavaScript. Componentes de Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem a necessidade de construir uma API. Você pode passar dados por props de Componentes de Servidor para os Componentes de Cliente interativos no navegador. +Compartilhamos pela primeira vez nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e em um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente — Server Components — que são executados antes do tempo e são excluídos do seu pacote JavaScript. Os Server Components podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por meio de props dos Server Components para os Client Components interativos no navegador. -RSC combina o simples modelo mental de "request/response" de Aplicações Multi-Páginas centradas no servidor com a interatividade contínua de Aplicações de Página Única centradas no cliente, oferecendo o melhor dos dois mundos. +O RSC combina o simples modelo mental de "requisição/resposta" de aplicativos Multi-Page centrados no servidor com a interatividade contínua dos aplicativos Single-Page centrados no cliente, proporcionando o melhor dos dois mundos. -Desde nossa última atualização, mesclamos o [RFC de Componentes de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta de [Convenções de Módulos de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e alcançamos um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificação do que uma implementação compatível com RSC deve suportar. +Desde nossa última atualização, mesclamos o [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta de [Convencões de Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também servem como especificação para o que uma implementação compatível com RSC deve suportar. -A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal forma de fazer a busca de dados a partir de Componentes de Servidor. Também planejamos suportar o carregamento de dados a partir do cliente ao introduzir um novo Hook chamado `use`, que desvencilha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas de cliente, planejamos adicionar suporte a isso ao estruturar seu aplicativo apenas de cliente de forma semelhante à como os aplicativos RSC são estruturados. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer o fetching de dados a partir dos Server Components. Também planejamos suportar o carregamento de dados a partir do cliente, introduzindo um novo Hook chamado `use`, que desembrulha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte a isso quando você estruturar seu aplicativo apenas do cliente de maneira semelhante a como os aplicativos RSC estão estruturados. -Agora que temos a busca de dados bem resolvida, estamos explorando a outra direção: enviar dados do cliente para o servidor, de forma que você possa executar mutações em bancos de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ações de Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, fornecendo RPC contínuo. Ações de Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript carregue. +Agora que resolvemos bastante bem o problema de fetching de dados, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Server Action através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando RPC sem costura. As Server Actions também fornecem formulários progressivamente aprimorados antes que o JavaScript seja carregado. -Os Componentes de Servidor do React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatível com RSC. Há uma separação clara para os recursos fornecidos pela especificação RSC e a implementação. Componentes de Servidor do React destinam-se a ser uma especificação para componentes que funcionam em frameworks React compatíveis. +Os React Server Components foram implementados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente se aprofunda no RSC como uma primitiva, mas não é a única maneira de construir um roteador e um framework compatíveis com RSC. Há uma separação clara para os recursos fornecidos pela especificação e implementação do RSC. Os React Server Components são destinados a ser uma especificação para componentes que funcionam em frameworks React compatíveis. -Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos que fosse, principalmente devido à profunda integração necessária com o bundler. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos colaborando diretamente com desenvolvedores de bundler para obter os primitivos para RSC incorporados. +Recomendamos em geral o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração do bundler necessária. A geração atual de bundlers funciona bem no lado do cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulos entre o servidor e o cliente. Por isso, estamos agora fazendo parceria diretamente com desenvolvedores de bundler para obter as primitivas para RSC integradas. ## Carregamento de Ativos {/*asset-loading*/} -[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está carregando, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, sob a perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na UI e sucessivas mudanças de layout. +[A Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está carregando, bem como durante as navegações do roteador que carregam mais dados e código. No entanto, do ponto de vista do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na IU e mudanças consecutivas de layout. -Estamos trabalhando para integrar totalmente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os considere para determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na forma como você escreve seus componentes React, as atualizações se comportarão de uma maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. +Estamos trabalhando para integrar completamente a Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os leve em consideração ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na maneira como você autor seus componentes React, as atualizações se comportarão de maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. -Atualmente estamos implementando esses recursos e teremos mais a compartilhar em breve. +Atualmente, estamos implementando esses recursos e teremos mais novidades em breve. ## Metadados do Documento {/*document-metadata*/} -Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista da manutenção, é mais escalável manter essa informação próxima ao componente React para aquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que é tipicamente renderizado em um componente na raiz do seu aplicativo. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas do componente React para aquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que geralmente é renderizado em um componente na raiz do seu aplicativo. Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -Uma técnica é renderizar um componente de terceiros especial que move `<title>`, `<meta>`, e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas existem muitos clientes que não executam JavaScript no lado do cliente, como parseadores Open Graph, e portanto essa técnica não é universalmente adequada. +Uma técnica é renderizar um componente de terceiros especial que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas há muitos clientes que não executam JavaScript do lado do cliente, como os analisadores de Open Graph, portanto, essa técnica não é universalmente adequada. -Outra técnica é renderizar a página no servidor em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Por fim, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você tire proveito do [Renderizador de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todo o conteúdo ser renderizado antes de enviar o `<head>`. +Outra técnica é renderizar o servidor da página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Servidor de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todos os conteúdos serem renderizados antes de enviar o `<head>`. -É por isso que estamos adicionando suporte interno para renderizar `<title>`, `<meta>`, e tags de metadados `<link>` em qualquer lugar na sua árvore de componentes por padrão. Funcionará da mesma forma em todos os ambientes, incluindo código totalmente no lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. +Por isso, estamos adicionando suporte integrado para renderizar tags `<title>`, `<meta>` e `<link>` de metadados em qualquer lugar na sua árvore de componentes diretamente. Isso funcionará da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. -## Compilador de Otimização do React {/*react-optimizing-compiler*/} +## Compilador Otimizador do React {/*react-optimizing-compiler*/} -Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador de otimização para o React. Já falamos sobre isso como um "compilador de auto-memoização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. +Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizador para o React. Já falamos sobre ele como um "compilador automático de memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a compreender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. -A ideia central do React é que os desenvolvedores definem sua UI como uma função do estado atual. Você trabalha com valores JavaScript comuns — números, strings, arrays, objetos — e usa idiomas padrão do JavaScript — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React re-renderiza sempre que o estado da aplicação muda. Acreditamos que esse modelo mental simples e a proximidade com as semânticas do JavaScript é um princípio importante no modelo de programação do React. +A ideia central do React é que os desenvolvedores definem sua IU como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa idiomatismos padrão do JavaScript — if/else, for, etc. — para descrever a lógica do seu componente. O modelo mental é que o React re-renderiza sempre que o estado da aplicação muda. Acreditamos que esse modelo mental simples e a proximidade com a semântica do JavaScript é um princípio importante no modelo de programação do React. -O problema é que o React pode às vezes ser *demais* reativo: ele pode re-renderizar em excesso. Por exemplo, no JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), portanto, criar um novo objeto ou array a cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar componentes explicitamente para não reagir em excesso às mudanças. +A questão é que o React às vezes pode ser *demais* reativo: pode re-renderizar demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array a cada renderização pode fazer com que o React trabalhe mais do que realmente precisa. Isso significa que os desenvolvedores têm que memorizá-los explicitamente para não reagir em demasia às mudanças. -Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando os valores do estado *mudarem de forma significativa*. Do ponto de vista da implementação, isso significa memoizar automaticamente, mas acreditamos que o enquadramento da reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo em tempo de execução de comparações profundas. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando valores de estado mudam *significativamente*. Do ponto de vista de implementação, isso significa memorização automática, mas acreditamos que a formulação de reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. -Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso do compilador internamente. Após algumas refatorações significativas no compilador a partir do final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo de código aberto assim que tivermos comprovado sua eficácia em produção. +Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente sobre o design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso interno do compilador. Após algumas refatorações significativas no compilador no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos tornar isso open source assim que tivermos provado sua eficácia em produção. -Por fim, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar muito mais detalhes quando comprovarmos o compilador e o tornarmos de código aberto. Mas há algumas informações que podemos compartilhar agora: +Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando provarmos o compilador e o tornarmos open source. Mas há alguns pontos que podemos compartilhar agora: -O núcleo do compilador está quase completamente desacoplado do Babel, e a API central do compilador é (aproximadamente) antigo AST entrando, novo AST saindo (mantendo os dados de localização da fonte). Por trás das câmeras, usamos uma representação de código e um pipeline de transformação personalizados para realizar uma análise semântica de baixo nível. No entanto, a principal interface pública para o compilador será através do Babel e outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é um wrapper muito fino que chama o compilador para gerar uma nova versão de cada função e trocá-la. +O núcleo do compilador está quase completamente desacoplado do Babel, e a API do compilador é (aproximadamente) AST antigo como entrada, novo AST como saída (mantendo os dados de localização de origem). Nos bastidores, usamos uma representação de código personalizada e um pipeline de transformação para realizar uma análise semântica de baixo nível. No entanto, a interface pública principal do compilador será através do Babel e de outros plugins do sistema de compilação. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e trocá-la. -À medida que refatoramos o compilador nos últimos meses, queríamos nos concentrar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades, como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript tem muitas maneiras de expressar cada uma dessas características: if/else, ternários, for, for-in, for-of, etc. Tentar suportar toda a linguagem desde o início teria atrasado o momento em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e algumas outras características. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para experimentar o compilador nas bases de código da Meta e ver quais recursos não suportados são mais comuns para que possamos priorizá-los a seguir. Continuaremos expandindo incrementalmente para suportar toda a linguagem. +À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades, como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript possui muitas maneiras de expressar cada uma dessas características: if/else, ternários, for, for-in, for-of, etc. Tentar suportar a linguagem completa desde o início teria atrasado o ponto em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e algumas outras características. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto da linguagem suportada. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e ignorando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses recursos em seguida. Continuaremos expandindo gradualmente para suportar toda a linguagem. -Tornar o JavaScript comum em componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema para reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com toda a expressividade da linguagem, em vez de ser limitado a uma linguagem específica de domínio. +Fazer JavaScript simples nos componentes React reativos exige um compilador com uma compreensão profunda das semânticas, para que ele possa entender exatamente o que o código está fazendo. Ao seguir essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com a total expressividade da linguagem, em vez de ser limitado a uma linguagem específica do domínio. ## Renderização Offscreen {/*offscreen-rendering*/} -A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem carga adicional de desempenho. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos do DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: +A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga adicional de desempenho. Você pode pensá-la como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos do DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. -- Um componente de troca de aba pode preservar o estado de abas ocultas, permitindo que o usuário troque entre elas sem perder seu progresso. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navegar para elas, elas estejam instantaneamente disponíveis. +- Um componente de mudança de aba pode preservar o estado das abas ocultas, permitindo que o usuário alterne entre elas sem perder seu progresso. - Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. -- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "background", de forma que eventos e atualizações sejam desativados para tudo, exceto para o modal. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "background", de modo que eventos e atualizações sejam desativados para tudo, exceto para o modal. -A maioria dos desenvolvedores React não interagirá com as APIs offscreen do React diretamente. Em vez disso, a renderização offscreen será integrada em coisas como roteadores e bibliotecas de UI, e, em seguida, os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. +A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de IU, e, assim, os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. -A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a forma como você escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não comprometerá a precisão dessas análises. Da mesma forma, quando um componente vai para offscreen, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. +A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* realmente até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não prejudicará a precisão dessas análises. Da mesma forma, quando um componente sai da tela, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. -Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native para Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará os fallbacks do Suspense. Nosso trabalho restante envolve finalizar os primitivos que são expostos para os desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. +Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com a Suspense — suspender dentro de uma árvore offscreen não acionará os fallback da Suspense. Nossa tarefa restante envolve a finalização das primitivas que serão expostas para desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. -## Rastreio de Transição {/*transition-tracing*/} +## Rastreio de Transições {/*transition-tracing*/} -A API de Rastreio de Transição permite que você detecte quando as [Transições React](/reference/react/useTransition) ficam mais lentas e investigue por que elas podem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente em pausa. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta melhor de medição de desempenho para React. Isso será particularmente útil com roteadores construídos sobre Transições React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Rastreio de Transições permite que você detecte quando [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, finalizamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente suspenso. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -Além dessa atualização, nossa equipe fez recentes aparições em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. +Além desta atualização, nossa equipe fez aparições recentes como convidados em podcasts da comunidade e transmissões ao vivo para falar mais sobre nosso trabalho e responder perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes de Servidor do React. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos React Server Components. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados do [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. -Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) por revisar este post. +Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster) e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão deste post. Obrigado por ler e até a próxima atualização! \ No newline at end of file From 07253c23d32572d1b9f9d224b82fcde7c759e2f4 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias <badivia.f@gmail.com> Date: Mon, 20 Jan 2025 11:56:12 -0300 Subject: [PATCH 3/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 80 +++++++++---------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index 8c1443444..b38000941 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,11 +1,11 @@ --- -title: "React Labs: No que temos trabalhado – Março de 2023" -author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage e Andrew Clark +title: "React Labs: No que estamos trabalhando – Março de 2023" +author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark date: 2023/03/22 description: Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- -22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) +22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) --- @@ -19,87 +19,87 @@ Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ## React Server Components {/*react-server-components*/} -Os React Server Components (ou RSC) são uma nova arquitetura de aplicativo projetada pela equipe do React. +React Server Components (ou RSC) é uma nova arquitetura de aplicação projetada pela equipe do React. -Compartilhamos pela primeira vez nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e em um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente — Server Components — que são executados antes do tempo e são excluídos do seu pacote JavaScript. Os Server Components podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por meio de props dos Server Components para os Client Components interativos no navegador. +Primeiro, compartilhamos nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente--Componentes do Servidor--que são executados antecipadamente e são excluídos do seu pacote JavaScript. Componentes do Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por props de Componentes do Servidor para os Componentes Interativos do Cliente no navegador. -O RSC combina o simples modelo mental de "requisição/resposta" de aplicativos Multi-Page centrados no servidor com a interatividade contínua dos aplicativos Single-Page centrados no cliente, proporcionando o melhor dos dois mundos. +RSC combina o simples modelo mental "pedido/resposta" de Aplicações Multi-Página centradas no servidor com a interatividade suave de Aplicações de Página Única centradas no cliente, oferecendo o melhor dos dois mundos. -Desde nossa última atualização, mesclamos o [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta de [Convencões de Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também servem como especificação para o que uma implementação compatível com RSC deve suportar. +Desde nossa última atualização, nós fundimos o [RFC de Componentes do Servidor React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos as questões pendentes com a proposta das [Convenções de Módulo do Servidor React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificação para o que uma implementação compatível com RSC deve suportar. -A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer o fetching de dados a partir dos Server Components. Também planejamos suportar o carregamento de dados a partir do cliente, introduzindo um novo Hook chamado `use`, que desembrulha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte a isso quando você estruturar seu aplicativo apenas do cliente de maneira semelhante a como os aplicativos RSC estão estruturados. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de realizar a busca de dados a partir dos Componentes do Servidor. Também planejamos suportar o carregamento de dados a partir do cliente, introduzindo um novo Hook chamado `use` que desembrulha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte para isso quando você estruturar seu aplicativo apenas do cliente de forma semelhante ao modo como os aplicativos RSC estão estruturados. -Agora que resolvemos bastante bem o problema de fetching de dados, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Server Action através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando RPC sem costura. As Server Actions também fornecem formulários progressivamente aprimorados antes que o JavaScript seja carregado. +Agora que temos a busca de dados bem resolvida, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando um RPC suave. As Ações do Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript carregue. -Os React Server Components foram implementados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente se aprofunda no RSC como uma primitiva, mas não é a única maneira de construir um roteador e um framework compatíveis com RSC. Há uma separação clara para os recursos fornecidos pela especificação e implementação do RSC. Os React Server Components são destinados a ser uma especificação para componentes que funcionam em frameworks React compatíveis. +Os Componentes do Servidor React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente se compromete com RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatível com RSC. Há uma clara separação entre os recursos fornecidos pela especificação RSC e a implementação. Os Componentes do Servidor React são destinados a ser uma especificação para componentes que funcionam através de frameworks React compatíveis. -Recomendamos em geral o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração do bundler necessária. A geração atual de bundlers funciona bem no lado do cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulos entre o servidor e o cliente. Por isso, estamos agora fazendo parceria diretamente com desenvolvedores de bundler para obter as primitivas para RSC integradas. +Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração do bundler necessária. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de bundler para obter os primitivos para RSC embutidos. ## Carregamento de Ativos {/*asset-loading*/} -[A Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está carregando, bem como durante as navegações do roteador que carregam mais dados e código. No entanto, do ponto de vista do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na IU e mudanças consecutivas de layout. +[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou código dos seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam gradualmente mais conteúdo enquanto a página está carregando, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na interface do usuário e mudanças de layout consecutivas. -Estamos trabalhando para integrar completamente a Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os leve em consideração ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na maneira como você autor seus componentes React, as atualizações se comportarão de maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. +Estamos trabalhando para integrar totalmente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os considere ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na maneira como você escreve seus componentes React, as atualizações se comportarão de maneira mais coesa e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente a partir dos componentes. -Atualmente, estamos implementando esses recursos e teremos mais novidades em breve. +Atualmente estamos implementando esses recursos e teremos mais para compartilhar em breve. ## Metadados do Documento {/*document-metadata*/} -Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas do componente React para aquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que geralmente é renderizado em um componente na raiz do seu aplicativo. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para essa tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas ao componente React daquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que normalmente é renderizado em um componente na raiz do seu aplicativo. Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -Uma técnica é renderizar um componente de terceiros especial que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas há muitos clientes que não executam JavaScript do lado do cliente, como os analisadores de Open Graph, portanto, essa técnica não é universalmente adequada. +Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para navegadores principais, mas há muitos clientes que não executam JavaScript do lado do cliente, como analisadores Open Graph, e assim essa técnica não é universalmente adequada. -Outra técnica é renderizar o servidor da página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Servidor de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todos os conteúdos serem renderizados antes de enviar o `<head>`. +Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [React 18's Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream), porque você teria que esperar por todo o conteúdo ser renderizado antes de enviar o `<head>`. -Por isso, estamos adicionando suporte integrado para renderizar tags `<title>`, `<meta>` e `<link>` de metadados em qualquer lugar na sua árvore de componentes diretamente. Isso funcionará da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. +É por isso que estamos adicionando suporte embutido para renderizar tags `<title>`, `<meta>` e `<link>` de metadados em qualquer lugar da sua árvore de componentes desde o início. Funcionará da mesma forma em todos os ambientes, incluindo código totalmente do lado do cliente, SSR, e no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. ## Compilador Otimizador do React {/*react-optimizing-compiler*/} -Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizador para o React. Já falamos sobre ele como um "compilador automático de memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a compreender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. +Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizador para React. Já falamos sobre ele como um "compilador de auto-memoização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador de *reatividade* automática. -A ideia central do React é que os desenvolvedores definem sua IU como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa idiomatismos padrão do JavaScript — if/else, for, etc. — para descrever a lógica do seu componente. O modelo mental é que o React re-renderiza sempre que o estado da aplicação muda. Acreditamos que esse modelo mental simples e a proximidade com a semântica do JavaScript é um princípio importante no modelo de programação do React. +A ideia central do React é que os desenvolvedores definem sua interface do usuário como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa idioms JavaScript padrão — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React irá re-renderizar sempre que o estado da aplicação mudar. Acreditamos que esse modelo mental simples e o fato de permanecer próximo à semântica JavaScript é um princípio importante no modelo de programação do React. -A questão é que o React às vezes pode ser *demais* reativo: pode re-renderizar demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array a cada renderização pode fazer com que o React trabalhe mais do que realmente precisa. Isso significa que os desenvolvedores têm que memorizá-los explicitamente para não reagir em demasia às mudanças. +O problema é que o React pode, às vezes, ser *demais* reativo: ele pode re-renderizar demais. Por exemplo, no JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar explicitamente os componentes para não reagir excessivamente às alterações. -Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando valores de estado mudam *significativamente*. Do ponto de vista de implementação, isso significa memorização automática, mas acreditamos que a formulação de reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham apenas a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando os valores de estado mudarem *significativamente*. Do ponto de vista de implementação, isso significa memoização automática, mas acreditamos que a formulação de reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. -Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente sobre o design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso interno do compilador. Após algumas refatorações significativas no compilador no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos tornar isso open source assim que tivermos provado sua eficácia em produção. +Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedbacks do uso do compilador internamente. Após algumas refatorações significativas no compilador começando no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo open-source uma vez que tenhamos comprovado sua eficácia em produção. -Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando provarmos o compilador e o tornarmos open source. Mas há alguns pontos que podemos compartilhar agora: +Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando comprovamos o compilador e o tornamos open-source. Mas há algumas informações que podemos compartilhar agora: -O núcleo do compilador está quase completamente desacoplado do Babel, e a API do compilador é (aproximadamente) AST antigo como entrada, novo AST como saída (mantendo os dados de localização de origem). Nos bastidores, usamos uma representação de código personalizada e um pipeline de transformação para realizar uma análise semântica de baixo nível. No entanto, a interface pública principal do compilador será através do Babel e de outros plugins do sistema de compilação. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e trocá-la. +O núcleo do compilador é quase completamente desacoplado do Babel, e a API principal do compilador é (de forma ampla) AST antigo entrando, novo AST saindo (mantendo os dados de localização da fonte). Nos bastidores, usamos uma representação de código personalizada e um pipeline de transformação para realizar análise semântica de baixo nível. No entanto, a interface pública principal para o compilador será através do Babel e outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e substituí-la. -À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades, como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript possui muitas maneiras de expressar cada uma dessas características: if/else, ternários, for, for-in, for-of, etc. Tentar suportar a linguagem completa desde o início teria atrasado o ponto em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e algumas outras características. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto da linguagem suportada. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e ignorando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses recursos em seguida. Continuaremos expandindo gradualmente para suportar toda a linguagem. +À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação principal para garantir que pudéssemos lidar com complexidades como condicionais, loops, reatribuições e mutações. No entanto, o JavaScript possui muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar suportar a linguagem completa logo de início teria atrasado o ponto em que poderíamos validar o modelo principal. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo principal e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses próximos. Continuaremos expandindo incrementalmente para apoiar a linguagem inteira. -Fazer JavaScript simples nos componentes React reativos exige um compilador com uma compreensão profunda das semânticas, para que ele possa entender exatamente o que o código está fazendo. Ao seguir essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com a total expressividade da linguagem, em vez de ser limitado a uma linguagem específica do domínio. +Fazer JavaScript simples nos componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produção de qualquer complexidade com toda a expressividade da linguagem, em vez de estar limitado a uma linguagem específica de domínio. ## Renderização Offscreen {/*offscreen-rendering*/} -A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga adicional de desempenho. Você pode pensá-la como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos do DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: +A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga de desempenho adicional. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navegar para elas, elas estejam instantaneamente disponíveis. -- Um componente de mudança de aba pode preservar o estado das abas ocultas, permitindo que o usuário alterne entre elas sem perder seu progresso. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. +- Um componente de troca de abas pode preservar o estado das abas ocultas, permitindo que o usuário mude entre elas sem perder seu progresso. - Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. -- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "background", de modo que eventos e atualizações sejam desativados para tudo, exceto para o modal. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo" para que eventos e atualizações sejam desativados, exceto para o modal. -A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de IU, e, assim, os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. +A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada em coisas como roteadores e bibliotecas de UI, e então os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. -A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* realmente até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não prejudicará a precisão dessas análises. Da mesma forma, quando um componente sai da tela, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. +A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como escreve seus componentes. Quando um componente é renderizado offscreen, ele na verdade não *monta* até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não afetará a precisão dessas análises. Da mesma forma, quando um componente vai offscreen, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. -Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com a Suspense — suspender dentro de uma árvore offscreen não acionará os fallback da Suspense. Nossa tarefa restante envolve a finalização das primitivas que serão expostas para desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. +Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados positivos de desempenho. Também melhoramos a forma como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará fallback do Suspense. Nosso trabalho restante envolve finalizar os primitivos que serão expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para teste e feedback. -## Rastreio de Transições {/*transition-tracing*/} +## Rastreamento de Transição {/*transition-tracing*/} -A API de Rastreio de Transições permite que você detecte quando [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, finalizamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente suspenso. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Rastreamento de Transição permite que você detecte quando [Transições React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente suspenso. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre Transições React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -Além desta atualização, nossa equipe fez aparições recentes como convidados em podcasts da comunidade e transmissões ao vivo para falar mais sobre nosso trabalho e responder perguntas. +Além desta atualização, nossa equipe fez aparições recentes em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos React Server Components. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes do Servidor React. * [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados do [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. -Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster) e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão deste post. +Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão deste post. -Obrigado por ler e até a próxima atualização! \ No newline at end of file +Obrigado por ler, e até a próxima atualização! \ No newline at end of file From 5af733d64f20b0cbe4e3104353feeeddcf65f728 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias <badivia.f@gmail.com> Date: Mon, 20 Jan 2025 14:17:05 -0300 Subject: [PATCH 4/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 90 +++++++++---------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index b38000941..4b6772eed 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,8 +1,8 @@ --- -title: "React Labs: No que estamos trabalhando – Março de 2023" +title: "React Labs: No que Estamos Trabalhando – Março de 2023" author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark date: 2023/03/22 -description: Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. +description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- 22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) @@ -11,7 +11,7 @@ description: Nos posts do React Labs, escrevemos sobre projetos em pesquisa e de <Intro> -Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. +Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. </Intro> @@ -19,87 +19,87 @@ Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ## React Server Components {/*react-server-components*/} -React Server Components (ou RSC) é uma nova arquitetura de aplicação projetada pela equipe do React. +React Server Components (ou RSC) é uma nova arquitetura de aplicativo projetada pela equipe do React. -Primeiro, compartilhamos nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente--Componentes do Servidor--que são executados antecipadamente e são excluídos do seu pacote JavaScript. Componentes do Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por props de Componentes do Servidor para os Componentes Interativos do Cliente no navegador. +Compartilhamos inicialmente nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente—Componentes de Servidor—que são executados antecipadamente e são excluídos do seu pacote JavaScript. Os Componentes de Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por meio de props dos Componentes de Servidor para os Componentes Interativos do Cliente no navegador. -RSC combina o simples modelo mental "pedido/resposta" de Aplicações Multi-Página centradas no servidor com a interatividade suave de Aplicações de Página Única centradas no cliente, oferecendo o melhor dos dois mundos. +RSC combina o simples modelo mental de "requisição/resposta" de Aplicativos Multi-Página centrados no servidor com a interatividade contínua de Aplicativos de Página Única centrados no cliente, oferecendo o melhor de ambos os mundos. -Desde nossa última atualização, nós fundimos o [RFC de Componentes do Servidor React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos as questões pendentes com a proposta das [Convenções de Módulo do Servidor React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificação para o que uma implementação compatível com RSC deve suportar. +Desde nossa última atualização, fundimos o [RFC dos Componentes de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta das [Convenções de Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificações sobre o que uma implementação compatível com RSC deve suportar. -A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de realizar a busca de dados a partir dos Componentes do Servidor. Também planejamos suportar o carregamento de dados a partir do cliente, introduzindo um novo Hook chamado `use` que desembrulha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte para isso quando você estruturar seu aplicativo apenas do cliente de forma semelhante ao modo como os aplicativos RSC estão estruturados. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer a busca de dados a partir dos Componentes de Servidor. Também planejamos suportar o carregamento de dados a partir do cliente introduzindo um novo Hook chamado `use` que desvenda Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte quando você estruturar seu aplicativo somente do cliente de forma semelhante à estrutura dos aplicativos RSC. -Agora que temos a busca de dados bem resolvida, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando um RPC suave. As Ações do Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript carregue. +Agora que temos a busca de dados bem encaminhada, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso ao permitir que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, fornecendo RPC contínuo. As Ações do Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript seja carregado. -Os Componentes do Servidor React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente se compromete com RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatível com RSC. Há uma clara separação entre os recursos fornecidos pela especificação RSC e a implementação. Os Componentes do Servidor React são destinados a ser uma especificação para componentes que funcionam através de frameworks React compatíveis. +Os Componentes de Servidor do React foram implementados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota RSC como um primitivo, mas não é a única maneira de construir um roteador e um framework compatível com RSC. Existe uma clara separação para os recursos fornecidos pela especificação RSC e pela implementação. Os Componentes de Servidor do React são destinados a ser uma especificação para componentes que funcionam entre frameworks compatíveis com o React. -Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração do bundler necessária. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de bundler para obter os primitivos para RSC embutidos. +Geralmente, recomendamos o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração necessária com os empacotadores. A geração atual de empacotadores é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de empacotadores para que os primitivos para RSC sejam embutidos. -## Carregamento de Ativos {/*asset-loading*/} +## Asset Loading {/*asset-loading*/} -[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou código dos seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam gradualmente mais conteúdo enquanto a página está carregando, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na interface do usuário e mudanças de layout consecutivas. +[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está sendo carregada, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na UI e mudanças consecutivas de layout. -Estamos trabalhando para integrar totalmente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os considere ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na maneira como você escreve seus componentes React, as atualizações se comportarão de maneira mais coesa e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente a partir dos componentes. +Estamos trabalhando para integrar completamente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React leve isso em consideração ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na forma como você cria seus componentes React, as atualizações se comportarão de maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos, como fontes, diretamente de componentes. -Atualmente estamos implementando esses recursos e teremos mais para compartilhar em breve. +Atualmente, estamos implementando esses recursos e teremos mais para compartilhar em breve. -## Metadados do Documento {/*document-metadata*/} +## Document Metadata {/*document-metadata*/} -Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para essa tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas ao componente React daquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que normalmente é renderizado em um componente na raiz do seu aplicativo. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição, e outras tags `<meta>` específicas para essa tela. Do ponto de vista da manutenção, é mais escalável manter essa informação próxima ao componente React daquela página ou tela. No entanto, as tags HTML para esse metadado precisam estar no `<head>` do documento, que normalmente é renderizado em um componente na raiz do seu aplicativo. Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para navegadores principais, mas há muitos clientes que não executam JavaScript do lado do cliente, como analisadores Open Graph, e assim essa técnica não é universalmente adequada. +Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>`, e outras tags dentro dele para o `<head>` do documento. Isso funciona para navegadores principais, mas há muitos clientes que não executam JavaScript no lado do cliente, como parsers Open Graph, e essa técnica não é universalmente adequada. -Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [React 18's Streaming Server Renderer](/reference/react-dom/server/renderToReadableStream), porque você teria que esperar por todo o conteúdo ser renderizado antes de enviar o `<head>`. +Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todo o conteúdo ser renderizado antes de enviar o `<head>`. -É por isso que estamos adicionando suporte embutido para renderizar tags `<title>`, `<meta>` e `<link>` de metadados em qualquer lugar da sua árvore de componentes desde o início. Funcionará da mesma forma em todos os ambientes, incluindo código totalmente do lado do cliente, SSR, e no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. +É por isso que estamos adicionando suporte embutido para renderizar tags `<title>`, `<meta>`, e `<link>` de metadados em qualquer lugar da sua árvore de componentes, de forma automática. Isso funcionará da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. -## Compilador Otimizador do React {/*react-optimizing-compiler*/} +## React Optimizing Compiler {/*react-optimizing-compiler*/} -Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizador para React. Já falamos sobre ele como um "compilador de auto-memoização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador de *reatividade* automática. +Desde nossa última atualização, temos iterado ativamente sobre o design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizado para o React. Falamos anteriormente sobre ele como um "compilador de auto-memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador de *reatividade* automático. -A ideia central do React é que os desenvolvedores definem sua interface do usuário como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa idioms JavaScript padrão — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React irá re-renderizar sempre que o estado da aplicação mudar. Acreditamos que esse modelo mental simples e o fato de permanecer próximo à semântica JavaScript é um princípio importante no modelo de programação do React. +A ideia central do React é que os desenvolvedores definem sua UI como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa o idioma JavaScript padrão — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React fará uma nova renderização sempre que o estado da aplicação mudar. Acreditamos que esse simples modelo mental e a manutenção próxima das semânticas do JavaScript são um princípio importante no modelo de programação do React. -O problema é que o React pode, às vezes, ser *demais* reativo: ele pode re-renderizar demais. Por exemplo, no JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar explicitamente os componentes para não reagir excessivamente às alterações. +O problema é que o React pode, às vezes, ser *demais* reativo: pode renderizar novamente demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (têm as mesmas chaves e valores), portanto, criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar explicitamente os componentes para não reagir demais às mudanças. -Nosso objetivo com o React Forget é garantir que os aplicativos React tenham apenas a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando os valores de estado mudarem *significativamente*. Do ponto de vista de implementação, isso significa memoização automática, mas acreditamos que a formulação de reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham apenas a quantidade certa de reatividade por padrão: que os aplicativos sejam renderizados novamente apenas quando os valores de estado mudarem *significativamente*. De uma perspectiva de implementação, isso significa memoizar automaticamente, mas acreditamos que a estruturação da reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente renderiza novamente quando a identidade do objeto muda. Com o Forget, o React renderiza novamente quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. -Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedbacks do uso do compilador internamente. Após algumas refatorações significativas no compilador começando no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo open-source uma vez que tenhamos comprovado sua eficácia em produção. +Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso interno do compilador. Após algumas refatorações significativas no compilador a partir do final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos disponibilizá-lo como código aberto uma vez que tivermos provado sua eficácia em produção. -Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando comprovamos o compilador e o tornamos open-source. Mas há algumas informações que podemos compartilhar agora: +Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando provarmos o compilador e o tornarmos de código aberto. Mas há algumas informações que podemos compartilhar agora: -O núcleo do compilador é quase completamente desacoplado do Babel, e a API principal do compilador é (de forma ampla) AST antigo entrando, novo AST saindo (mantendo os dados de localização da fonte). Nos bastidores, usamos uma representação de código personalizada e um pipeline de transformação para realizar análise semântica de baixo nível. No entanto, a interface pública principal para o compilador será através do Babel e outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e substituí-la. +O núcleo do compilador está quase completamente desacoplado do Babel, e a API principal do compilador é (aproximadamente) AST antigo de entrada, novo AST de saída (mantendo os dados de localização de origem). Por baixo dos panos, usamos uma representação personalizada de código e um pipeline de transformação para realizar uma análise semântica de baixo nível. No entanto, a interface pública principal do compilador será através do Babel e de outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e a troca. -À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação principal para garantir que pudéssemos lidar com complexidades como condicionais, loops, reatribuições e mutações. No entanto, o JavaScript possui muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar suportar a linguagem completa logo de início teria atrasado o ponto em que poderíamos validar o modelo principal. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo principal e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses próximos. Continuaremos expandindo incrementalmente para apoiar a linguagem inteira. +À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript possui muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar suportar toda a linguagem desde o início teria atrasado o momento em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos repositórios de código da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses próximos. Continuaremos expandindo progressivamente para suportar toda a linguagem. -Fazer JavaScript simples nos componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produção de qualquer complexidade com toda a expressividade da linguagem, em vez de estar limitado a uma linguagem específica de domínio. +Tornar o JavaScript simples em componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produção de qualquer complexidade com toda a expressividade da linguagem, em vez de ficar limitado a uma linguagem específica de domínio. -## Renderização Offscreen {/*offscreen-rendering*/} +## Offscreen Rendering {/*offscreen-rendering*/} -A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga de desempenho adicional. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: +A renderização fora da tela é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga adicional de desempenho. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. -- Um componente de troca de abas pode preservar o estado das abas ocultas, permitindo que o usuário mude entre elas sem perder seu progresso. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, elas estejam instantaneamente disponíveis. +- Um componente de troca de abas pode preservar o estado de abas ocultas, para que o usuário possa alternar entre elas sem perder seu progresso. - Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. -- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo" para que eventos e atualizações sejam desativados, exceto para o modal. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo" para que eventos e atualizações sejam desativados para tudo, exceto o modal. -A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada em coisas como roteadores e bibliotecas de UI, e então os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. +A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de UI, e os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. -A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como escreve seus componentes. Quando um componente é renderizado offscreen, ele na verdade não *monta* até que o componente se torne visível — seus efeitos não são acionados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não afetará a precisão dessas análises. Da mesma forma, quando um componente vai offscreen, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. +A ideia é que você deva ser capaz de renderizar qualquer árvore React fora da tela sem mudar a forma como escreve seus componentes. Quando um componente é renderizado fora da tela, ele não é realmente *montado* até que o componente se torne visível — seus efeitos não são disparados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não afetará a precisão dessas análises. Da mesma forma, quando um componente sai da tela, seus efeitos também são desmontados. Um recurso chave da renderização fora da tela é que você pode alternar a visibilidade de um componente sem perder seu estado. -Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados positivos de desempenho. Também melhoramos a forma como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará fallback do Suspense. Nosso trabalho restante envolve finalizar os primitivos que serão expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para teste e feedback. +Desde nossa última atualização, testamos uma versão experimental da pré-renderização internamente na Meta em nossos aplicativos React Native em Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com Suspense — suspender dentro de uma árvore offscreen não acionará os fallbacks do Suspense. Nosso trabalho restante envolve a finalização dos primitivos que são expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. -## Rastreamento de Transição {/*transition-tracing*/} +## Transition Tracing {/*transition-tracing*/} -A API de Rastreamento de Transição permite que você detecte quando [Transições React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente suspenso. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre Transições React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Transition Tracing permite que você detecte quando [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue o porquê de poderem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente em espera. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -Além desta atualização, nossa equipe fez aparições recentes em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. +Além desta atualização, nossa equipe fez recentes aparições como convidados em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder a perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes do Servidor React. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados do [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal do YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações relacionadas aos Componentes de Servidor do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam suas opiniões sobre o futuro do React. -Agradecimentos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão deste post. +Agradecemos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão desta postagem. -Obrigado por ler, e até a próxima atualização! \ No newline at end of file +Obrigado por ler e até a próxima atualização! \ No newline at end of file From 526b9a34e965fbeb4161225c763e83faa725998f Mon Sep 17 00:00:00 2001 From: Nivaldo Farias <badivia.f@gmail.com> Date: Mon, 20 Jan 2025 14:18:23 -0300 Subject: [PATCH 5/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 74 +++++++++---------- 1 file changed, 37 insertions(+), 37 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index 4b6772eed..9241c5326 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -1,8 +1,8 @@ --- -title: "React Labs: No que Estamos Trabalhando – Março de 2023" +title: "React Labs: No que estamos trabalhando – Março de 2023" author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark date: 2023/03/22 -description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. +description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progresso significativo neles desde a nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- 22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) @@ -11,7 +11,7 @@ description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa <Intro> -Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progressos significativos desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. +Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progresso significativo neles desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. </Intro> @@ -19,87 +19,87 @@ Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvim ## React Server Components {/*react-server-components*/} -React Server Components (ou RSC) é uma nova arquitetura de aplicativo projetada pela equipe do React. +Os React Server Components (ou RSC) são uma nova arquitetura de aplicação projetada pela equipe do React. -Compartilhamos inicialmente nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente—Componentes de Servidor—que são executados antecipadamente e são excluídos do seu pacote JavaScript. Os Componentes de Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por meio de props dos Componentes de Servidor para os Componentes Interativos do Cliente no navegador. +Compartilhamos pela primeira vez nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente--Componentes do Servidor--que são executados antes do tempo e são excluídos do seu bundle JavaScript. Os Componentes do Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por props dos Componentes do Servidor para os Componentes Interativos do Cliente no navegador. -RSC combina o simples modelo mental de "requisição/resposta" de Aplicativos Multi-Página centrados no servidor com a interatividade contínua de Aplicativos de Página Única centrados no cliente, oferecendo o melhor de ambos os mundos. +O RSC combina o simples modelo mental "solicitação/resposta" de aplicativos Multi-Página centrados em servidor com a interatividade sem costura dos aplicativos de Página Única centrados em cliente, oferecendo o melhor dos dois mundos. -Desde nossa última atualização, fundimos o [RFC dos Componentes de Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta das [Convenções de Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificações sobre o que uma implementação compatível com RSC deve suportar. +Desde nossa última atualização, unimos o [RFC dos React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta das [Convenções do Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para seguir a convenção `"use client"`. Esses documentos também atuam como especificação para o que uma implementação compatível com RSC deve suportar. -A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer a busca de dados a partir dos Componentes de Servidor. Também planejamos suportar o carregamento de dados a partir do cliente introduzindo um novo Hook chamado `use` que desvenda Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte quando você estruturar seu aplicativo somente do cliente de forma semelhante à estrutura dos aplicativos RSC. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer a busca de dados a partir dos Componentes do Servidor. Também planejamos suportar o carregamento de dados do cliente introduzindo um novo Hook chamado `use` que desembrulha Promessas. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte a isso quando você estruturar seu aplicativo apenas do cliente de maneira semelhante a como os aplicativos RSC são estruturados. -Agora que temos a busca de dados bem encaminhada, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso ao permitir que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, fornecendo RPC contínuo. As Ações do Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript seja carregado. +Agora que temos a busca de dados bem consolidada, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando RPC sem costura. As Ações do Servidor também dão a você formulários progressivamente aprimorados antes que o JavaScript seja carregado. -Os Componentes de Servidor do React foram implementados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota RSC como um primitivo, mas não é a única maneira de construir um roteador e um framework compatível com RSC. Existe uma clara separação para os recursos fornecidos pela especificação RSC e pela implementação. Os Componentes de Servidor do React são destinados a ser uma especificação para componentes que funcionam entre frameworks compatíveis com o React. +Os Componentes do Servidor do React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota o RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatíveis com RSC. Existe uma separação clara para as funcionalidades fornecidas pela especificação RSC e pela implementação. Os Componentes do Servidor do React são destinados a atuar como uma especificação para componentes que funcionam em frameworks compatíveis com o React. -Geralmente, recomendamos o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à profunda integração necessária com os empacotadores. A geração atual de empacotadores é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de empacotadores para que os primitivos para RSC sejam embutidos. +Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à integração profunda do bundler necessária. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de bundlers para que os primitivos para RSC sejam incorporados. ## Asset Loading {/*asset-loading*/} -[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está sendo carregada, assim como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam toda a história ao considerar se um novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na UI e mudanças consecutivas de layout. +[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está sendo carregada, bem como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam a história completa ao considerar se novo conteúdo está pronto. Por padrão, os navegadores carregam estilos, fontes e imagens de forma independente, o que pode levar a saltos na interface e mudanças consecutivas de layout. -Estamos trabalhando para integrar completamente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React leve isso em consideração ao determinar se o conteúdo está pronto para ser exibido. Sem qualquer alteração na forma como você cria seus componentes React, as atualizações se comportarão de maneira mais coerente e agradável. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos, como fontes, diretamente de componentes. +Estamos trabalhando para integrar completamente o Suspense com o ciclo de vida de carregamento de estilos, fontes e imagens, de modo que o React os considere para determinar se o conteúdo está pronto para ser exibido. Sem qualquer mudança na maneira como você escreve seus componentes React, as atualizações se comportarão de forma mais coerente e satisfatória. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. Atualmente, estamos implementando esses recursos e teremos mais para compartilhar em breve. ## Document Metadata {/*document-metadata*/} -Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição, e outras tags `<meta>` específicas para essa tela. Do ponto de vista da manutenção, é mais escalável manter essa informação próxima ao componente React daquela página ou tela. No entanto, as tags HTML para esse metadado precisam estar no `<head>` do documento, que normalmente é renderizado em um componente na raiz do seu aplicativo. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas ao componente React daquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que é normalmente renderizado em um componente na raiz do seu aplicativo. Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>`, e outras tags dentro dele para o `<head>` do documento. Isso funciona para navegadores principais, mas há muitos clientes que não executam JavaScript no lado do cliente, como parsers Open Graph, e essa técnica não é universalmente adequada. +Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas existem muitos clientes que não executam JavaScript do lado do cliente, como parsers do Open Graph, e assim, essa técnica não é universalmente adequada. Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todo o conteúdo ser renderizado antes de enviar o `<head>`. -É por isso que estamos adicionando suporte embutido para renderizar tags `<title>`, `<meta>`, e `<link>` de metadados em qualquer lugar da sua árvore de componentes, de forma automática. Isso funcionará da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. +É por isso que estamos adicionando suporte embutido para renderizar as tags `<title>`, `<meta>` e as tags de metadados `<link>` em qualquer lugar na árvore de componentes de forma nativa. Funcionaria da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. ## React Optimizing Compiler {/*react-optimizing-compiler*/} -Desde nossa última atualização, temos iterado ativamente sobre o design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizado para o React. Falamos anteriormente sobre ele como um "compilador de auto-memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador de *reatividade* automático. +Desde a nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizado para React. Já falamos sobre isso como um "compilador de auto-memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. -A ideia central do React é que os desenvolvedores definem sua UI como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa o idioma JavaScript padrão — if/else, for, etc — para descrever a lógica do seu componente. O modelo mental é que o React fará uma nova renderização sempre que o estado da aplicação mudar. Acreditamos que esse simples modelo mental e a manutenção próxima das semânticas do JavaScript são um princípio importante no modelo de programação do React. +A ideia central do React é que os desenvolvedores definem sua interface do usuário como uma função do estado atual. Você trabalha com valores de JavaScript simples — números, strings, arrays, objetos — e usa idiomatismos padrão de JavaScript — if/else, for, etc — para descrever a lógica de seu componente. O modelo mental é que o React re-renderizará sempre que o estado da aplicação mudar. Acreditamos que esse modelo mental simples e a proximidade com a semântica do JavaScript são um princípio importante no modelo de programação do React. -O problema é que o React pode, às vezes, ser *demais* reativo: pode renderizar novamente demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (têm as mesmas chaves e valores), portanto, criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar explicitamente os componentes para não reagir demais às mudanças. +O problema é que o React pode às vezes ser *demais* reativo: pode re-renderizar demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memorizar explicitamente componentes para não reagir excessivamente a mudanças. -Nosso objetivo com o React Forget é garantir que os aplicativos React tenham apenas a quantidade certa de reatividade por padrão: que os aplicativos sejam renderizados novamente apenas quando os valores de estado mudarem *significativamente*. De uma perspectiva de implementação, isso significa memoizar automaticamente, mas acreditamos que a estruturação da reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente renderiza novamente quando a identidade do objeto muda. Com o Forget, o React renderiza novamente quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem somente quando os valores de estado *mudam de forma significativa*. Do ponto de vista de implementação, isso significa memorização automática, mas acreditamos que a estrutura de reatividade é uma melhor forma de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. -Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso interno do compilador. Após algumas refatorações significativas no compilador a partir do final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos disponibilizá-lo como código aberto uma vez que tivermos provado sua eficácia em produção. +Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente sobre o design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso do compilador internamente. Após algumas refatorações significativas do compilador começando no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo de código aberto assim que o provamos em produção. -Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando provarmos o compilador e o tornarmos de código aberto. Mas há algumas informações que podemos compartilhar agora: +Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar muitos mais detalhes quando comprovamos o compilador e o tornamos de código aberto. Mas há algumas informações que podemos compartilhar agora: -O núcleo do compilador está quase completamente desacoplado do Babel, e a API principal do compilador é (aproximadamente) AST antigo de entrada, novo AST de saída (mantendo os dados de localização de origem). Por baixo dos panos, usamos uma representação personalizada de código e um pipeline de transformação para realizar uma análise semântica de baixo nível. No entanto, a interface pública principal do compilador será através do Babel e de outros plugins do sistema de construção. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada muito fina que chama o compilador para gerar uma nova versão de cada função e a troca. +O núcleo do compilador está quase completamente desacoplado do Babel, e a API central do compilador é (aproximadamente) antigo AST entra, novo AST sai (enquanto mantém os dados de localização do código). Por trás das cenas, usamos uma representação e um pipeline de transformação de código personalizados para realizar análise semântica de baixo nível. No entanto, a interface pública principal para o compilador será através do Babel e de outros plugins do sistema de construção. Para facilidade de teste, atualmente temos um plugin Babel que é um envoltório muito fino que chama o compilador para gerar uma nova versão de cada função e substituí-la. -À medida que refatoramos o compilador nos últimos meses, queríamos focar em refinar o modelo de compilação central para garantir que pudéssemos lidar com complexidades como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript possui muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar suportar toda a linguagem desde o início teria atrasado o momento em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos repositórios de código da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses próximos. Continuaremos expandindo progressivamente para suportar toda a linguagem. +À medida que refatoramos o compilador nos últimos meses, queríamos nos concentrar em refinar o modelo de compilação central para garantir que conseguimos lidar com complexidades como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript tem muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar dar suporte ao conjunto completo da linguagem desde o início teria atrasado o ponto em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, ampliamos o subconjunto da linguagem suportada. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são os mais comuns, para que possamos priorizá-los a seguir. Continuaremos expandindo gradualmente para suportar toda a linguagem. -Tornar o JavaScript simples em componentes React reativo requer um compilador com uma compreensão profunda das semânticas para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produção de qualquer complexidade com toda a expressividade da linguagem, em vez de ficar limitado a uma linguagem específica de domínio. +Tornar o JavaScript simples nos componentes do React reativo exige um compilador com uma profunda compreensão da semântica para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com toda a expressividade da linguagem, em vez de ser limitado a uma linguagem específica de domínio. ## Offscreen Rendering {/*offscreen-rendering*/} -A renderização fora da tela é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga adicional de desempenho. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: +A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga de desempenho adicional. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, elas estejam instantaneamente disponíveis. -- Um componente de troca de abas pode preservar o estado de abas ocultas, para que o usuário possa alternar entre elas sem perder seu progresso. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. +- Um componente de troca de abas pode preservar o estado das abas ocultas, para que o usuário possa alternar entre elas sem perder seu progresso. - Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. -- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo" para que eventos e atualizações sejam desativados para tudo, exceto o modal. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo", de modo que eventos e atualizações sejam desativados para tudo, exceto o modal. -A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de UI, e os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. +A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de UI, e então os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. -A ideia é que você deva ser capaz de renderizar qualquer árvore React fora da tela sem mudar a forma como escreve seus componentes. Quando um componente é renderizado fora da tela, ele não é realmente *montado* até que o componente se torne visível — seus efeitos não são disparados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não afetará a precisão dessas análises. Da mesma forma, quando um componente sai da tela, seus efeitos também são desmontados. Um recurso chave da renderização fora da tela é que você pode alternar a visibilidade de um componente sem perder seu estado. +A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como você escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* até que o componente se torne visível — seus efeitos não são disparados. Por exemplo, se um componente usa `useEffect` para registrar análises quando ele aparece pela primeira vez, a pré-renderização não bagunçará a precisão dessas análises. Da mesma forma, quando um componente vai para offscreen, seus efeitos também são desmontados. Uma característica chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. -Desde nossa última atualização, testamos uma versão experimental da pré-renderização internamente na Meta em nossos aplicativos React Native em Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com Suspense — suspender dentro de uma árvore offscreen não acionará os fallbacks do Suspense. Nosso trabalho restante envolve a finalização dos primitivos que são expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC ainda este ano, juntamente com uma API experimental para testes e feedback. +Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará as opções de fallback do Suspense. Nosso trabalho restante envolve finalizar os primitivos que são expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC mais tarde este ano, juntamente com uma API experimental para testes e feedback. ## Transition Tracing {/*transition-tracing*/} -A API de Transition Tracing permite que você detecte quando [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue o porquê de poderem estar lentas. Após nossa última atualização, completamos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente em espera. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Rastreio de Transições permite que você detecte quando as [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, concluímos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente pausado. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma melhor ferramenta de medição de desempenho para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -Além desta atualização, nossa equipe fez recentes aparições como convidados em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder a perguntas. +Além dessa atualização, nossa equipe tem feito aparições recentes em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal do YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações relacionadas aos Componentes de Servidor do React. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam suas opiniões sobre o futuro do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes do Servidor do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. -Agradecemos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão desta postagem. +Agradecemos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster) e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão desta postagem. Obrigado por ler e até a próxima atualização! \ No newline at end of file From 31aebfe5289ab654adc0fc87883b95c05d871814 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias <badivia.f@gmail.com> Date: Mon, 20 Jan 2025 14:23:57 -0300 Subject: [PATCH 6/6] Translate `react-labs-what-we-have-been-working-on-march-2023.md` to pt-br --- ...what-we-have-been-working-on-march-2023.md | 86 +++++++++---------- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md index 9241c5326..25f4a417b 100644 --- a/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md +++ b/src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md @@ -2,7 +2,7 @@ title: "React Labs: No que estamos trabalhando – Março de 2023" author: Joseph Savona, Josh Story, Lauren Tan, Mengdi Chen, Samuel Susla, Sathya Gunasekaran, Sebastian Markbage, e Andrew Clark date: 2023/03/22 -description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progresso significativo neles desde a nossa última atualização e gostaríamos de compartilhar o que aprendemos. +description: Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativos. Fizemos progresso significativo desde nossa última atualização e gostaríamos de compartilhar o que aprendemos. --- 22 de março de 2023 por [Joseph Savona](https://twitter.com/en_JS), [Josh Story](https://twitter.com/joshcstory), [Lauren Tan](https://twitter.com/potetotes), [Mengdi Chen](https://twitter.com/mengdi_en), [Samuel Susla](https://twitter.com/SamuelSusla), [Sathya Gunasekaran](https://twitter.com/_gsathya), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) @@ -11,7 +11,7 @@ description: Nas postagens do React Labs, escrevemos sobre projetos em pesquisa <Intro> -Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativo. Fizemos progresso significativo neles desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. +Nos posts do React Labs, escrevemos sobre projetos em pesquisa e desenvolvimento ativos. Fizemos progresso significativo desde nossa [última atualização](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022) e gostaríamos de compartilhar o que aprendemos. </Intro> @@ -19,87 +19,87 @@ Nas postagens do React Labs, escrevemos sobre projetos em pesquisa e desenvolvim ## React Server Components {/*react-server-components*/} -Os React Server Components (ou RSC) são uma nova arquitetura de aplicação projetada pela equipe do React. +React Server Components (ou RSC) é uma nova arquitetura de aplicação projetada pela equipe do React. -Compartilhamos pela primeira vez nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente--Componentes do Servidor--que são executados antes do tempo e são excluídos do seu bundle JavaScript. Os Componentes do Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por props dos Componentes do Servidor para os Componentes Interativos do Cliente no navegador. +Compartilhamos pela primeira vez nossa pesquisa sobre RSC em uma [palestra introdutória](/blog/2020/12/21/data-fetching-with-react-server-components) e em um [RFC](https://github.com/reactjs/rfcs/pull/188). Para recapitular, estamos introduzindo um novo tipo de componente — Componentes do Servidor — que são executados antecipadamente e são excluídos do seu pacote JavaScript. Os Componentes do Servidor podem ser executados durante a construção, permitindo que você leia do sistema de arquivos ou busque conteúdo estático. Eles também podem ser executados no servidor, permitindo que você acesse sua camada de dados sem precisar construir uma API. Você pode passar dados por props dos Componentes do Servidor para os Componentes Interativos do Cliente no navegador. -O RSC combina o simples modelo mental "solicitação/resposta" de aplicativos Multi-Página centrados em servidor com a interatividade sem costura dos aplicativos de Página Única centrados em cliente, oferecendo o melhor dos dois mundos. +RSC combina o simples modelo mental de "requisito/resposta" de Aplicativos Múltiplas Páginas centrados no servidor com a interatividade perfeita de Aplicativos de Página Única centrados no cliente, oferecendo o melhor dos dois mundos. -Desde nossa última atualização, unimos o [RFC dos React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos questões pendentes com a proposta das [Convenções do Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para seguir a convenção `"use client"`. Esses documentos também atuam como especificação para o que uma implementação compatível com RSC deve suportar. +Desde nossa última atualização, fundimos o [React Server Components RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) para ratificar a proposta. Resolvemos problemas pendentes com a proposta das [Convenções de Módulo do Servidor do React](https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md) e chegamos a um consenso com nossos parceiros para adotar a convenção `"use client"`. Esses documentos também atuam como especificação para o que uma implementação compatível com RSC deve suportar. -A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal maneira de fazer a busca de dados a partir dos Componentes do Servidor. Também planejamos suportar o carregamento de dados do cliente introduzindo um novo Hook chamado `use` que desembrulha Promessas. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos apenas do cliente, planejamos adicionar suporte a isso quando você estruturar seu aplicativo apenas do cliente de maneira semelhante a como os aplicativos RSC são estruturados. +A maior mudança é que introduzimos [`async` / `await`](https://github.com/reactjs/rfcs/pull/229) como a principal forma de fazer a busca de dados a partir dos Componentes do Servidor. Também planejamos suportar a carga de dados do cliente, introduzindo um novo Hook chamado `use`, que desembrulha Promises. Embora não possamos suportar `async / await` em componentes arbitrários em aplicativos somente do cliente, planejamos adicionar suporte quando você estruturar seu aplicativo somente do cliente semelhante a como os aplicativos RSC são estruturados. -Agora que temos a busca de dados bem consolidada, estamos explorando a outra direção: enviar dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ação do Servidor através da fronteira servidor/cliente, que o cliente pode então chamar, proporcionando RPC sem costura. As Ações do Servidor também dão a você formulários progressivamente aprimorados antes que o JavaScript seja carregado. +Agora que temos a busca de dados bem resolvida, estamos explorando a outra direção: enviando dados do cliente para o servidor, para que você possa executar mutações de banco de dados e implementar formulários. Estamos fazendo isso permitindo que você passe funções de Ação do Servidor pela fronteira servidor/cliente, que o cliente pode então chamar, proporcionando RPC perfeito. As Ações do Servidor também oferecem formulários progressivamente aprimorados antes que o JavaScript seja carregado. -Os Componentes do Servidor do React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota o RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatíveis com RSC. Existe uma separação clara para as funcionalidades fornecidas pela especificação RSC e pela implementação. Os Componentes do Servidor do React são destinados a atuar como uma especificação para componentes que funcionam em frameworks compatíveis com o React. +Os Componentes do Servidor do React foram lançados no [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). Isso demonstra uma integração profunda de um roteador que realmente adota RSC como um primitivo, mas não é a única maneira de construir um roteador e framework compatível com RSC. Existe uma clara separação para recursos fornecidos pela especificação e implementação de RSC. Os Componentes do Servidor do React são destinados a ser uma especificação para componentes que funcionam em frameworks React compatíveis. -Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos, principalmente devido à integração profunda do bundler necessária. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que agora estamos fazendo parceria diretamente com desenvolvedores de bundlers para que os primitivos para RSC sejam incorporados. +Recomendamos geralmente o uso de um framework existente, mas se você precisar construir seu próprio framework personalizado, isso é possível. Construir seu próprio framework compatível com RSC não é tão fácil quanto gostaríamos que fosse, principalmente devido à profunda integração necessária com o bundler. A geração atual de bundlers é ótima para uso no cliente, mas não foi projetada com suporte de primeira classe para dividir um único gráfico de módulo entre o servidor e o cliente. É por isso que estamos agora colaborando diretamente com desenvolvedores de bundler para obter os primitivos para RSC incorporados. -## Asset Loading {/*asset-loading*/} +## Carregamento de Ativos {/*asset-loading*/} -[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código para seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está sendo carregada, bem como durante as navegações do roteador que carregam mais dados e código. No entanto, da perspectiva do usuário, o carregamento de dados e a renderização não contam a história completa ao considerar se novo conteúdo está pronto. Por padrão, os navegadores carregam estilos, fontes e imagens de forma independente, o que pode levar a saltos na interface e mudanças consecutivas de layout. +[Suspense](/reference/react/Suspense) permite que você especifique o que exibir na tela enquanto os dados ou o código de seus componentes ainda estão sendo carregados. Isso permite que seus usuários vejam progressivamente mais conteúdo enquanto a página está carregando, assim como durante as navegações do roteador que carregam mais dados e código. Porém, na perspectiva do usuário, o carregamento de dados e renderização não conta toda a história ao considerar se novo conteúdo está pronto. Por padrão, os navegadores carregam folhas de estilo, fontes e imagens de forma independente, o que pode levar a saltos na UI e mudanças de layout consecutivas. -Estamos trabalhando para integrar completamente o Suspense com o ciclo de vida de carregamento de estilos, fontes e imagens, de modo que o React os considere para determinar se o conteúdo está pronto para ser exibido. Sem qualquer mudança na maneira como você escreve seus componentes React, as atualizações se comportarão de forma mais coerente e satisfatória. Como uma otimização, também forneceremos uma maneira manual de pré-carregar ativos como fontes diretamente dos componentes. +Estamos trabalhando para integrar totalmente o Suspense com o ciclo de carregamento de folhas de estilo, fontes e imagens, para que o React os leve em conta para determinar se o conteúdo está pronto para ser exibido. Sem qualquer mudança na forma como você escreve seus componentes React, as atualizações se comportarão de maneira mais coerente e agradável. Como uma otimização, também forneceremos uma forma manual para pré-carregar ativos como fontes diretamente dos componentes. Atualmente, estamos implementando esses recursos e teremos mais para compartilhar em breve. -## Document Metadata {/*document-metadata*/} +## Metadados do Documento {/*document-metadata*/} -Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para esta tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas ao componente React daquela página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que é normalmente renderizado em um componente na raiz do seu aplicativo. +Diferentes páginas e telas em seu aplicativo podem ter metadados diferentes, como a tag `<title>`, descrição e outras tags `<meta>` específicas para essa tela. Do ponto de vista de manutenção, é mais escalável manter essas informações próximas ao componente React para essa página ou tela. No entanto, as tags HTML para esses metadados precisam estar no `<head>` do documento, que normalmente é renderizado em um componente na raiz do seu aplicativo. Hoje, as pessoas resolvem esse problema com uma das duas técnicas. -Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para os principais navegadores, mas existem muitos clientes que não executam JavaScript do lado do cliente, como parsers do Open Graph, e assim, essa técnica não é universalmente adequada. +Uma técnica é renderizar um componente especial de terceiros que move `<title>`, `<meta>` e outras tags dentro dele para o `<head>` do documento. Isso funciona para principais navegadores, mas existem muitos clientes que não executam JavaScript do lado do cliente, como analisadores do Open Graph, e, portanto, essa técnica não é universalmente adequada. -Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que esperar todo o conteúdo ser renderizado antes de enviar o `<head>`. +Outra técnica é renderizar o servidor a página em duas partes. Primeiro, o conteúdo principal é renderizado e todas essas tags são coletadas. Em seguida, o `<head>` é renderizado com essas tags. Finalmente, o `<head>` e o conteúdo principal são enviados para o navegador. Essa abordagem funciona, mas impede que você aproveite o [Renderizador de Servidor em Streaming do React 18](/reference/react-dom/server/renderToReadableStream) porque você teria que aguardar toda a renderização do conteúdo antes de enviar o `<head>`. -É por isso que estamos adicionando suporte embutido para renderizar as tags `<title>`, `<meta>` e as tags de metadados `<link>` em qualquer lugar na árvore de componentes de forma nativa. Funcionaria da mesma maneira em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. +É por isso que estamos adicionando suporte incorporado para renderizar tags `<title>`, `<meta>` e metadados `<link>` em qualquer lugar na árvore de componentes fora da caixa. Isso funcionaria da mesma forma em todos os ambientes, incluindo código totalmente do lado do cliente, SSR e, no futuro, RSC. Compartilharemos mais detalhes sobre isso em breve. -## React Optimizing Compiler {/*react-optimizing-compiler*/} +## Compilador Otimizador do React {/*react-optimizing-compiler*/} -Desde a nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizado para React. Já falamos sobre isso como um "compilador de auto-memorização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais profundamente o modelo de programação do React. Uma maneira melhor de entender o React Forget é como um compilador automático de *reatividade*. +Desde nossa atualização anterior, temos iterado ativamente no design do [React Forget](/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler), um compilador otimizador para o React. Já falamos sobre ele como um "compilador de auto-memoização", e isso é verdade em certo sentido. Mas construir o compilador nos ajudou a entender ainda mais o modelo de programação do React. Uma melhor maneira de entender o React Forget é como um compilador automático de *reatividade*. -A ideia central do React é que os desenvolvedores definem sua interface do usuário como uma função do estado atual. Você trabalha com valores de JavaScript simples — números, strings, arrays, objetos — e usa idiomatismos padrão de JavaScript — if/else, for, etc — para descrever a lógica de seu componente. O modelo mental é que o React re-renderizará sempre que o estado da aplicação mudar. Acreditamos que esse modelo mental simples e a proximidade com a semântica do JavaScript são um princípio importante no modelo de programação do React. +A ideia central do React é que os desenvolvedores definem sua UI como uma função do estado atual. Você trabalha com valores JavaScript simples — números, strings, arrays, objetos — e usa idiomatismos padrão de JavaScript — if/else, for, etc. — para descrever a lógica do seu componente. O modelo mental é que o React irá re-renderizar sempre que o estado da aplicação mudar. Acreditamos que esse modelo mental simples e a proximidade com a semântica do JavaScript são princípios importantes no modelo de programação do React. -O problema é que o React pode às vezes ser *demais* reativo: pode re-renderizar demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array em cada renderização pode fazer com que o React faça mais trabalho do que realmente precisa. Isso significa que os desenvolvedores têm que memorizar explicitamente componentes para não reagir excessivamente a mudanças. +O problema é que o React pode, às vezes, ser *demais* reativo: ele pode re-renderizar demais. Por exemplo, em JavaScript não temos maneiras baratas de comparar se dois objetos ou arrays são equivalentes (tendo as mesmas chaves e valores), então criar um novo objeto ou array a cada renderização pode causar mais trabalho para o React do que realmente precisa. Isso significa que os desenvolvedores têm que memoizar explicitamente componentes para não reagir excessivamente às mudanças. -Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem somente quando os valores de estado *mudam de forma significativa*. Do ponto de vista de implementação, isso significa memorização automática, mas acreditamos que a estrutura de reatividade é uma melhor forma de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. +Nosso objetivo com o React Forget é garantir que os aplicativos React tenham a quantidade certa de reatividade por padrão: que os aplicativos re-renderizem apenas quando os valores de estado *mudam de forma significativa*. Do ponto de vista de implementação, isso significa memoização automática, mas acreditamos que o enquadramento da reatividade é uma maneira melhor de entender o React e o Forget. Uma maneira de pensar sobre isso é que o React atualmente re-renderiza quando a identidade do objeto muda. Com o Forget, o React re-renderiza quando o valor semântico muda — mas sem incorrer no custo de tempo de execução de comparações profundas. -Em termos de progresso concreto, desde nossa última atualização, iteramos substancialmente sobre o design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso do compilador internamente. Após algumas refatorações significativas do compilador começando no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos torná-lo de código aberto assim que o provamos em produção. +Em termos de progresso concreto, desde nossa última atualização, nós iteramos substancialmente no design do compilador para alinhar com essa abordagem de reatividade automática e incorporar feedback do uso interno do compilador. Após algumas refatorações significativas no compilador, que começaram no final do ano passado, agora começamos a usar o compilador em produção em áreas limitadas na Meta. Planejamos open source assim que tivermos provado sua eficácia na produção. -Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar muitos mais detalhes quando comprovamos o compilador e o tornamos de código aberto. Mas há algumas informações que podemos compartilhar agora: +Finalmente, muitas pessoas expressaram interesse em como o compilador funciona. Estamos ansiosos para compartilhar mais detalhes quando validarmos e torná-lo open source. Mas há algumas informações que podemos compartilhar agora: -O núcleo do compilador está quase completamente desacoplado do Babel, e a API central do compilador é (aproximadamente) antigo AST entra, novo AST sai (enquanto mantém os dados de localização do código). Por trás das cenas, usamos uma representação e um pipeline de transformação de código personalizados para realizar análise semântica de baixo nível. No entanto, a interface pública principal para o compilador será através do Babel e de outros plugins do sistema de construção. Para facilidade de teste, atualmente temos um plugin Babel que é um envoltório muito fino que chama o compilador para gerar uma nova versão de cada função e substituí-la. +O núcleo do compilador está quase completamente desacoplado do Babel, e a API central do compilador é (aproximadamente) AST antigo para AST novo (enquanto retém os dados de localização de origem). Sob o capô, usamos uma representação de código personalizada e um pipeline de transformação para fazer uma análise semântica de baixo nível. No entanto, a interface pública principal para o compilador será via Babel e outros plugins do sistema de build. Para facilitar os testes, atualmente temos um plugin do Babel que é uma camada fina que chama o compilador para gerar uma nova versão de cada função e substituí-la. -À medida que refatoramos o compilador nos últimos meses, queríamos nos concentrar em refinar o modelo de compilação central para garantir que conseguimos lidar com complexidades como condicionais, loops, reatribuição e mutação. No entanto, o JavaScript tem muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar dar suporte ao conjunto completo da linguagem desde o início teria atrasado o ponto em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo da linguagem: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de função e alguns outros recursos. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, ampliamos o subconjunto da linguagem suportada. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são os mais comuns, para que possamos priorizá-los a seguir. Continuaremos expandindo gradualmente para suportar toda a linguagem. +À medida que refatoramos o compilador nos últimos meses, queríamos nos concentrar em refinar o modelo central de compilação para garantir que pudéssemos lidar com complexidades, como condicionais, loops, reatribuições e mutações. No entanto, o JavaScript tem muitas maneiras de expressar cada um desses recursos: if/else, ternários, for, for-in, for-of, etc. Tentar suportar todo o idioma desde o início teria atrasado o ponto em que poderíamos validar o modelo central. Em vez disso, começamos com um subconjunto pequeno, mas representativo do idioma: let/const, if/else, loops for, objetos, arrays, primitivos, chamadas de funções e alguns outros recursos. À medida que ganhamos confiança no modelo central e refinamos nossas abstrações internas, expandimos o subconjunto de linguagem suportado. Também somos explícitos sobre a sintaxe que ainda não suportamos, registrando diagnósticos e pulando a compilação para entradas não suportadas. Temos utilitários para testar o compilador nos códigos da Meta e ver quais recursos não suportados são mais comuns, para que possamos priorizar esses próximos. Continuaremos expandindo gradualmente para suportar toda a linguagem. -Tornar o JavaScript simples nos componentes do React reativo exige um compilador com uma profunda compreensão da semântica para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema de reatividade dentro do JavaScript que permite que você escreva código de produto de qualquer complexidade com toda a expressividade da linguagem, em vez de ser limitado a uma linguagem específica de domínio. +Tornar o JavaScript simples em componentes React reativos requer um compilador com um entendimento profundo da semântica, para que ele possa entender exatamente o que o código está fazendo. Ao adotar essa abordagem, estamos criando um sistema para reatividade dentro do JavaScript que permite que você escreva código de produção de qualquer complexidade com toda a expressividade da linguagem, em vez de ser limitado a uma linguagem específica de domínio. -## Offscreen Rendering {/*offscreen-rendering*/} +## Renderização Offscreen {/*offscreen-rendering*/} -A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga de desempenho adicional. Você pode pensar nisso como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: +A renderização offscreen é uma capacidade futura no React para renderizar telas em segundo plano sem sobrecarga de desempenho adicional. Você pode pensar nela como uma versão da propriedade CSS [`content-visibility`](https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility) que funciona não apenas para elementos DOM, mas também para componentes React. Durante nossa pesquisa, descobrimos uma variedade de casos de uso: -- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, estejam instantaneamente disponíveis. -- Um componente de troca de abas pode preservar o estado das abas ocultas, para que o usuário possa alternar entre elas sem perder seu progresso. +- Um roteador pode pré-renderizar telas em segundo plano para que, quando um usuário navega até elas, elas estejam instantaneamente disponíveis. +- Um componente de troca de abas pode preservar o estado de abas ocultas, para que o usuário possa alternar entre elas sem perder seu progresso. - Um componente de lista virtualizada pode pré-renderizar linhas adicionais acima e abaixo da janela visível. -- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado em modo "fundo", de modo que eventos e atualizações sejam desativados para tudo, exceto o modal. +- Ao abrir um modal ou popup, o restante do aplicativo pode ser colocado no modo "segundo plano", de modo que eventos e atualizações sejam desativados para tudo, exceto o modal. -A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de UI, e então os desenvolvedores que usam essas bibliotecas se beneficiarão automaticamente sem trabalho adicional. +A maioria dos desenvolvedores React não interagirá diretamente com as APIs offscreen do React. Em vez disso, a renderização offscreen será integrada a coisas como roteadores e bibliotecas de UI, e os desenvolvedores que usam essas bibliotecas automaticamente se beneficiarão sem trabalho adicional. -A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como você escreve seus componentes. Quando um componente é renderizado offscreen, ele não *monta* até que o componente se torne visível — seus efeitos não são disparados. Por exemplo, se um componente usa `useEffect` para registrar análises quando ele aparece pela primeira vez, a pré-renderização não bagunçará a precisão dessas análises. Da mesma forma, quando um componente vai para offscreen, seus efeitos também são desmontados. Uma característica chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. +A ideia é que você deve ser capaz de renderizar qualquer árvore React offscreen sem mudar a maneira como você escreve seus componentes. Quando um componente é renderizado offscreen, ele não realmente *monta* até que o componente se torne visível — seus efeitos não são ativados. Por exemplo, se um componente usa `useEffect` para registrar análises quando aparece pela primeira vez, a pré-renderização não prejudicará a precisão dessas análises. Da mesma forma, quando um componente vai para offscreen, seus efeitos também são desmontados. Um recurso chave da renderização offscreen é que você pode alternar a visibilidade de um componente sem perder seu estado. -Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará as opções de fallback do Suspense. Nosso trabalho restante envolve finalizar os primitivos que são expostos aos desenvolvedores de bibliotecas. Esperamos publicar um RFC mais tarde este ano, juntamente com uma API experimental para testes e feedback. +Desde nossa última atualização, testamos uma versão experimental de pré-renderização internamente na Meta em nossos aplicativos React Native no Android e iOS, com resultados de desempenho positivos. Também melhoramos como a renderização offscreen funciona com o Suspense — suspender dentro de uma árvore offscreen não acionará fallbacks do Suspense. Nosso trabalho restante envolve a finalização dos primitivos que são expostos aos desenvolvedores de biblioteca. Esperamos publicar um RFC mais tarde este ano, juntamente com uma API experimental para testes e feedback. -## Transition Tracing {/*transition-tracing*/} +## Rastreio de Transitions {/*transition-tracing*/} -A API de Rastreio de Transições permite que você detecte quando as [Transições do React](/reference/react/useTransition) se tornam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, concluímos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente pausado. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma melhor ferramenta de medição de desempenho para o React. Isso será particularmente útil com roteadores construídos sobre as Transições do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). +A API de Rastreio de Transitions permite que você detecte quando as [Transitions do React](/reference/react/useTransition) ficam mais lentas e investigue por que podem estar lentas. Após nossa última atualização, concluímos o design inicial da API e publicamos um [RFC](https://github.com/reactjs/rfcs/pull/238). As capacidades básicas também foram implementadas. O projeto está atualmente em espera. Agradecemos o feedback sobre o RFC e esperamos retomar seu desenvolvimento para fornecer uma ferramenta de medição de desempenho melhor para o React. Isso será particularmente útil com roteadores construídos sobre as Transitions do React, como o [Next.js App Router](/learn/start-a-new-react-project#nextjs-app-router). * * * -Além dessa atualização, nossa equipe tem feito aparições recentes em podcasts e transmissões ao vivo da comunidade para falar mais sobre nosso trabalho e responder perguntas. +Além desta atualização, nossa equipe fez aparições recentes como convidados em podcasts comunitários e transmissões ao vivo para falar mais sobre nosso trabalho e responder perguntas. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal no YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes do Servidor do React. -* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam seus pensamentos sobre o futuro do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram entrevistados por [Kent C. Dodds em seu canal do YouTube](https://www.youtube.com/watch?v=h7tur48JSaw), onde discutiram preocupações em torno dos Componentes do Servidor do React. +* [Dan Abramov](https://twitter.com/dan_abramov) e [Joe Savona](https://twitter.com/en_JS) foram convidados no [podcast JSParty](https://jsparty.fm/267) e compartilharam suas opiniões sobre o futuro do React. -Agradecemos a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster) e [Sophie Alpert](https://twitter.com/sophiebits) pela revisão desta postagem. +Obrigado a [Andrew Clark](https://twitter.com/acdlite), [Dan Abramov](https://twitter.com/dan_abramov), [Dave McCabe](https://twitter.com/mcc_abe), [Luna Wei](https://twitter.com/lunaleaps), [Matt Carroll](https://twitter.com/mattcarrollcode), [Sean Keegan](https://twitter.com/DevRelSean), [Sebastian Silbermann](https://twitter.com/sebsilbermann), [Seth Webster](https://twitter.com/sethwebster), e [Sophie Alpert](https://twitter.com/sophiebits) por revisarem este post. -Obrigado por ler e até a próxima atualização! \ No newline at end of file +Obrigado por ler e nos vemos na próxima atualização! \ No newline at end of file