Merge branch 'master' into translate-react-v-16-6

content/blog/2017-12-07-introducing-the-react-rfc-process.md

@@ -1,40 +1,40 @@
 ---
-title: "Introducing the React RFC Process"
+title: "Apresentando o processo React RFC"
 author: [acdlite]
 ---
 
-We're adopting an RFC ("request for comments") process for contributing ideas to React. 
+Estamos adotando um processo de RFC ("request for comments", em português, "Pedido de comentários") para ideias que possam contribuir com o React.
 
-Inspired by [Yarn](https://github.com/yarnpkg/rfcs), [Ember](https://github.com/emberjs/rfcs), and [Rust](https://github.com/rust-lang/rfcs), the goal is to allow React core team members and community members to collaborate on the design of new features. It's also intended to provide a clear path for ideas to enter the project:
+Seguindo o exemplo do [Yarn](https://github.com/yarnpkg/rfcs), [Ember](https://github.com/emberjs/rfcs), e [Rust](https://github.com/rust-lang/rfcs), o objetivo é permitir que membros da equipe principal do React e membros da comunidade possam contribuir no desenvolvimento de novas funcionalidades. Também temos o objetivo de fornecer um caminho claro para a entrada de novas ideias no projeto:
 
-- Create an RFC document detailing your proposal.
-- Submit a PR to the [RFC repository](https://github.com/reactjs/rfcs).
-- Incorporate feedback into the proposal.
-- After discussion, the core team may or may not accept the RFC.
-- If the RFC is accepted, the PR is merged.
+- Crie um documento RFC detalhando seu proposito.
+- Submeta uma PR para o [Repositório RFC](https://github.com/reactjs/rfcs).
+- Coloque seu feedback na proposta.
+- Após a discussão, o time principal pode aceitar ou não o RFC.
+- Se o RFC for aceito, a PR é aceita.
 
-RFCs are accepted when they are approved for implementation in React. A more thorough description of the process is available in the repository's [README](https://github.com/reactjs/rfcs/blob/master/README.md). The exact details may be refined in the future.
+Documentos RFCs são aceitos quando eles são aprovados para implementação no React. Uma descrição mais detalhada do processo está disponível no  [README](https://github.com/reactjs/rfcs/blob/master/README.md) do repositório. Os detalhes exatos podem ser melhorados no futuro.
 
-## Who Can Submit RFCs? {#who-can-submit-rfcs}
+## Quem Pode Submeter RFCs? {#who-can-submit-rfcs}
 
-Anyone! No knowledge of React's internals is required, nor are you expected to implement the proposal yourself.
+Qualquer pessoa! Nenhum conhecimento avançado em React é necessário, também não é esperado que você implemente a proposta sozinho.
 
-As with our other repositories, we do ask that you complete a [Contributor License Agreement](https://github.com/reactjs/rfcs#contributor-license-agreement-cla) before we can accept your PR.
+Como fazemos com nossos outros repositórios, pedimos que você complete um [Contrato de Licença de Contribuidor](https://github.com/reactjs/rfcs#contributor-license-agreement-cla) antes que possamos aceitar sua PR.
 
-## What Types of Changes Should Be Submitted As RFCs? {#what-types-of-changes-should-be-submitted-as-rfcs}
+## Que tipos de alterações devem ser enviadas como RFCs? {#what-types-of-changes-should-be-submitted-as-rfcs}
 
-Generally, any idea that would benefit from additional review or design before being implemented is a good candidate for an RFC. As a rule of thumb, this means any proposal that adds, changes, or removes a React API.
+Geralmente, qualquer ideia que se beneficiaria de uma revisão ou projeto adicional antes de ser implementada é um bom candidato para uma RFC. Como regra geral, isso significa qualquer proposta que adicione, altere, ou remova uma API do React.
 
-Not every change must go through the RFC process. Bug fixes or performance improvements that don't touch the API can be submitted directly to the main library.
+Nem todas as alterações devem passar pelo processo de RFC. Correção de bugs ou melhorias de desempenho que não tocam uma API podem ser enviadas diretamente para a biblioteca principal.
 
-We now have several repositories where you can submit contributions to React:
+Possuímos diversos repositórios onde você pode enviar contribuições para o React:
 
-- **Issues, bugfixes, and code changes to the main library**: [facebook/react](https://github.com/facebook/react)
-- **Website and documentation**: [reactjs/reactjs.org](https://github.com/reactjs/reactjs.org)
-- **Ideas for changes that need additional review before being implemented**: [reactjs/rfcs](https://github.com/reactjs/rfcs)
+- **Erros, Correção de bugs, e alterações de código para a biblioteca principal**: [facebook/react](https://github.com/facebook/react)
+- **Site e documentação**: [reactjs/reactjs.org](https://github.com/reactjs/reactjs.org)
+- **Ideias para alterações que precisam de revisões adicionais antes de serem implementadas**: [reactjs/rfcs](https://github.com/reactjs/rfcs)
 
-## RFC for A New Context API {#rfc-for-a-new-context-api}
+## RFC para uma Nova Context API {#rfc-for-a-new-context-api}
 
-Coinciding with the launch of our RFC process, we've submitted a [proposal for a new version of context](https://github.com/reactjs/rfcs/pull/2). The proposal has already received many valuable comments from the community that we will incorporate into the design of the new API.
+Coincidindo com o lançamento do nosso processo RFC, submetemos uma [proposta para uma nova versão do context](https://github.com/reactjs/rfcs/pull/2). A proposta já recebeu muitos comentários valiosos da comunidade que utilizaremos no projeto da nova API.
 
-The context PR is a good example of how a typical RFC should be structured. We're excited to start receiving your proposals!
+A PR do context é um bom exemplo de como uma RFC deve ser estruturada. Estamos ansiosos para começarmos a receber suas propostas!

content/blog/2018-03-01-sneak-peek-beyond-react-16.md

@@ -1,24 +1,24 @@
 ---
-title: "Sneak Peek: Beyond React 16"
+title: "Espiada: Além do React 16"
 author: [sophiebits]
 ---
 
-[Dan Abramov](https://twitter.com/dan_abramov) from our team just spoke at [JSConf Iceland 2018](https://2018.jsconf.is/) with a preview of some new features we've been working on in React. The talk opens with a question: "With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?"
+O [Dan Abramov](https://twitter.com/dan_abramov) do nosso time acabou de palestrar na [JSConf Iceland 2018](https://2018.jsconf.is/) com uma prévia de alguns novos recursos em que estamos trabalhando no React. A palestra começa com uma pergunta: "Com as vastas diferenças em poder de computação e velocidade de rede, como podemos oferecer a melhor experiência de usuário para todos?"
 
-Here's the video courtesy of JSConf Iceland:
+Aqui está o vídeo cortesia da JSConf Iceland:
 
 <br>
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/nLF0n9SACd4?rel=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
-I think you'll enjoy the talk more if you stop reading here and just watch the video. If you don't have time to watch, a (very) brief summary follows.
+Acho que você irá gostar mais da palestra, se você parar de ler aqui e apenas assistir ao vídeo. Se você não tiver tempo para assistir, segue um (bem) breve resumo.
 
-## About the Two Demos {#about-the-two-demos}
+## Sobre as Duas Demonstrações {#about-the-two-demos}
 
-On the first demo, Dan says: "We've built a generic way to ensure that high-priority updates don't get blocked by a low-priority update, called **time slicing**. If my device is fast enough, it feels almost like it's synchronous; if my device is slow, the app still feels responsive. It adapts to the device thanks to the [requestIdleCallback](https://developers.google.com/web/updates/2015/08/using-requestidlecallback) API. Notice that only the final state was displayed; the rendered screen is always consistent and we don't see visual artifacts of slow rendering causing a janky user experience."
+Na primeira demonstração, Dan diz: "Criamos uma maneira genérica de garantir que as atualizações de alta prioridade não sejam bloqueadas por uma atualização de baixa prioridade, chamada **time slicing**. Se meu dispositivo for rápido o suficiente, parece quase síncrono; se o meu dispositivo estiver lento, o aplicativo ainda parece responsivo. Ele se adapta ao dispositivo graças a API do [requestIdleCallback](https://developers.google.com/web/updates/2015/08/using-requestidlecallback). Entretanto, apenas o estado final será apresentado; a página renderizada é sempre consistente e não vemos artifícios visuais da renderização lenta, causando uma experiência ruim ao usuário.
 
-On the second demo, Dan explains: "We've built a generic way for components to suspend rendering while they load async data, which we call **suspense**. You can pause any state update until the data is ready, and you can add async loading to any component deep in the tree without plumbing all the props and state through your app and hoisting the logic. On a fast network, updates appear very fluid and instantaneous without a jarring cascade of spinners that appear and disappear. On a slow network, you can intentionally design which loading states the user should see and how granular or coarse they should be, instead of showing spinners based on how the code is written. The app stays responsive throughout."
+Na segunda demonstração, Dan explica: "Criamos uma maneira genérica para os componentes suspenderem a renderização enquanto carregam dados assíncronos, que chamamos de **suspense**. Você pode pausar qualquer atualização de estado até que os dados estejam prontos, e também adicionar carregamento assíncrono a qualquer componente no fundo da árvore sem descer todas as props e estados através do seu aplicativo e elevando a lógica. Em uma rede rápida, as atualizações parecem muito fluidas e instantâneas sem uma inconstância de carregamentos que aparecem e desaparecem. Em uma rede lenta, você pode intencionalmente projetar quais os estados de carregamento que o usuário deve ver e como eles devem ser granulares ou grosseiros, em vez de exibir os carregamentos com base em como o código é escrito. O aplicativo permanece responsivo durante todo o processo."
 
-"Importantly, this is still the React you know. This is still the declarative component paradigm that you probably like about React."
+"Importantemente, esse ainda é o React que você conhece. Esse ainda é o paradigma do componente declarativo que você provavelmente gosta no React."
 
-We can't wait to release these new async rendering features later this year. Follow this blog and [@reactjs on Twitter](https://twitter.com/reactjs) for updates.
+Estamos ansiosos para liberar esses novos recursos de renderização assíncrona no final do ano. Siga este blog e [@reactjs no Twitter](https://twitter.com/reactjs) para atualizações.