From fe1aa7cba98e4d2e28df6151e472734503d0ad1d Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 11:07:29 -0300 Subject: [PATCH 1/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 91 +++++++++---------- 1 file changed, 44 insertions(+), 47 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index 19d9960b0..5dd00a501 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Enabling Incremental Feature Rollout Outside Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, and Andrew Clark +title: "React Canaries: Habilitando Implementações Incrementais de Funcionalidades Fora da Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark date: 2023/05/03 -description: We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final, before they're released in a stable version--similar to how Meta has long used bleeding-edge versions of React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. +description: Gostaríamos de oferecer à comunidade React a opção de adotar novas funcionalidades individuais assim que seu design estiver próximo do final, antes de serem lançadas em uma versão estável - semelhante a como a Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de funcionalidades individuais do React da programação de lançamentos do React. --- -May 3, 2023 by [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), and [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) --- -We'd like to offer the React community an option to adopt individual new features as soon as their design is close to final, before they're released in a stable version--similar to how Meta has long used bleeding-edge versions of React internally. We are introducing a new officially supported [Canary release channel](/community/versioning-policy#canary-channel). It lets curated setups like frameworks decouple adoption of individual React features from the React release schedule. +Gostaríamos de oferecer à comunidade React a opção de adotar novas funcionalidades individuais assim que seu design estiver próximo do final, antes de serem lançadas em uma versão estável - semelhante a como a Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de funcionalidades individuais do React da programação de lançamentos do React. @@ -19,79 +19,76 @@ We'd like to offer the React community an option to adopt individual new feature ## tl;dr {/*tldr*/} -* We're introducing an officially supported [Canary release channel](/community/versioning-policy#canary-channel) for React. Since it's officially supported, if any regressions land, we'll treat them with a similar urgency to bugs in stable releases. -* Canaries let you start using individual new React features before they land in the semver-stable releases. -* Unlike the [Experimental](/community/versioning-policy#experimental-channel) channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases. -* We will announce breaking changes and new features on our blog as they land in Canary releases. -* **As always, React continues to follow semver for every Stable release.** +* Estamos introduzindo um [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se regressões ocorrerem, iremos tratá-las com a mesma urgência que erros em lançamentos estáveis. +* Canaries permitem que você comece a usar novas funcionalidades individuais do React antes que elas cheguem às versões semver-estáveis. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas funcionalidades que acreditamos razoavelmente que estão prontas para adoção. Incentivamos frameworks a considerar a inclusão de versões Canary do React fixadas. +* Anunciaremos mudanças breaking e novas funcionalidades em nosso blog assim que elas chegarem às releases Canary. +* **Como sempre, o React continua a seguir semver para cada release Estável.** -## How React features are usually developed {/*how-react-features-are-usually-developed*/} +## Como as funcionalidades do React são normalmente desenvolvidas {/*how-react-features-are-usually-developed*/} -Typically, every React feature has gone through the same stages: +Tipicamente, cada funcionalidade do React passa pelas mesmas etapas: -1. We develop an initial version and prefix it with `experimental_` or `unstable_`. The feature is only available in the `experimental` release channel. At this point, the feature is expected to change significantly. -2. We find a team at Meta willing to help us test this feature and provide feedback on it. This leads to a round of changes. As the feature becomes more stable, we work with more teams at Meta to try it out. -3. Eventually, we feel confident in the design. We remove the prefix from the API name, and make the feature available on the `main` branch by default, which most Meta products use. At this point, any team at Meta can use this feature. -4. As we build confidence in the direction, we also post an RFC for the new feature. At this point we know the design works for a broad set of cases, but we might make some last minute adjustments. -5. When we are close to cutting an open source release, we write documentation for the feature and finally release the feature in a stable React release. +1. Desenvolvemos uma versão inicial e prefixamos com `experimental_` ou `unstable_`. A funcionalidade está disponível apenas no canal de release `experimental`. Neste ponto, espera-se que a funcionalidade mude significativamente. +2. Encontramos uma equipe na Meta disposta a nos ajudar a testar essa funcionalidade e fornecer feedback sobre ela. Isso leva a uma rodada de mudanças. À medida que a funcionalidade se torna mais estável, trabalhamos com mais equipes na Meta para testá-la. +3. Eventualmente, nos sentimos confiantes no design. Removemos o prefixo do nome da API e disponibilizamos a funcionalidade no branch `main` por padrão, que a maioria dos produtos da Meta utiliza. Neste ponto, qualquer equipe da Meta pode usar essa funcionalidade. +4. À medida que aumentamos a confiança na direção, também postamos um RFC para a nova funcionalidade. Neste ponto, sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos próximos de lançar uma versão open source, escrevemos a documentação para a funcionalidade e finalmente lançamos a funcionalidade em uma versão estável do React. -This playbook works well for most features we've released so far. However, there can be a significant gap between when the feature is generally ready to use (step 3) and when it is released in open source (step 5). +Este playbook funciona bem para a maioria das funcionalidades que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando a funcionalidade está geralmente pronta para uso (passo 3) e quando é lançada como open source (passo 5). -**We'd like to offer the React community an option to follow the same approach as Meta, and adopt individual new features earlier (as they become available) without having to wait for the next release cycle of React.** +**Gostaríamos de oferecer à comunidade React a opção de seguir a mesma abordagem que a Meta e adotar novas funcionalidades individuais mais cedo (à medida que ficam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** -As always, all React features will eventually make it into a Stable release. +Como sempre, todas as funcionalidades do React eventualmente estarão em uma release Estável. -## Can we just do more minor releases? {/*can-we-just-do-more-minor-releases*/} +## Podemos apenas fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} -Generally, we *do* use minor releases for introducing new features. +De maneira geral, *nós* usamos lançamentos menores para introduzir novas funcionalidades. -However, this isn't always possible. Sometimes, new features are interconnected with *other* new features which have not yet been fully completed and that we're still actively iterating on. We can't release them separately because their implementations are related. We can't version them separately because they affect the same packages (for example, `react` and `react-dom`). And we need to keep the ability to iterate on the pieces that aren't ready without a flurry of major version releases, which semver would require us to do. +No entanto, isso nem sempre é possível. Às vezes, novas funcionalidades estão interconectadas com *outras* novas funcionalidades que ainda não foram totalmente concluídas e nas quais ainda estamos iterando ativamente. Não podemos lançá-las separadamente porque suas implementações estão relacionadas. Não podemos versioná-las separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma infinidade de lançamentos de versão principais, o que o semver exigiria que fizéssemos. -At Meta, we've solved this problem by building React from the `main` branch, and manually updating it to a specific pinned commit every week. This is also the approach that React Native releases have been following for the last several years. Every *stable* release of React Native is pinned to a specific commit from the `main` branch of the React repository. This lets React Native include important bugfixes and incrementally adopt new React features at the framework level without getting coupled to the global React release schedule. +Na Meta, resolvemos esse problema construindo o React a partir do branch `main` e atualizando manualmente para um commit específico fixado toda semana. Esta é também a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada release *estável* do React Native está fixada em um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adotem novas funcionalidades do React de maneira incremental a nível de framework sem se acoplarem à programação global de lançamentos do React. -We would like to make this workflow available to other frameworks and curated setups. For example, it lets a framework *on top of* React include a React-related breaking change *before* this breaking change gets included into a stable React release. This is particularly useful because some breaking changes only affect framework integrations. This lets a framework release such a change in its own minor version without breaking semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima de* React inclua uma mudança breaking relacionada ao React *antes* que essa mudança breaking seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças breaking afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar semver. -Rolling releases with the Canaries channel will allow us to have a tighter feedback loop and ensure that new features get comprehensive testing in the community. This workflow is closer to how TC39, the JavaScript standards committee, [handles changes in numbered stages](https://tc39.es/process-document/). New React features may be available in frameworks built on React before they are in a React stable release, just as new JavaScript features ship in browsers before they are officially ratified as part of the specification. +Lançamentos contínuos com o canal Canaries nos permitirá ter um ciclo de feedback mais apertado e garantir que novas funcionalidades sejam testadas de forma abrangente na comunidade. Este fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novas funcionalidades do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em uma release estável do React, assim como novas funcionalidades do JavaScript são lançadas em navegadores antes de serem oficialmente ratificadas como parte da especificação. -## Why not use experimental releases instead? {/*why-not-use-experimental-releases-instead*/} +## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Although you *can* technically use [Experimental releases](/community/versioning-policy#canary-channel), we recommend against using them in production because experimental APIs can undergo significant breaking changes on their way to stabilization (or can even be removed entirely). While Canaries can also contain mistakes (as with any release), going forward we plan to announce any significant breaking changes in Canaries on our blog. Canaries are the closest to the code Meta runs internally, so you can generally expect them to be relatively stable. However, you *do* need to keep the version pinned and manually scan the GitHub commit log when updating between the pinned commits. +Embora você *possa* tecnicamente usar [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem passar por mudanças breaking significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora os Canaries também possam conter erros (como qualquer release), a partir de agora planejamos anunciar quaisquer mudanças breaking significativas nos Canaries em nosso blog. Os Canaries são os mais próximos do código que a Meta executa internamente, então você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. -**We expect that most people using React outside a curated setup (like a framework) will want to continue using the Stable releases.** However, if you're building a framework, you might want to consider bundling a Canary version of React pinned to a particular commit, and update it at your own pace. The benefit of that is that it lets you ship individual completed React features and bugfixes earlier for your users and at your own release schedule, similar to how React Native has been doing it for the last few years. The downside is that you would take on additional responsibility to review which React commits are being pulled in and communicate to your users which React changes are included with your releases. +**Esperamos que a maioria das pessoas que usam React fora de uma configuração cuidada (como um framework) queira continuar usando as versões Estáveis.** No entanto, se você está construindo um framework, pode querer considerar a inclusão de uma versão Canary do React fixada em um commit específico e atualizá-la no seu próprio ritmo. O benefício disso é que permite que você envie funcionalidades individuais do React e correções de bugs mais cedo para seus usuários e de acordo com sua própria programação de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo puxados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. -If you're a framework author and want to try this approach, please get in touch with us. +Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. -## Announcing breaking changes and new features early {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças breaking e novas funcionalidades com antecedência {/*announcing-breaking-changes-and-new-features-early*/} -Canary releases represent our best guess of what will go into the next stable React release at any given time. +As releases Canary representam nosso melhor palpite sobre o que irá entrar na próxima versão estável do React a qualquer momento. -Traditionally, we've only announced breaking changes at the *end* of the release cycle (when doing a major release). Now that Canary releases are an officially supported way to consume React, we plan to shift towards announcing breaking changes and significant new features *as they land* in Canaries. For example, if we merge a breaking change that will go out in a Canary, we will write a post about it on the React blog, including codemods and migration instructions if necessary. Then, if you're a framework author cutting a major release that updates the pinned React canary to include that change, you can link to our blog post from your release notes. Finally, when a stable major version of React is ready, we will link to those already published blog posts, which we hope will help our team make progress faster. +Tradicionalmente, só anunciamos mudanças breaking no *final* do ciclo de lançamento (ao fazer um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças breaking e novas funcionalidades significativas *à medida que elas chegam* nos Canaries. Por exemplo, se mesclarmos uma mudança breaking que sairá em um Canary, escreveremos um post sobre isso no blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está cortando um lançamento principal que atualiza o Canary fixado do React para incluir essa mudança, você pode vincular ao nosso post do blog em suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, vincularíamos a esses posts de blog já publicados, o que esperamos que ajude nossa equipe a avançar mais rápido. -We plan to document APIs as they land in Canaries--even if these APIs are not yet available outside of them. APIs that are only available in Canaries will be marked with a special note on the corresponding pages. This will include APIs like [`use`](https://github.com/reactjs/rfcs/pull/229), and some others (like `cache` and `createServerContext`) which we'll send RFCs for. +Planejamos documentar APIs à medida que elas chegam nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora deles. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. -## Canaries must be pinned {/*canaries-must-be-pinned*/} +## Canaries devem ser fixados {/*canaries-must-be-pinned*/} -If you decide to adopt the Canary workflow for your app or framework, make sure you always pin the *exact* version of the Canary you're using. Since Canaries are pre-releases, they may still include breaking changes. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que você está usando. Como os Canaries são pré-releases, eles ainda podem incluir mudanças breaking. -## Example: React Server Components {/*example-react-server-components*/} +## Exemplo: Componentes do Servidor React {/*example-react-server-components*/} -As we [announced in March](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can't release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as [asset loading](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) and expect more breaking changes there. +Conforme anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor do React foram finalizadas, e não esperamos mudanças breaking significativas relacionadas ao contrato de API voltado para o usuário. No entanto, ainda não podemos liberar suporte para Componentes do Servidor React em uma versão estável do React porque ainda estamos trabalhando em várias funcionalidades interligadas apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças breaking lá. -This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React. (To avoid bundling two copies of React, frameworks that wish to do this would need to enforce resolution of `react` and `react-dom` to the pinned Canary they ship with their framework, and explain that to their users. As an example, this is what Next.js App Router does.) +Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é enviar uma versão Canary fixada do React. (Para evitar incluir duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework, e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) -## Testing libraries against both Stable and Canary versions {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Testando bibliotecas contra versões Estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -We do not expect library authors to test every single Canary release since it would be prohibitively difficult. However, just as when we [originally introduced the different React pre-release channels three years ago](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), we encourage libraries to run tests against *both* the latest Stable and latest Canary versions. If you see a change in behavior that wasn't announced, please file a bug in the React repository so that we can help diagnose it. We expect that as this practice becomes widely adopted, it will reduce the amount of effort necessary to upgrade libraries to new major versions of React, since accidental regressions would be found as they land. +Não esperamos que autores de bibliotecas testem cada lancamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando [introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), incentivamos bibliotecas a rodar testes tanto nas versões Estáveis mais recentes quanto nas versões Canary mais recentes. Se você perceber uma mudança de comportamento que não foi anunciada, por favor, abra um bug no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, isso reduzirá o esforço necessário para atualizar bibliotecas para novas versões principais do React, pois regressões acidentais seriam encontradas assim que chegassem. -Strictly speaking, Canary is not a *new* release channel--it used to be called Next. However, we've decided to rename it to avoid confusion with Next.js. We're announcing it as a *new* release channel to communicate the new expectations, such as Canaries being an officially supported way to use React. +Estritamente falando, Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando-o como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. -## Stable releases work like before {/*stable-releases-work-like-before*/} - -We are not introducing any changes to stable React releases. - - +## Lançamentos Estáveis funcionam como antes {/*stable-releases-work-like-before*/} +Não estamos introduzindo nenhuma mudança nas releases estáveis do React. \ No newline at end of file From dcc74ae33fcabbfafe8a09a57002dbf45256199f Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 11:27:23 -0300 Subject: [PATCH 2/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 80 +++++++++---------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index 5dd00a501..a5f716809 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Habilitando Implementações Incrementais de Funcionalidades Fora da Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark +title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora da Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, e Andrew Clark date: 2023/05/03 -description: Gostaríamos de oferecer à comunidade React a opção de adotar novas funcionalidades individuais assim que seu design estiver próximo do final, antes de serem lançadas em uma versão estável - semelhante a como a Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de funcionalidades individuais do React da programação de lançamentos do React. +description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos de forma individual assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta há muito tempo usa versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. --- -3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) --- -Gostaríamos de oferecer à comunidade React a opção de adotar novas funcionalidades individuais assim que seu design estiver próximo do final, antes de serem lançadas em uma versão estável - semelhante a como a Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de funcionalidades individuais do React da programação de lançamentos do React. +Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos de forma individual assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta há muito tempo usa versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. @@ -19,76 +19,76 @@ Gostaríamos de oferecer à comunidade React a opção de adotar novas funcional ## tl;dr {/*tldr*/} -* Estamos introduzindo um [canal de releases Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se regressões ocorrerem, iremos tratá-las com a mesma urgência que erros em lançamentos estáveis. -* Canaries permitem que você comece a usar novas funcionalidades individuais do React antes que elas cheguem às versões semver-estáveis. -* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas funcionalidades que acreditamos razoavelmente que estão prontas para adoção. Incentivamos frameworks a considerar a inclusão de versões Canary do React fixadas. -* Anunciaremos mudanças breaking e novas funcionalidades em nosso blog assim que elas chegarem às releases Canary. -* **Como sempre, o React continua a seguir semver para cada release Estável.** +* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se alguma regressão ocorrer, a trataremos com a mesma urgência que erros em lançamentos estáveis. +* Canários permitem que você comece a usar novos recursos individuais do React antes que eles sejam incluídos nas versões estáveis semver. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canários do React incluem apenas recursos que achamos razoavelmente prontos para adoção. Encorajamos frameworks a considerar agrupar versões Canary fixas do React. +* Anunciaremos mudanças impactantes e novos recursos em nosso blog à medida que forem disponibilizados nas versões Canary. +* **Como sempre, o React continua a seguir semver para cada lançamento estável.** -## Como as funcionalidades do React são normalmente desenvolvidas {/*how-react-features-are-usually-developed*/} +## Como os recursos do React são normalmente desenvolvidos {/*how-react-features-are-usually-developed*/} -Tipicamente, cada funcionalidade do React passa pelas mesmas etapas: +Normalmente, cada recurso do React passou pelas mesmas etapas: -1. Desenvolvemos uma versão inicial e prefixamos com `experimental_` ou `unstable_`. A funcionalidade está disponível apenas no canal de release `experimental`. Neste ponto, espera-se que a funcionalidade mude significativamente. -2. Encontramos uma equipe na Meta disposta a nos ajudar a testar essa funcionalidade e fornecer feedback sobre ela. Isso leva a uma rodada de mudanças. À medida que a funcionalidade se torna mais estável, trabalhamos com mais equipes na Meta para testá-la. -3. Eventualmente, nos sentimos confiantes no design. Removemos o prefixo do nome da API e disponibilizamos a funcionalidade no branch `main` por padrão, que a maioria dos produtos da Meta utiliza. Neste ponto, qualquer equipe da Meta pode usar essa funcionalidade. -4. À medida que aumentamos a confiança na direção, também postamos um RFC para a nova funcionalidade. Neste ponto, sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. -5. Quando estamos próximos de lançar uma versão open source, escrevemos a documentação para a funcionalidade e finalmente lançamos a funcionalidade em uma versão estável do React. +1. Desenvolvemos uma versão inicial e prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamentos `experimental`. Neste ponto, o recurso deve mudar significativamente. +2. Encontramos uma equipe na Meta disposta a nos ajudar a testar esse recurso e fornecer feedback sobre ele. Isso leva a uma rodada de mudanças. À medida que o recurso se torna mais estável, trabalhamos com mais equipes na Meta para testá-lo. +3. Eventualmente, sentimos confiança no design. Removemos o prefixo do nome da API e tornamos o recurso disponível na branch `main` por padrão, que a maioria dos produtos da Meta utiliza. Neste ponto, qualquer equipe na Meta pode usar esse recurso. +4. À medida que construímos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto, sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos prestes a cortar um lançamento de código aberto, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. -Este playbook funciona bem para a maioria das funcionalidades que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando a funcionalidade está geralmente pronta para uso (passo 3) e quando é lançada como open source (passo 5). +Este plano funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver um gap significativo entre o momento em que o recurso está geralmente pronto para uso (passo 3) e quando é lançado como código aberto (passo 5). -**Gostaríamos de oferecer à comunidade React a opção de seguir a mesma abordagem que a Meta e adotar novas funcionalidades individuais mais cedo (à medida que ficam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** +**Gostaríamos de oferecer à comunidade React uma opção para seguir a mesma abordagem da Meta e adotar novos recursos individuais mais cedo (assim que se tornem disponíveis) sem ter que esperar o próximo ciclo de lançamento do React.** -Como sempre, todas as funcionalidades do React eventualmente estarão em uma release Estável. +Como sempre, todos os recursos do React eventualmente farão parte de um lançamento estável. ## Podemos apenas fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} -De maneira geral, *nós* usamos lançamentos menores para introduzir novas funcionalidades. +Geralmente, nós *fazemos* usar lançamentos menores para introduzir novos recursos. -No entanto, isso nem sempre é possível. Às vezes, novas funcionalidades estão interconectadas com *outras* novas funcionalidades que ainda não foram totalmente concluídas e nas quais ainda estamos iterando ativamente. Não podemos lançá-las separadamente porque suas implementações estão relacionadas. Não podemos versioná-las separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma infinidade de lançamentos de versão principais, o que o semver exigiria que fizéssemos. +No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram totalmente completados e nos quais ainda estamos iterando ativamente. Não podemos liberá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma avalanche de lançamentos de versão major, que a semver exigiria que fizéssemos. -Na Meta, resolvemos esse problema construindo o React a partir do branch `main` e atualizando manualmente para um commit específico fixado toda semana. Esta é também a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada release *estável* do React Native está fixada em um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adotem novas funcionalidades do React de maneira incremental a nível de framework sem se acoplarem à programação global de lançamentos do React. +Na Meta, resolvemos esse problema construindo o React a partir da branch `main` e atualizando manualmente para um commit específico fixo a cada semana. Esta também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico da branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote incrementalmente novos recursos do React no nível do framework sem ficar acoplado ao cronograma global de lançamentos do React. -Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima de* React inclua uma mudança breaking relacionada ao React *antes* que essa mudança breaking seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças breaking afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima do* React inclua uma mudança de ruptura relacionada ao React *antes* que essa mudança de ruptura seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças de ruptura afetam apenas integrações de framework. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar a semver. -Lançamentos contínuos com o canal Canaries nos permitirá ter um ciclo de feedback mais apertado e garantir que novas funcionalidades sejam testadas de forma abrangente na comunidade. Este fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novas funcionalidades do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em uma release estável do React, assim como novas funcionalidades do JavaScript são lançadas em navegadores antes de serem oficialmente ratificadas como parte da especificação. +Lançamentos contínuos com o canal Canaries nos permitirão ter um feedback mais rápido e garantir que novos recursos sejam testados de forma abrangente na comunidade. Esse fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em uma versão estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. ## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Embora você *possa* tecnicamente usar [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem passar por mudanças breaking significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora os Canaries também possam conter erros (como qualquer release), a partir de agora planejamos anunciar quaisquer mudanças breaking significativas nos Canaries em nosso blog. Os Canaries são os mais próximos do código que a Meta executa internamente, então você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. +Embora você *possa* tecnicamente usar [lançamentos experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem sofrer mudanças impactantes significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora os Canários também possam conter erros (como qualquer lançamento), no futuro planejamos anunciar quaisquer mudanças impactantes significativas em Canários em nosso blog. Os Canários são os mais próximos do código que a Meta executa internamente, então você pode geralmente esperar que sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixos. -**Esperamos que a maioria das pessoas que usam React fora de uma configuração cuidada (como um framework) queira continuar usando as versões Estáveis.** No entanto, se você está construindo um framework, pode querer considerar a inclusão de uma versão Canary do React fixada em um commit específico e atualizá-la no seu próprio ritmo. O benefício disso é que permite que você envie funcionalidades individuais do React e correções de bugs mais cedo para seus usuários e de acordo com sua própria programação de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo puxados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. +**Esperamos que a maioria das pessoas usando React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos estáveis.** No entanto, se você estiver construindo um framework, pode querer considerar a agregação de uma versão Canary do React fixada a um determinado commit e atualizá-la em seu próprio ritmo. O benefício disso é que permite que você envie recursos e correções de bugs individuais do React mais cedo para seus usuários e de acordo com seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo incorporados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. -## Anunciando mudanças breaking e novas funcionalidades com antecedência {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças impactantes e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} -As releases Canary representam nosso melhor palpite sobre o que irá entrar na próxima versão estável do React a qualquer momento. +Os lançamentos Canary representam nosso melhor palpite do que irá para o próximo lançamento estável do React a qualquer momento. -Tradicionalmente, só anunciamos mudanças breaking no *final* do ciclo de lançamento (ao fazer um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças breaking e novas funcionalidades significativas *à medida que elas chegam* nos Canaries. Por exemplo, se mesclarmos uma mudança breaking que sairá em um Canary, escreveremos um post sobre isso no blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está cortando um lançamento principal que atualiza o Canary fixado do React para incluir essa mudança, você pode vincular ao nosso post do blog em suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, vincularíamos a esses posts de blog já publicados, o que esperamos que ajude nossa equipe a avançar mais rápido. +Tradicionalmente, só anunciamos mudanças impactantes no *final* do ciclo de lançamento (quando fazemos um lançamento major). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças impactantes e novos recursos significativos *à medida que forem disponibilizados* nos Canários. Por exemplo, se mesclarmos uma mudança impactante que será liberada em um Canary, escreveremos um post sobre isso em nosso blog React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está cortando um lançamento major que atualiza o Canary fixo do React para incluir essa mudança, você pode vincular ao nosso post do blog em suas notas de lançamento. Finalmente, quando uma versão major estável do React estiver pronta, vincularemos a esses posts do blog já publicados, o que esperamos ajudar nossa equipe a fazer progresso mais rapidamente. -Planejamos documentar APIs à medida que elas chegam nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora deles. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. +Planejamos documentar APIs à medida que forem disponibilizadas nos Canários - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canários serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229) e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. -## Canaries devem ser fixados {/*canaries-must-be-pinned*/} +## Os Canários devem ser fixados {/*canaries-must-be-pinned*/} -Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que você está usando. Como os Canaries são pré-releases, eles ainda podem incluir mudanças breaking. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que você está usando. Como os Canários são pré-lançamentos, eles ainda podem incluir mudanças de ruptura. ## Exemplo: Componentes do Servidor React {/*example-react-server-components*/} -Conforme anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor do React foram finalizadas, e não esperamos mudanças breaking significativas relacionadas ao contrato de API voltado para o usuário. No entanto, ainda não podemos liberar suporte para Componentes do Servidor React em uma versão estável do React porque ainda estamos trabalhando em várias funcionalidades interligadas apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças breaking lá. +Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas e não esperamos mudanças impactantes significativas relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar suporte para Componentes do Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos interligados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças impactantes lá. -Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é enviar uma versão Canary fixada do React. (Para evitar incluir duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework, e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) +Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento major do React, a única maneira de um framework adotá-los é lançar uma versão Canary do React fixada. (Para evitar agrupar duas cópias do React, frameworks que desejam fazer isso precisariam forçar a resolução de `react` e `react-dom` para o Canary fixo que eles lançam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) -## Testando bibliotecas contra versões Estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Testando bibliotecas contra versões Stable e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -Não esperamos que autores de bibliotecas testem cada lancamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando [introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), incentivamos bibliotecas a rodar testes tanto nas versões Estáveis mais recentes quanto nas versões Canary mais recentes. Se você perceber uma mudança de comportamento que não foi anunciada, por favor, abra um bug no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, isso reduzirá o esforço necessário para atualizar bibliotecas para novas versões principais do React, pois regressões acidentais seriam encontradas assim que chegassem. +Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), encorajamos bibliotecas a executar testes contra *tanto* a versão Stable mais recente quanto a versão Canary mais recente. Se você observar uma mudança de comportamento que não foi anunciada, por favor, registre um bug no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, ela reduzirá o esforço necessário para atualizar bibliotecas para novas versões major do React, já que regressões acidentais seriam encontradas assim que forem lançadas. -Estritamente falando, Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando-o como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. +Estritamente falando, o Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canários sendo uma maneira oficialmente suportada de usar o React. -## Lançamentos Estáveis funcionam como antes {/*stable-releases-work-like-before*/} +## Lançamentos estáveis funcionam como antes {/*stable-releases-work-like-before*/} -Não estamos introduzindo nenhuma mudança nas releases estáveis do React. \ No newline at end of file +Não estamos introduzindo nenhuma mudança nos lançamentos estáveis do React. \ No newline at end of file From 2624daf7589cde8be4f6e9c426edca45c1cc936e Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 11:36:24 -0300 Subject: [PATCH 3/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 78 +++++++++---------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index a5f716809..c8bba44e4 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora da Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, e Andrew Clark +title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora do Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark date: 2023/05/03 -description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos de forma individual assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta há muito tempo usa versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. +description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante à maneira como o Meta tem usado versões de ponta do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React da programação de lançamentos do React. --- -3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) --- -Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos de forma individual assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta há muito tempo usa versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. +Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante à maneira como o Meta tem usado versões de ponta do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React da programação de lançamentos do React. @@ -19,76 +19,76 @@ Gostaríamos de oferecer à comunidade React uma opção para adotar novos recur ## tl;dr {/*tldr*/} -* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se alguma regressão ocorrer, a trataremos com a mesma urgência que erros em lançamentos estáveis. -* Canários permitem que você comece a usar novos recursos individuais do React antes que eles sejam incluídos nas versões estáveis semver. -* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canários do React incluem apenas recursos que achamos razoavelmente prontos para adoção. Encorajamos frameworks a considerar agrupar versões Canary fixas do React. -* Anunciaremos mudanças impactantes e novos recursos em nosso blog à medida que forem disponibilizados nas versões Canary. -* **Como sempre, o React continua a seguir semver para cada lançamento estável.** +* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se quaisquer regressões ocorrerem, as trataremos com uma urgência similar a erros em lançamentos estáveis. +* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões estáveis semver. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), o React Canaries inclui apenas recursos que acreditamos razoavelmente estar prontos para adoção. Encorajamos frameworks a considerar agrupar lançamentos Canary do React fixados. +* Anunciaremos mudanças significativas e novos recursos em nosso blog assim que forem lançados nos Canary releases. +* **Como sempre, o React continua a seguir semver para cada lançamento Estável.** -## Como os recursos do React são normalmente desenvolvidos {/*how-react-features-are-usually-developed*/} +## Como os recursos do React são geralmente desenvolvidos {/*how-react-features-are-usually-developed*/} -Normalmente, cada recurso do React passou pelas mesmas etapas: +Geralmente, cada recurso do React passa pelas mesmas etapas: -1. Desenvolvemos uma versão inicial e prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamentos `experimental`. Neste ponto, o recurso deve mudar significativamente. -2. Encontramos uma equipe na Meta disposta a nos ajudar a testar esse recurso e fornecer feedback sobre ele. Isso leva a uma rodada de mudanças. À medida que o recurso se torna mais estável, trabalhamos com mais equipes na Meta para testá-lo. -3. Eventualmente, sentimos confiança no design. Removemos o prefixo do nome da API e tornamos o recurso disponível na branch `main` por padrão, que a maioria dos produtos da Meta utiliza. Neste ponto, qualquer equipe na Meta pode usar esse recurso. -4. À medida que construímos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto, sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. -5. Quando estamos prestes a cortar um lançamento de código aberto, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. +1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Neste ponto, espera-se que o recurso mude significativamente. +2. Encontramos uma equipe no Meta disposta a nos ajudar a testar esse recurso e fornecer feedback sobre ele. Isso leva a uma rodada de alterações. À medida que o recurso se torna mais estável, trabalhamos com mais equipes no Meta para testá-lo. +3. Eventualmente, sentimos confiança no design. Removemos o prefixo do nome da API e tornamos o recurso disponível no branch `main` por padrão, que a maioria dos produtos do Meta usa. Nesse momento, qualquer equipe do Meta pode usar esse recurso. +4. À medida que ganhamos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos prestes a lançar uma versão de código aberto, escrevemos documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. -Este plano funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver um gap significativo entre o momento em que o recurso está geralmente pronto para uso (passo 3) e quando é lançado como código aberto (passo 5). +Esse roteiro funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (etapa 3) e quando é lançado como código aberto (etapa 5). -**Gostaríamos de oferecer à comunidade React uma opção para seguir a mesma abordagem da Meta e adotar novos recursos individuais mais cedo (assim que se tornem disponíveis) sem ter que esperar o próximo ciclo de lançamento do React.** +**Gostaríamos de oferecer à comunidade React uma opção para seguir o mesmo caminho que o Meta e adotar recursos novos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** -Como sempre, todos os recursos do React eventualmente farão parte de um lançamento estável. +Como sempre, todos os recursos do React eventualmente farão parte de um lançamento Estável. ## Podemos apenas fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} -Geralmente, nós *fazemos* usar lançamentos menores para introduzir novos recursos. +Geralmente, *fazemos* lançamentos menores para introduzir novos recursos. -No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram totalmente completados e nos quais ainda estamos iterando ativamente. Não podemos liberá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma avalanche de lançamentos de versão major, que a semver exigiria que fizéssemos. +No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram concluídos completamente e nos quais ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque eles afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, o que o semver exigiria de nós. -Na Meta, resolvemos esse problema construindo o React a partir da branch `main` e atualizando manualmente para um commit específico fixo a cada semana. Esta também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico da branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote incrementalmente novos recursos do React no nível do framework sem ficar acoplado ao cronograma global de lançamentos do React. +No Meta, resolvemos esse problema construindo o React a partir do branch `main`, atualizando-o manualmente para um commit fixado específico a cada semana. Essa é também a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote de forma incremental novos recursos do React em nível de framework sem se acoplar à programação global de lançamentos do React. -Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima do* React inclua uma mudança de ruptura relacionada ao React *antes* que essa mudança de ruptura seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças de ruptura afetam apenas integrações de framework. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar a semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, permite que um framework *sobre* o React inclua uma mudança breaking relacionada ao React *antes* que essa mudança breaking seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças breaking afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar o semver. -Lançamentos contínuos com o canal Canaries nos permitirão ter um feedback mais rápido e garantir que novos recursos sejam testados de forma abrangente na comunidade. Esse fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em uma versão estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. +Lançamentos contínuos com o canal Canaries nos permitirão ter um ciclo de feedback mais rápido e garantir que novos recursos sejam amplamente testados na comunidade. Esse fluxo de trabalho está mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em um lançamento estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. ## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Embora você *possa* tecnicamente usar [lançamentos experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem sofrer mudanças impactantes significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora os Canários também possam conter erros (como qualquer lançamento), no futuro planejamos anunciar quaisquer mudanças impactantes significativas em Canários em nosso blog. Os Canários são os mais próximos do código que a Meta executa internamente, então você pode geralmente esperar que sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixos. +Embora você *possa* tecnicamente usar [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem passar por mudanças breaking significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora Canaries também possam conter erros (como qualquer lançamento), daqui para frente planejamos anunciar quaisquer mudanças breaking significativas nos Canaries em nosso blog. Os Canaries são os mais próximos do código que o Meta executa internamente, portanto, você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. -**Esperamos que a maioria das pessoas usando React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos estáveis.** No entanto, se você estiver construindo um framework, pode querer considerar a agregação de uma versão Canary do React fixada a um determinado commit e atualizá-la em seu próprio ritmo. O benefício disso é que permite que você envie recursos e correções de bugs individuais do React mais cedo para seus usuários e de acordo com seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo incorporados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. +**Esperamos que a maioria das pessoas que usam o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos Estáveis.** No entanto, se você está construindo um framework, pode querer considerar agrupar uma versão Canary do React fixada em um commit específico e atualizá-la em seu próprio ritmo. O benefício disso é que ele permite que você envie recursos completos individuais do React e correções de bugs mais cedo para seus usuários e em seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. O lado negativo é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo incluídos e comunicar a seus usuários quais alterações do React estão incluídas em seus lançamentos. Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. -## Anunciando mudanças impactantes e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças breaking e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} -Os lançamentos Canary representam nosso melhor palpite do que irá para o próximo lançamento estável do React a qualquer momento. +Os lançamentos Canary representam nosso melhor palpite sobre o que irá compor o próximo lançamento estável do React a qualquer momento. -Tradicionalmente, só anunciamos mudanças impactantes no *final* do ciclo de lançamento (quando fazemos um lançamento major). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças impactantes e novos recursos significativos *à medida que forem disponibilizados* nos Canários. Por exemplo, se mesclarmos uma mudança impactante que será liberada em um Canary, escreveremos um post sobre isso em nosso blog React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está cortando um lançamento major que atualiza o Canary fixo do React para incluir essa mudança, você pode vincular ao nosso post do blog em suas notas de lançamento. Finalmente, quando uma versão major estável do React estiver pronta, vincularemos a esses posts do blog já publicados, o que esperamos ajudar nossa equipe a fazer progresso mais rapidamente. +Tradicionalmente, só anunciamos mudanças breaking no *final* do ciclo de lançamento (ao realizar um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças breaking e novos recursos significativos *à medida que eles surgem* nos Canaries. Por exemplo, se nós mesclarmos uma mudança breaking que será lançada em um Canary, escreveremos um post sobre isso no blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está realizando um lançamento principal que atualiza o Canary fixado do React para incluir essa mudança, você pode vincular nosso post do blog a partir de suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, vincularemos a esses posts do blog já publicados, o que esperamos ajudar nossa equipe a progredir mais rápido. -Planejamos documentar APIs à medida que forem disponibilizadas nos Canários - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canários serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229) e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. +Planejamos documentar APIs à medida que elas aparecem nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora deles. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. -## Os Canários devem ser fixados {/*canaries-must-be-pinned*/} +## Canaries devem ser fixados {/*canaries-must-be-pinned*/} -Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que você está usando. Como os Canários são pré-lançamentos, eles ainda podem incluir mudanças de ruptura. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças breaking. ## Exemplo: Componentes do Servidor React {/*example-react-server-components*/} -Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas e não esperamos mudanças impactantes significativas relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar suporte para Componentes do Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos interligados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças impactantes lá. +Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas e não esperamos mudanças breaking significativas relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar suporte para Componentes do Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos entrelaçados voltados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças breaking lá. -Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento major do React, a única maneira de um framework adotá-los é lançar uma versão Canary do React fixada. (Para evitar agrupar duas cópias do React, frameworks que desejam fazer isso precisariam forçar a resolução de `react` e `react-dom` para o Canary fixo que eles lançam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) +Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é lançar uma versão Canary fixada do React. (Para evitar a inclusão de duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) -## Testando bibliotecas contra versões Stable e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Testando bibliotecas contra versões Estáveis e Canaries {/*testing-libraries-against-both-stable-and-canary-versions*/} -Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), encorajamos bibliotecas a executar testes contra *tanto* a versão Stable mais recente quanto a versão Canary mais recente. Se você observar uma mudança de comportamento que não foi anunciada, por favor, registre um bug no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, ela reduzirá o esforço necessário para atualizar bibliotecas para novas versões major do React, já que regressões acidentais seriam encontradas assim que forem lançadas. +Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria extremamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos atrás](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), encorajamos bibliotecas a executar testes contra *tanto* a versão Estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança no comportamento que não foi anunciada, por favor, abra um bug no repositório do React para que possamos ajudar a diagnosticar. Esperamos que, à medida que essa prática se torne amplamente adotada, reduza a quantidade de esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam descobertas à medida que elas ocorrem. -Estritamente falando, o Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canários sendo uma maneira oficialmente suportada de usar o React. +Estritamente falando, Canary não é um novo canal de lançamento - antigamente era chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando-o como um novo canal de lançamento para comunicar as novas expectativas, como Canaries sendo uma maneira oficialmente suportada de usar o React. ## Lançamentos estáveis funcionam como antes {/*stable-releases-work-like-before*/} -Não estamos introduzindo nenhuma mudança nos lançamentos estáveis do React. \ No newline at end of file +Não estamos introduzindo nenhuma mudança nas versões estáveis do React. \ No newline at end of file From e3b9b5002039ced09e60e2d66ec78e0f66ae3992 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 14:16:08 -0300 Subject: [PATCH 4/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 76 +++++++++---------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index c8bba44e4..ced100d1c 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora do Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark +title: "React Canaries: Habilitando Implementação Incremental de Recursos Fora do Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, e Andrew Clark date: 2023/05/03 -description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante à maneira como o Meta tem usado versões de ponta do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React da programação de lançamentos do React. +description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante ao que o Meta tem utilizado há muito tempo com versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais React do cronograma de lançamentos do React. --- -3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) --- -Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante à maneira como o Meta tem usado versões de ponta do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React da programação de lançamentos do React. +Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante ao que o Meta tem utilizado há muito tempo com versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais React do cronograma de lançamentos do React. @@ -19,76 +19,76 @@ Gostaríamos de oferecer à comunidade React uma opção para adotar novos recur ## tl;dr {/*tldr*/} -* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se quaisquer regressões ocorrerem, as trataremos com uma urgência similar a erros em lançamentos estáveis. -* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões estáveis semver. -* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), o React Canaries inclui apenas recursos que acreditamos razoavelmente estar prontos para adoção. Encorajamos frameworks a considerar agrupar lançamentos Canary do React fixados. -* Anunciaremos mudanças significativas e novos recursos em nosso blog assim que forem lançados nos Canary releases. -* **Como sempre, o React continua a seguir semver para cada lançamento Estável.** +* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se houver regressões, trataremos delas com a mesma urgência que erros em lançamentos estáveis. +* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões semver-estáveis. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas recursos que acreditamos razoavelmente estar prontos para adoção. Encorajamos frameworks a considerar agrupar lançamentos Canary do React fixados. +* Anunciaremos mudanças quebradoras e novos recursos em nosso blog à medida que eles forem lançados nas versões Canary. +* **Como sempre, o React continua a seguir semver para cada lançamento estável.** ## Como os recursos do React são geralmente desenvolvidos {/*how-react-features-are-usually-developed*/} -Geralmente, cada recurso do React passa pelas mesmas etapas: +Tipicamente, cada recurso do React passou pelas mesmas etapas: 1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Neste ponto, espera-se que o recurso mude significativamente. -2. Encontramos uma equipe no Meta disposta a nos ajudar a testar esse recurso e fornecer feedback sobre ele. Isso leva a uma rodada de alterações. À medida que o recurso se torna mais estável, trabalhamos com mais equipes no Meta para testá-lo. -3. Eventualmente, sentimos confiança no design. Removemos o prefixo do nome da API e tornamos o recurso disponível no branch `main` por padrão, que a maioria dos produtos do Meta usa. Nesse momento, qualquer equipe do Meta pode usar esse recurso. -4. À medida que ganhamos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto sabemos que o design funciona para um conjunto amplo de casos, mas podemos fazer alguns ajustes de última hora. -5. Quando estamos prestes a lançar uma versão de código aberto, escrevemos documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. +2. Encontramos uma equipe no Meta disposta a nos ajudar a testar este recurso e fornecer feedback sobre ele. Isso leva a uma rodada de mudanças. À medida que o recurso se torna mais estável, trabalhamos com mais equipes no Meta para testá-lo. +3. Eventualmente, nos sentimos confiantes no design. Removemos o prefixo do nome da API e tornamos o recurso disponível na branch `main` por padrão, que a maioria dos produtos do Meta usa. Nesse ponto, qualquer equipe no Meta pode usar esse recurso. +4. À medida que construímos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto, sabemos que o design funciona para um amplo conjunto de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos prestes a liberar uma versão open source, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. -Esse roteiro funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (etapa 3) e quando é lançado como código aberto (etapa 5). +Este manual funciona bem para a maioria dos recursos que já lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (etapa 3) e quando ele é lançado como open source (etapa 5). -**Gostaríamos de oferecer à comunidade React uma opção para seguir o mesmo caminho que o Meta e adotar recursos novos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** +**Gostaríamos de oferecer à comunidade React uma opção para seguir o mesmo approach do Meta e adotar novos recursos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** -Como sempre, todos os recursos do React eventualmente farão parte de um lançamento Estável. +Como sempre, todos os recursos do React eventualmente farão parte de um lançamento estável. -## Podemos apenas fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} +## Podemos simplesmente fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} -Geralmente, *fazemos* lançamentos menores para introduzir novos recursos. +Geralmente, nós *fazemos* usar lançamentos menores para introduzir novos recursos. -No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram concluídos completamente e nos quais ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque eles afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar nas partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, o que o semver exigiria de nós. +No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram totalmente concluídos e que ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar sobre as partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, que semver exigiria que fizéssemos. -No Meta, resolvemos esse problema construindo o React a partir do branch `main`, atualizando-o manualmente para um commit fixado específico a cada semana. Essa é também a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote de forma incremental novos recursos do React em nível de framework sem se acoplar à programação global de lançamentos do React. +No Meta, resolvemos esse problema construindo o React a partir da branch `main` e atualizando-o manualmente para um commit fixo específico a cada semana. Esta também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico da branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote novos recursos do React de forma incremental no nível do framework, sem ficar acoplado ao cronograma global de lançamentos do React. -Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, permite que um framework *sobre* o React inclua uma mudança breaking relacionada ao React *antes* que essa mudança breaking seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças breaking afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar o semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *sobre* o React inclua uma mudança quebradora relacionada ao React *antes* que essa mudança quebradora seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças quebradoras afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar semver. -Lançamentos contínuos com o canal Canaries nos permitirão ter um ciclo de feedback mais rápido e garantir que novos recursos sejam amplamente testados na comunidade. Esse fluxo de trabalho está mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em um lançamento estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. +Lançamentos contínuos com o canal Canaries nos permitirão ter um ciclo de feedback mais curto e garantir que novos recursos recebam testes abrangentes na comunidade. Este fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em um lançamento estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. ## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Embora você *possa* tecnicamente usar [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem passar por mudanças breaking significativas em seu caminho para a estabilização (ou podem até ser removidas completamente). Embora Canaries também possam conter erros (como qualquer lançamento), daqui para frente planejamos anunciar quaisquer mudanças breaking significativas nos Canaries em nosso blog. Os Canaries são os mais próximos do código que o Meta executa internamente, portanto, você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. +Embora você *possa* tecnicamente usar [lançamentos experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem sofrer mudanças quebradoras significativas em seu caminho para a estabilização (ou podem até ser removidas totalmente). Embora os Canaries também possam conter erros (como qualquer lançamento), vamos anunciar qualquer mudança quebradora significativa nos Canaries em nosso blog. Os Canaries são os mais próximos do código que o Meta executa internamente, então você pode geralmente esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. -**Esperamos que a maioria das pessoas que usam o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos Estáveis.** No entanto, se você está construindo um framework, pode querer considerar agrupar uma versão Canary do React fixada em um commit específico e atualizá-la em seu próprio ritmo. O benefício disso é que ele permite que você envie recursos completos individuais do React e correções de bugs mais cedo para seus usuários e em seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. O lado negativo é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo incluídos e comunicar a seus usuários quais alterações do React estão incluídas em seus lançamentos. +**Esperamos que a maioria das pessoas usando o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos estáveis.** No entanto, se você está construindo um framework, talvez queira considerar agrupar uma versão Canary do React fixada a um commit específico e atualizá-la a seu próprio ritmo. O benefício disso é que permite que você entregue recursos concretos do React e correções de bugs mais cedo para seus usuários e no seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria a responsabilidade adicional de revisar quais commits do React estão sendo puxados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. -Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. +Se você é um autor de framework e quer tentar essa abordagem, entre em contato conosco. -## Anunciando mudanças breaking e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças quebradoras e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} -Os lançamentos Canary representam nosso melhor palpite sobre o que irá compor o próximo lançamento estável do React a qualquer momento. +Os lançamentos Canary representam nossa melhor estimativa do que irá para o próximo lançamento estável do React a qualquer momento. -Tradicionalmente, só anunciamos mudanças breaking no *final* do ciclo de lançamento (ao realizar um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças breaking e novos recursos significativos *à medida que eles surgem* nos Canaries. Por exemplo, se nós mesclarmos uma mudança breaking que será lançada em um Canary, escreveremos um post sobre isso no blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está realizando um lançamento principal que atualiza o Canary fixado do React para incluir essa mudança, você pode vincular nosso post do blog a partir de suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, vincularemos a esses posts do blog já publicados, o que esperamos ajudar nossa equipe a progredir mais rápido. +Tradicionalmente, nós só anunciamos mudanças quebradoras no *final* do ciclo de lançamento (ao fazer um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças quebradoras e novos recursos significativos *à medida que forem lançados* nos Canaries. Por exemplo, se mesclarmos uma mudança quebradora que irá sair em um Canary, escreveremos um post sobre isso em nosso blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está fazendo um lançamento principal que atualiza o canary do React fixado para incluir essa mudança, você pode linkar para nosso post no blog nas suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, iremos linkar para esses posts já publicados no blog, o que esperamos ajudar nossa equipe a avançar mais rapidamente. -Planejamos documentar APIs à medida que elas aparecem nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora deles. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. +Planejamos documentar APIs à medida que elas forem lançadas nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. ## Canaries devem ser fixados {/*canaries-must-be-pinned*/} -Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças breaking. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças quebradoras. ## Exemplo: Componentes do Servidor React {/*example-react-server-components*/} -Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas e não esperamos mudanças breaking significativas relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar suporte para Componentes do Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos entrelaçados voltados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças breaking lá. +Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas, e não esperamos mudanças quebradoras significativas relacionadas ao seu contrato de API voltado ao usuário. No entanto, não podemos ainda liberar suporte para Componentes do Servidor React em uma versão estável do React porque ainda estamos trabalhando em várias funcionalidades interligadas apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças quebradoras lá. -Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é lançar uma versão Canary fixada do React. (Para evitar a inclusão de duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) +Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é enviar uma versão Canary fixada do React. (Para evitar agregar duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) -## Testando bibliotecas contra versões Estáveis e Canaries {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Testando bibliotecas contra versões estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria extremamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos atrás](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), encorajamos bibliotecas a executar testes contra *tanto* a versão Estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança no comportamento que não foi anunciada, por favor, abra um bug no repositório do React para que possamos ajudar a diagnosticar. Esperamos que, à medida que essa prática se torne amplamente adotada, reduza a quantidade de esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam descobertas à medida que elas ocorrem. +Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React, encorajamos bibliotecas a executar testes contra *tanto* a versão estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança no comportamento que não foi anunciada, por favor, relate um erro no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, reduza a quantidade de esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam encontradas à medida que fossem lançadas. -Estritamente falando, Canary não é um novo canal de lançamento - antigamente era chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando-o como um novo canal de lançamento para comunicar as novas expectativas, como Canaries sendo uma maneira oficialmente suportada de usar o React. +Estritamente falando, Canary não é um canal de lançamento *novo*--ele costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. ## Lançamentos estáveis funcionam como antes {/*stable-releases-work-like-before*/} -Não estamos introduzindo nenhuma mudança nas versões estáveis do React. \ No newline at end of file +Não estamos introduzindo nenhuma mudança nos lançamentos estáveis do React. \ No newline at end of file From ad17792cb8b9aa2a30b3d05ef56831183b5b5a09 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 14:18:09 -0300 Subject: [PATCH 5/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 78 +++++++++---------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index ced100d1c..de693ddcd 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Habilitando Implementação Incremental de Recursos Fora do Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, e Andrew Clark +title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora da Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark date: 2023/05/03 -description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante ao que o Meta tem utilizado há muito tempo com versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais React do cronograma de lançamentos do React. +description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta tem usado versões experimentais do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. --- -3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) --- -Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante ao que o Meta tem utilizado há muito tempo com versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais React do cronograma de lançamentos do React. +Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta tem usado versões experimentais do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. @@ -19,73 +19,73 @@ Gostaríamos de oferecer à comunidade React uma opção para adotar novos recur ## tl;dr {/*tldr*/} -* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se houver regressões, trataremos delas com a mesma urgência que erros em lançamentos estáveis. -* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões semver-estáveis. -* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas recursos que acreditamos razoavelmente estar prontos para adoção. Encorajamos frameworks a considerar agrupar lançamentos Canary do React fixados. -* Anunciaremos mudanças quebradoras e novos recursos em nosso blog à medida que eles forem lançados nas versões Canary. -* **Como sempre, o React continua a seguir semver para cada lançamento estável.** +* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se regressões ocorrerem, as trataremos com a mesma urgência que erros em lançamentos estáveis. +* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões estáveis semver. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas recursos que acreditamos razoavelmente que estão prontos para adoção. Incentivamos os frameworks a considerar agrupar lançamentos do React Canary fixados. +* Anunciaremos alterações e novos recursos de ruptura em nosso blog assim que forem incluídos nas lançamentos Canary. +* **Como sempre, o React continua a seguir semver para todos os lançamentos estáveis.** -## Como os recursos do React são geralmente desenvolvidos {/*how-react-features-are-usually-developed*/} +## Como os recursos do React são normalmente desenvolvidos {/*how-react-features-are-usually-developed*/} -Tipicamente, cada recurso do React passou pelas mesmas etapas: +Normalmente, cada recurso do React passa pelas mesmas etapas: -1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Neste ponto, espera-se que o recurso mude significativamente. -2. Encontramos uma equipe no Meta disposta a nos ajudar a testar este recurso e fornecer feedback sobre ele. Isso leva a uma rodada de mudanças. À medida que o recurso se torna mais estável, trabalhamos com mais equipes no Meta para testá-lo. -3. Eventualmente, nos sentimos confiantes no design. Removemos o prefixo do nome da API e tornamos o recurso disponível na branch `main` por padrão, que a maioria dos produtos do Meta usa. Nesse ponto, qualquer equipe no Meta pode usar esse recurso. -4. À medida que construímos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto, sabemos que o design funciona para um amplo conjunto de casos, mas podemos fazer alguns ajustes de última hora. -5. Quando estamos prestes a liberar uma versão open source, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. +1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Nesse ponto, espera-se que o recurso mude significativamente. +2. Encontramos uma equipe na Meta disposta a nos ajudar a testar esse recurso e fornecer feedback. Isso leva a uma rodada de alterações. À medida que o recurso se torna mais estável, trabalhamos com mais equipes da Meta para testá-lo. +3. Por fim, nos sentimos confiantes no design. Removemos o prefixo do nome da API e tornamos o recurso disponível por padrão no branch `main`, que a maioria dos produtos Meta usa. Nesse ponto, qualquer equipe da Meta pode usar esse recurso. +4. À medida que construímos confiança na direção, também postamos uma RFC para o novo recurso. Nesse ponto, sabemos que o design funciona para um amplo conjunto de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos prestes a cortar um lançamento de código aberto, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. -Este manual funciona bem para a maioria dos recursos que já lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (etapa 3) e quando ele é lançado como open source (etapa 5). +Esse playbook funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (passo 3) e quando é lançado em código aberto (passo 5). -**Gostaríamos de oferecer à comunidade React uma opção para seguir o mesmo approach do Meta e adotar novos recursos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** +**Gostaríamos de oferecer à comunidade React uma opção para seguir a mesma abordagem que a Meta e adotar novos recursos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamentos do React.** Como sempre, todos os recursos do React eventualmente farão parte de um lançamento estável. -## Podemos simplesmente fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} +## Podemos apenas fazer mais lançamentos menores? {/*can-we-just-do-more-minor-releases*/} -Geralmente, nós *fazemos* usar lançamentos menores para introduzir novos recursos. +Geralmente, *fazemos* lançamentos menores para introduzir novos recursos. -No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram totalmente concluídos e que ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar sobre as partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, que semver exigiria que fizéssemos. +No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram completamente finalizados e nos quais ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque eles afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar sobre as partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, o que o semver exigiria que fizéssemos. -No Meta, resolvemos esse problema construindo o React a partir da branch `main` e atualizando-o manualmente para um commit fixo específico a cada semana. Esta também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico da branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote novos recursos do React de forma incremental no nível do framework, sem ficar acoplado ao cronograma global de lançamentos do React. +Na Meta, resolvemos esse problema construindo o React a partir do branch `main` e atualizando manualmente para um commit fixado específico a cada semana. Essa também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado em um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote novos recursos do React de forma incremental no nível do framework sem ficar acoplado ao cronograma global de lançamentos do React. -Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *sobre* o React inclua uma mudança quebradora relacionada ao React *antes* que essa mudança quebradora seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas mudanças quebradoras afetam apenas integrações de frameworks. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima do* React inclua uma alteração de ruptura relacionada ao React *antes* que essa alteração de ruptura seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas alterações de ruptura afetam apenas integrações de frameworks. Isso permite que um framework lance tal alteração em sua própria versão menor sem quebrar o semver. -Lançamentos contínuos com o canal Canaries nos permitirão ter um ciclo de feedback mais curto e garantir que novos recursos recebam testes abrangentes na comunidade. Este fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em um lançamento estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. +Lançamentos contínuos com o canal Canary nos permitirão ter um ciclo de feedback mais próximo e garantir que novos recursos sejam amplamente testados na comunidade. Esse fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em etapas numeradas](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos com React antes de serem lançados em uma versão estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. ## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Embora você *possa* tecnicamente usar [lançamentos experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem sofrer mudanças quebradoras significativas em seu caminho para a estabilização (ou podem até ser removidas totalmente). Embora os Canaries também possam conter erros (como qualquer lançamento), vamos anunciar qualquer mudança quebradora significativa nos Canaries em nosso blog. Os Canaries são os mais próximos do código que o Meta executa internamente, então você pode geralmente esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e escanear manualmente o log de commits do GitHub ao atualizar entre os commits fixados. +Embora você *possa* usar tecnicamente [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos contra seu uso em produção porque APIs experimentais podem passar por mudanças significativas de ruptura enquanto estão a caminho da estabilização (ou podem até ser removidas completamente). Embora os Canaries também possam conter erros (como qualquer lançamento), no futuro planejamos anunciar quaisquer mudanças significativas de ruptura nos Canaries em nosso blog. Os Canaries são os mais próximos do código que a Meta executa internamente, portanto, você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e revisar manualmente o log de commits do GitHub ao atualizar entre os commits fixados. -**Esperamos que a maioria das pessoas usando o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos estáveis.** No entanto, se você está construindo um framework, talvez queira considerar agrupar uma versão Canary do React fixada a um commit específico e atualizá-la a seu próprio ritmo. O benefício disso é que permite que você entregue recursos concretos do React e correções de bugs mais cedo para seus usuários e no seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria a responsabilidade adicional de revisar quais commits do React estão sendo puxados e comunicar a seus usuários quais mudanças do React estão incluídas em seus lançamentos. +**Esperamos que a maioria das pessoas usando o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos Estáveis.** No entanto, se você está construindo um framework, pode querer considerar agrupar uma versão Canary do React fixada em um commit específico e atualizá-la em seu próprio ritmo. O benefício disso é que permite que você envie recursos completos individuais do React e correções de bugs mais cedo para seus usuários e em seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria responsabilidade adicional para revisar quais commits do React estão sendo incluídos e comunicar aos seus usuários quais alterações do React estão incluídas em seus lançamentos. -Se você é um autor de framework e quer tentar essa abordagem, entre em contato conosco. +Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. -## Anunciando mudanças quebradoras e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças de ruptura e novos recursos antecipadamente {/*announcing-breaking-changes-and-new-features-early*/} -Os lançamentos Canary representam nossa melhor estimativa do que irá para o próximo lançamento estável do React a qualquer momento. +Os lançamentos Canary representam nossa melhor estimativa do que entrará no próximo lançamento estável do React a qualquer momento. -Tradicionalmente, nós só anunciamos mudanças quebradoras no *final* do ciclo de lançamento (ao fazer um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças quebradoras e novos recursos significativos *à medida que forem lançados* nos Canaries. Por exemplo, se mesclarmos uma mudança quebradora que irá sair em um Canary, escreveremos um post sobre isso em nosso blog do React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está fazendo um lançamento principal que atualiza o canary do React fixado para incluir essa mudança, você pode linkar para nosso post no blog nas suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, iremos linkar para esses posts já publicados no blog, o que esperamos ajudar nossa equipe a avançar mais rapidamente. +Tradicionalmente, apenas anunciamos mudanças de ruptura no *final* do ciclo de lançamento (quando fazemos um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças de ruptura e novos recursos significativos *à medida que surgem* nos Canaries. Por exemplo, se mesclarmos uma mudança de ruptura que será lançada em um Canary, escreveremos uma postagem sobre isso em nosso blog React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está fazendo um lançamento principal que atualiza o canário React fixado para incluir essa alteração, você pode vincular nossa postagem do blog às suas notas de lançamento. Por fim, quando uma versão principal estável do React estiver pronta, vamos vincular a essas postagens do blog já publicadas, o que esperamos que ajude nossa equipe a progredir mais rapidamente. -Planejamos documentar APIs à medida que elas forem lançadas nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. +Planejamos documentar APIs à medida que surgem nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. ## Canaries devem ser fixados {/*canaries-must-be-pinned*/} -Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças quebradoras. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças de ruptura. -## Exemplo: Componentes do Servidor React {/*example-react-server-components*/} +## Exemplo: Componentes de Servidor React {/*example-react-server-components*/} -Como anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes do Servidor React foram finalizadas, e não esperamos mudanças quebradoras significativas relacionadas ao seu contrato de API voltado ao usuário. No entanto, não podemos ainda liberar suporte para Componentes do Servidor React em uma versão estável do React porque ainda estamos trabalhando em várias funcionalidades interligadas apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças quebradoras lá. +Conforme anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes de Servidor React foram finalizadas e não esperamos mudanças significativas de ruptura relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar o suporte para Componentes de Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos interligados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças de ruptura lá. -Isso significa que os Componentes do Servidor React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é enviar uma versão Canary fixada do React. (Para evitar agregar duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que enviam com seu framework e explicar isso a seus usuários. Como exemplo, é isso que o Next.js App Router faz.) +Isso significa que os Componentes de Servidor React estão prontos para ser adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é lançar uma versão Canary fixada do React. (Para evitar empacotar duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que eles enviam com seu framework e explicar isso para seus usuários. Como exemplo, é isso que o Next.js App Router faz.) -## Testando bibliotecas contra versões estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} +## Testando bibliotecas contra versões Estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois isso seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React, encorajamos bibliotecas a executar testes contra *tanto* a versão estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança no comportamento que não foi anunciada, por favor, relate um erro no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, reduza a quantidade de esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam encontradas à medida que fossem lançadas. +Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos, incentivamos bibliotecas a executar testes contra *tanto* a versão Estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança de comportamento que não foi anunciada, por favor, registre um erro no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, isso reduza o esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam encontradas à medida que surgem. -Estritamente falando, Canary não é um canal de lançamento *novo*--ele costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. +Estritamente falando, Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. From 345bce90ec1394d5e7b9361a9211993a00529507 Mon Sep 17 00:00:00 2001 From: Nivaldo Farias Date: Mon, 20 Jan 2025 14:20:10 -0300 Subject: [PATCH 6/6] Translate `react-canaries.md` to pt-br --- src/content/blog/2023/05/03/react-canaries.md | 72 +++++++++---------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/src/content/blog/2023/05/03/react-canaries.md b/src/content/blog/2023/05/03/react-canaries.md index de693ddcd..68bf06187 100644 --- a/src/content/blog/2023/05/03/react-canaries.md +++ b/src/content/blog/2023/05/03/react-canaries.md @@ -1,17 +1,17 @@ --- -title: "React Canaries: Habilitando a Implementação Incremental de Recursos Fora da Meta" -author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage e Andrew Clark +title: "Canários do React: Habilitando Implementação Incremental de Recursos Fora do Meta" +author: Dan Abramov, Sophie Alpert, Rick Hanlon, Sebastian Markbage, e Andrew Clark date: 2023/05/03 -description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta tem usado versões experimentais do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. +description: Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como o Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. --- -3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage) e [Andrew Clark](https://twitter.com/acdlite) +3 de maio de 2023 por [Dan Abramov](https://twitter.com/dan_abramov), [Sophie Alpert](https://twitter.com/sophiebits), [Rick Hanlon](https://twitter.com/rickhanlonii), [Sebastian Markbåge](https://twitter.com/sebmarkbage), e [Andrew Clark](https://twitter.com/acdlite) --- -Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como a Meta tem usado versões experimentais do React internamente há muito tempo. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Ele permite que configurações curadas, como frameworks, desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. +Gostaríamos de oferecer à comunidade React uma opção para adotar novos recursos individuais assim que seu design estiver próximo do final, antes de serem lançados em uma versão estável - semelhante a como o Meta tem usado versões de ponta do React internamente. Estamos introduzindo um novo [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado. Isso permite que configurações curadas como frameworks desacoplem a adoção de recursos individuais do React do cronograma de lançamentos do React. @@ -19,25 +19,25 @@ Gostaríamos de oferecer à comunidade React uma opção para adotar novos recur ## tl;dr {/*tldr*/} -* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se regressões ocorrerem, as trataremos com a mesma urgência que erros em lançamentos estáveis. -* Canaries permitem que você comece a usar novos recursos individuais do React antes que eles sejam lançados nas versões estáveis semver. -* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canaries do React incluem apenas recursos que acreditamos razoavelmente que estão prontos para adoção. Incentivamos os frameworks a considerar agrupar lançamentos do React Canary fixados. -* Anunciaremos alterações e novos recursos de ruptura em nosso blog assim que forem incluídos nas lançamentos Canary. -* **Como sempre, o React continua a seguir semver para todos os lançamentos estáveis.** +* Estamos introduzindo um [canal de lançamento Canary](/community/versioning-policy#canary-channel) oficialmente suportado para o React. Como é oficialmente suportado, se houver qualquer regressão, as trataremos com a mesma urgência que os erros em versões estáveis. +* Canários permitem que você comece a usar novos recursos individuais do React antes que eles estejam disponíveis nas versões semver-estáveis. +* Ao contrário do canal [Experimental](/community/versioning-policy#experimental-channel), os Canários do React incluem apenas recursos que acreditamos razoavelmente estar prontos para adoção. Nós encorajamos frameworks a considerar agrupar lançamentos do React Canary fixados. +* Anunciaremos mudanças que quebram a compatibilidade e novos recursos em nosso blog à medida que forem lançados em versões Canary. +* **Como sempre, o React continua a seguir semver para cada lançamento estável.** -## Como os recursos do React são normalmente desenvolvidos {/*how-react-features-are-usually-developed*/} +## Como os recursos do React são geralmente desenvolvidos {/*how-react-features-are-usually-developed*/} Normalmente, cada recurso do React passa pelas mesmas etapas: -1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Nesse ponto, espera-se que o recurso mude significativamente. -2. Encontramos uma equipe na Meta disposta a nos ajudar a testar esse recurso e fornecer feedback. Isso leva a uma rodada de alterações. À medida que o recurso se torna mais estável, trabalhamos com mais equipes da Meta para testá-lo. -3. Por fim, nos sentimos confiantes no design. Removemos o prefixo do nome da API e tornamos o recurso disponível por padrão no branch `main`, que a maioria dos produtos Meta usa. Nesse ponto, qualquer equipe da Meta pode usar esse recurso. -4. À medida que construímos confiança na direção, também postamos uma RFC para o novo recurso. Nesse ponto, sabemos que o design funciona para um amplo conjunto de casos, mas podemos fazer alguns ajustes de última hora. -5. Quando estamos prestes a cortar um lançamento de código aberto, escrevemos a documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. +1. Desenvolvemos uma versão inicial e a prefixamos com `experimental_` ou `unstable_`. O recurso está disponível apenas no canal de lançamento `experimental`. Neste ponto, espera-se que o recurso mude significativamente. +2. Encontramos uma equipe no Meta disposta a nos ajudar a testar esse recurso e fornecer feedback sobre ele. Isso leva a uma rodada de mudanças. À medida que o recurso se torna mais estável, trabalhamos com mais equipes no Meta para testá-lo. +3. Eventualmente, nos sentimos confiantes no design. Removemos o prefixo do nome da API e tornamos o recurso disponível na ramificação `main` por padrão, que a maioria dos produtos Meta utiliza. Neste ponto, qualquer equipe no Meta pode usar esse recurso. +4. À medida que construímos confiança na direção, também publicamos um RFC para o novo recurso. Neste ponto, sabemos que o design funciona para um amplo conjunto de casos, mas podemos fazer alguns ajustes de última hora. +5. Quando estamos próximos de lançar uma versão de código aberto, escrevemos documentação para o recurso e finalmente lançamos o recurso em uma versão estável do React. -Esse playbook funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (passo 3) e quando é lançado em código aberto (passo 5). +Esse playbook funciona bem para a maioria dos recursos que lançamos até agora. No entanto, pode haver uma lacuna significativa entre quando o recurso está geralmente pronto para uso (etapa 3) e quando é lançado em código aberto (etapa 5). -**Gostaríamos de oferecer à comunidade React uma opção para seguir a mesma abordagem que a Meta e adotar novos recursos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamentos do React.** +**Gostaríamos de oferecer à comunidade React uma opção para seguir a mesma abordagem do Meta e adotar novos recursos individuais mais cedo (à medida que se tornam disponíveis) sem ter que esperar pelo próximo ciclo de lançamento do React.** Como sempre, todos os recursos do React eventualmente farão parte de um lançamento estável. @@ -45,47 +45,47 @@ Como sempre, todos os recursos do React eventualmente farão parte de um lançam Geralmente, *fazemos* lançamentos menores para introduzir novos recursos. -No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram completamente finalizados e nos quais ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não podemos versioná-los separadamente porque eles afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar sobre as partes que não estão prontas sem uma enxurrada de lançamentos de versões principais, o que o semver exigiria que fizéssemos. +No entanto, isso nem sempre é possível. Às vezes, novos recursos estão interconectados com *outros* novos recursos que ainda não foram totalmente concluídos e que ainda estamos iterando ativamente. Não podemos lançá-los separadamente porque suas implementações estão relacionadas. Não conseguimos versioná-los separadamente porque eles afetam os mesmos pacotes (por exemplo, `react` e `react-dom`). E precisamos manter a capacidade de iterar sobre as partes que não estão prontas sem uma série de lançamentos de versão principal, o que a semver exigiria que fizéssemos. -Na Meta, resolvemos esse problema construindo o React a partir do branch `main` e atualizando manualmente para um commit fixado específico a cada semana. Essa também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado em um commit específico do branch `main` do repositório do React. Isso permite que o React Native inclua correções de bugs importantes e adote novos recursos do React de forma incremental no nível do framework sem ficar acoplado ao cronograma global de lançamentos do React. +No Meta, resolvemos esse problema construindo o React a partir da ramificação `main`, e atualizando-o manualmente para um commit fixado específico a cada semana. Esta também é a abordagem que os lançamentos do React Native têm seguido nos últimos anos. Cada lançamento *estável* do React Native é fixado a um commit específico da ramificação `main` do repositório do React. Isso permite que o React Native inclua correções de erros importantes e adote incrementalmente novos recursos do React em nível de framework sem ficar preso ao cronograma global de lançamentos do React. -Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *em cima do* React inclua uma alteração de ruptura relacionada ao React *antes* que essa alteração de ruptura seja incluída em um lançamento estável do React. Isso é particularmente útil porque algumas alterações de ruptura afetam apenas integrações de frameworks. Isso permite que um framework lance tal alteração em sua própria versão menor sem quebrar o semver. +Gostaríamos de tornar esse fluxo de trabalho disponível para outros frameworks e configurações curadas. Por exemplo, isso permite que um framework *sobre* o React inclua uma mudança quebradora relacionada ao React *antes* que essa mudança quebradora seja incluída em uma versão estável do React. Isso é particularmente útil porque algumas mudanças quebradoras afetam apenas integrações de framework. Isso permite que um framework lance tal mudança em sua própria versão menor sem quebrar a semver. -Lançamentos contínuos com o canal Canary nos permitirão ter um ciclo de feedback mais próximo e garantir que novos recursos sejam amplamente testados na comunidade. Esse fluxo de trabalho é mais próximo de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em etapas numeradas](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos com React antes de serem lançados em uma versão estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. +Lançamentos contínuos com o canal Canary nos permitirão ter um ciclo de feedback mais próximo e garantir que novos recursos recebam testes abrangentes na comunidade. Esse fluxo de trabalho se aproxima de como o TC39, o comitê de padrões do JavaScript, [lida com mudanças em estágios numerados](https://tc39.es/process-document/). Novos recursos do React podem estar disponíveis em frameworks construídos sobre o React antes de estarem em uma versão estável do React, assim como novos recursos do JavaScript são lançados em navegadores antes de serem oficialmente ratificados como parte da especificação. ## Por que não usar lançamentos experimentais em vez disso? {/*why-not-use-experimental-releases-instead*/} -Embora você *possa* usar tecnicamente [lançamentos Experimentais](/community/versioning-policy#canary-channel), recomendamos contra seu uso em produção porque APIs experimentais podem passar por mudanças significativas de ruptura enquanto estão a caminho da estabilização (ou podem até ser removidas completamente). Embora os Canaries também possam conter erros (como qualquer lançamento), no futuro planejamos anunciar quaisquer mudanças significativas de ruptura nos Canaries em nosso blog. Os Canaries são os mais próximos do código que a Meta executa internamente, portanto, você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e revisar manualmente o log de commits do GitHub ao atualizar entre os commits fixados. +Embora você *possa* tecnicamente usar [lançamentos experimentais](/community/versioning-policy#canary-channel), recomendamos não usá-los em produção porque APIs experimentais podem sofrer mudanças quebradoras significativas em seu caminho para estabilidade (ou podem até ser removidas completamente). Embora os Canários também possam conter erros (como qualquer lançamento), no futuro planejamos anunciar quaisquer mudanças quebradoras significativas nos Canários em nosso blog. Os Canários são os mais próximos do código que o Meta executa internamente, então você pode esperar que eles sejam relativamente estáveis. No entanto, você *precisa* manter a versão fixada e fazer uma varredura manual no log de commits do GitHub ao atualizar entre os commits fixados. -**Esperamos que a maioria das pessoas usando o React fora de uma configuração curada (como um framework) queira continuar usando os lançamentos Estáveis.** No entanto, se você está construindo um framework, pode querer considerar agrupar uma versão Canary do React fixada em um commit específico e atualizá-la em seu próprio ritmo. O benefício disso é que permite que você envie recursos completos individuais do React e correções de bugs mais cedo para seus usuários e em seu próprio cronograma de lançamentos, semelhante ao que o React Native tem feito nos últimos anos. A desvantagem é que você assumiria responsabilidade adicional para revisar quais commits do React estão sendo incluídos e comunicar aos seus usuários quais alterações do React estão incluídas em seus lançamentos. +**Esperamos que a maioria das pessoas que usam o React fora de uma configuração curada (como um framework) queira continuar usando as versões Estáveis.** No entanto, se você está construindo um framework, pode considerar agrupar uma versão Canary do React fixada a um commit específico e atualizá-la à sua própria velocidade. O benefício disso é que permite que você envie recursos completos do React e correções de erros mais cedo para seus usuários e no seu próprio cronograma de lançamentos, semelhante a como o React Native tem feito nos últimos anos. A desvantagem é que você assumiria uma responsabilidade adicional para revisar quais commits do React estão sendo incorporados e comunicar aos seus usuários quais mudanças do React estão incluídas com seus lançamentos. -Se você é um autor de framework e deseja tentar essa abordagem, entre em contato conosco. +Se você é um autor de framework e deseja experimentar essa abordagem, entre em contato conosco. -## Anunciando mudanças de ruptura e novos recursos antecipadamente {/*announcing-breaking-changes-and-new-features-early*/} +## Anunciando mudanças quebradoras e novos recursos cedo {/*announcing-breaking-changes-and-new-features-early*/} -Os lançamentos Canary representam nossa melhor estimativa do que entrará no próximo lançamento estável do React a qualquer momento. +Os lançamentos Canary representam nosso melhor palpite do que irá para a próxima versão estável do React a qualquer momento. -Tradicionalmente, apenas anunciamos mudanças de ruptura no *final* do ciclo de lançamento (quando fazemos um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir o React, planejamos mudar para anunciar mudanças de ruptura e novos recursos significativos *à medida que surgem* nos Canaries. Por exemplo, se mesclarmos uma mudança de ruptura que será lançada em um Canary, escreveremos uma postagem sobre isso em nosso blog React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework que está fazendo um lançamento principal que atualiza o canário React fixado para incluir essa alteração, você pode vincular nossa postagem do blog às suas notas de lançamento. Por fim, quando uma versão principal estável do React estiver pronta, vamos vincular a essas postagens do blog já publicadas, o que esperamos que ajude nossa equipe a progredir mais rapidamente. +Tradicionalmente, temos anunciado mudanças quebradoras apenas ao *final* do ciclo de lançamento (ao fazer um lançamento principal). Agora que os lançamentos Canary são uma maneira oficialmente suportada de consumir React, planejamos mudar para anunciar mudanças quebradoras e novos recursos significativos *à medida que forem lançados* nos Canários. Por exemplo, se mesclamos uma mudança quebradora que será enviada em um Canary, escreveremos uma postagem sobre isso em nosso blog React, incluindo codemods e instruções de migração, se necessário. Então, se você é um autor de framework lançando uma versão principal que atualiza o canário React fixado para incluir essa mudança, você pode vincular nossa postagem do blog em suas notas de lançamento. Finalmente, quando uma versão principal estável do React estiver pronta, vincularemos essas postagens de blog já publicadas, o que esperamos que ajude nossa equipe a avançar mais rapidamente. -Planejamos documentar APIs à medida que surgem nos Canaries - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canaries serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. +Planejamos documentar APIs à medida que forem lançadas nos Canários - mesmo que essas APIs ainda não estejam disponíveis fora delas. APIs que estão disponíveis apenas nos Canários serão marcadas com uma nota especial nas páginas correspondentes. Isso incluirá APIs como [`use`](https://github.com/reactjs/rfcs/pull/229), e algumas outras (como `cache` e `createServerContext`) para as quais enviaremos RFCs. -## Canaries devem ser fixados {/*canaries-must-be-pinned*/} +## Canários devem ser fixados {/*canaries-must-be-pinned*/} -Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canaries são pré-lançamentos, eles ainda podem incluir mudanças de ruptura. +Se você decidir adotar o fluxo de trabalho Canary para seu aplicativo ou framework, certifique-se de sempre fixar a versão *exata* do Canary que está usando. Como os Canários são pré-lançamentos, eles ainda podem incluir mudanças quebradoras. -## Exemplo: Componentes de Servidor React {/*example-react-server-components*/} +## Exemplo: Componentes de Servidor do React {/*example-react-server-components*/} -Conforme anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes de Servidor React foram finalizadas e não esperamos mudanças significativas de ruptura relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar o suporte para Componentes de Servidor React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos interligados apenas para frameworks (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças de ruptura lá. +Conforme [anunciamos em março](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components), as convenções dos Componentes de Servidor do React foram finalizadas, e não esperamos mudanças quebradoras significativas relacionadas ao seu contrato de API voltado para o usuário. No entanto, não podemos lançar suporte para Componentes de Servidor do React em uma versão estável do React ainda porque ainda estamos trabalhando em vários recursos interligados apenas para framework (como [carregamento de ativos](/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#asset-loading)) e esperamos mais mudanças quebradoras lá. -Isso significa que os Componentes de Servidor React estão prontos para ser adotados por frameworks. No entanto, até o próximo lançamento principal do React, a única maneira de um framework adotá-los é lançar uma versão Canary fixada do React. (Para evitar empacotar duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado que eles enviam com seu framework e explicar isso para seus usuários. Como exemplo, é isso que o Next.js App Router faz.) +Isso significa que os Componentes de Servidor do React estão prontos para serem adotados por frameworks. No entanto, até o próximo lançamento maior do React, a única maneira de um framework adotá-los é enviar uma versão Canary do React fixada. (Para evitar a inclusão de duas cópias do React, frameworks que desejam fazer isso precisariam impor a resolução de `react` e `react-dom` para o Canary fixado com o qual eles enviam seu framework e explicar isso aos seus usuários. Como exemplo, isso é o que o Next.js App Router faz.) ## Testando bibliotecas contra versões Estáveis e Canary {/*testing-libraries-against-both-stable-and-canary-versions*/} -Não esperamos que autores de bibliotecas testem cada lançamento Canary, pois seria proibitivamente difícil. No entanto, assim como quando introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos, incentivamos bibliotecas a executar testes contra *tanto* a versão Estável mais recente quanto a versão Canary mais recente. Se você notar uma mudança de comportamento que não foi anunciada, por favor, registre um erro no repositório do React para que possamos ajudar a diagnosticá-lo. Esperamos que, à medida que essa prática se torne amplamente adotada, isso reduza o esforço necessário para atualizar bibliotecas para novas versões principais do React, já que regressões acidentais seriam encontradas à medida que surgem. +Não esperamos que autores de bibliotecas testem cada lançamento Canary, uma vez que isso seria proibitivamente difícil. No entanto, assim como quando [introduzimos originalmente os diferentes canais de pré-lançamento do React há três anos](https://legacy.reactjs.org/blog/2019/10/22/react-release-channels.html), encorajamos bibliotecas a executar testes contra *tanto* as versões Estáveis mais recentes quanto as versões Canary mais recentes. Se você perceber uma mudança no comportamento que não foi anunciada, please.file um erro no repositório do React para que possamos ajudar a diagnosticar. Esperamos que, à medida que essa prática se torne amplamente adotada, ela reduzirá o esforço necessário para atualizar bibliotecas para novas versões principais do React, uma vez que regressões acidentais seriam encontradas à medida que aparecem. -Estritamente falando, Canary não é um *novo* canal de lançamento - costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com o Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canaries sendo uma maneira oficialmente suportada de usar o React. +Estritamente falando, Canary não é um *novo* canal de lançamento - ele costumava ser chamado de Next. No entanto, decidimos renomeá-lo para evitar confusão com Next.js. Estamos anunciando como um *novo* canal de lançamento para comunicar as novas expectativas, como os Canários sendo uma maneira oficialmente suportada de usar o React.