Merge branch 'master' into dom-attributes-in-react-16

Author: lucaspolizeli

.gitignore

@@ -3,4 +3,5 @@
 .idea
 node_modules
 public
-yarn-error.log
+yarn-error.log
+.vscode/settings.json

GLOSSARY.md

@@ -1,6 +1,6 @@
 # Guia de Estilo Universal
 
-Este documento descreve as regras que devem ser aplicadas para **todos** os idiomas.  
+Este documento descreve as regras que devem ser aplicadas para **todos** os idiomas.
 Quando estiver se referindo ao próprio `React`, use `o React`.
 
 ## IDs dos Títulos
@@ -103,41 +103,41 @@ Sugestões de palavras e termos:
 
 | Palavra/Termo original | Sugestão |
 | ------------------ | ---------- |
+| assertion | asserção |
+| browser | navegador |
 | bubbling | propagar |
 | bug | erro |
-| browser | navegador |
+| class component | componente de classe |
 | class | classe |
+| client | cliente |
+| client-side | lado do cliente |
+| container | contêiner |
 | context | contexto |
 | controlled component | componente controlado |
-| uncontrolled component | componente não controlado |
 | debugging | depuração|
+| DOM node | nó do DOM |
+| event handler | manipulador de eventos (event handler) |
 | function component | componente de função |
-| class component | componente de classe |
+| handler | manipulador |
+| helper function | função auxiliar |
+| high-order components | componente de alta-ordem |
 | key | chave |
 | library | biblioteca |
 | lowercase | minúscula(s) / caixa baixa |
 | package | pacote |
 | React element | Elemento React |
 | React fragment | Fragmento React |
 | render | renderizar (verb), renderizado (noun)
-| uncontrolled component | componente não controlado |
-| uppercase | maiúscula(s) / caixa alta |
-| to wrap | encapsular |
-| to assert | afirmar |
-| assertion | asserção |
 | server | servidor |
 | server-side | lado do servidor |
-| client | cliente |
-| client-side | lado do cliente |
-| high-order components | componente de alta-ordem |
-| stateful logic | lógica com estado |
-| stateful component | componente com estado |
-| container | contêiner |
-| helper function | função auxiliar |
 | siblings | irmãos |
-| DOM node | nó do DOM |
-| handler | manipulador |
-| event handler | manipulador de eventos (event handler) |
+| stateful component | componente com estado |
+| stateful logic | lógica com estado |
+| to assert | afirmar |
+| to wrap | encapsular |
+| uncontrolled component | componente não controlado |
+| uncontrolled component | componente não controlado |
+| uppercase | maiúscula(s) / caixa alta |
 
 ## Conteúdo que não deve ser traduzido
 
@@ -146,28 +146,28 @@ Sugestões de palavras e termos:
 * bind
 * bundle
 * bundler
-* camelCase
 * callback
+* camelCase
 * DOM
+* event listener
 * framework
 * hook
+* log
 * mock
 * portal
 * props
 * ref
+* release
+* script
+* single-page-apps
 * state
 * string
 * string literal
+* subscribe
+* subscription
 * template literal
-* UI
-* log
 * timestamps
-* release
-* script
-* single-page-apps
-* subscription
-* subscribe
-* event listener
-* widgets
+* UI
 * watcher
+* widgets
 * wrapper

content/blog/2015-02-20-introducing-relay-and-graphql.md

@@ -3,15 +3,14 @@ title: "(A => B) !=> (B => A)"
 author: [jimfb]
 ---
 
-The documentation for `componentWillReceiveProps` states that `componentWillReceiveProps` will be invoked when the props change as the result of a rerender. Some people assume this means "if `componentWillReceiveProps` is called, then the props must have changed", but that conclusion is logically incorrect.
+A documentação para `componentWillReceiveProps` diz que `componentWillReceiveProps` será invocado quando as props mudam como resultado de uma re-renderização. Algumas pessoas assumem que isso significa "se `componentWillReceiveProps` é chamado, então as props devem ter mudado", mas essa conclusão é logicamente incorreta.
 
-The guiding principle is one of my favorites from formal logic/mathematics:
- > A implies B does not imply B implies A
+O princípio orientador é um dos meus favoritos da lógica/matemática formal:
+ > A implica B não implica B implica A
 
-Example: "If I eat moldy food, then I will get sick" does not imply "if I am sick, then I must have eaten moldy food". There are many other reasons I could be feeling sick. For instance, maybe the flu is circulating around the office. Similarly, there are many reasons that `componentWillReceiveProps` might get called, even if the props didn’t change.
-
-If you don’t believe me, call `ReactDOM.render()` three times with the exact same props, and try to predict the number of times `componentWillReceiveProps` will get called:
+Exemplo: "Se eu comer comida mofada, eu ficarei doente" não implica "se estou doente, então eu devo ter comido comida mofada". Existem muitas outras razões pelas quais eu poderia estar me sentindo doente. Por exemplo, a gripe tem circulado no escritório. Da mesma forma, existem várias razões para que `componentWillReceiveProps` seja chamado, mesmo que as props não tenham mudado.
 
+Se você não acredita em mim, chame `ReactDOM.render()` três vezes com exatamente as mesmas props, e tente prever o número de vezes que `componentWillReceiveProps` será chamado:
 
 ```js
 class Component extends React.Component {
@@ -31,10 +30,9 @@ ReactDOM.render(<Component data={mydata} />, container);
 ReactDOM.render(<Component data={mydata} />, container);
 ```
 
+Neste caso, a resposta é "2". React chama `componentWillReceiveProps` duas vezes (uma vez para cada um dos dois updates). Nas duas vezes, o valor "drinks" é impresso (isto é, as props não mudaram).
 
-In this case, the answer is "2". React calls `componentWillReceiveProps` twice (once for each of the two updates). Both times, the value of "drinks" is printed (ie. the props didn’t change).
-
-To understand why, we need to think about what *could* have happened. The data *could* have changed between the initial render and the two subsequent updates, if the code had performed a mutation like this:
+Para entender o porquê, precisamos pensar no que *poderia* ter acontecido. Os dados *poderiam* ter mudado entre a renderização inicial e as duas atualizações subsequentes, se o código tivesse realizado uma mutação como essa:
 
 ```js
 var mydata = {bar: 'drinks'};
@@ -45,16 +43,14 @@ mydata.bar = 'noise'
 ReactDOM.render(<Component data={mydata} />, container);
 ```
 
-React has no way of knowing that the data didn’t change. Therefore, React needs to call `componentWillReceiveProps`, because the component needs to be notified of the new props (even if the new props happen to be the same as the old props).
-
-You might think that React could just use smarter checks for equality, but there are some issues with this idea:
-
- * The old `mydata` and the new `mydata` are actually the same physical object (only the object’s internal value changed). Since the references are triple-equals-equal, doing an equality check doesn’t tell us if the value has changed. The only possible solution would be to have created a deep copy of the data, and then later do a deep comparison - but this can be prohibitively expensive for large data structures (especially ones with cycles).
- * The `mydata` object might contain references to functions which have captured variables within closures. There is no way for React to peek into these closures, and thus no way for React to copy them and/or verify equality.
- * The `mydata` object might contain references to objects which are re-instantiated during the parent's render (ie. not triple-equals-equal) but are conceptually equal (ie. same keys and same values). A deep-compare (expensive) could detect this, except that functions present a problem again because there is no reliable way to compare two functions to see if they are semantically equivalent.
+React não tem como saber que os dados não foram alterados. Portanto, React precisa chamar `componentWillReceiveProps`, porque o componente precisa ser notificado sobre as novas props (mesmo se as novas props forem iguais as props antigas).
 
-Given the language constraints, it is sometimes impossible for us to achieve meaningful equality semantics. In such cases, React will call `componentWillReceiveProps` (even though the props might not have changed) so the component has an opportunity to examine the new props and act accordingly.
+Você pode pensar que o React poderia apenas usar verificações mais inteligentes para igualidade, mas há alguns problemas com essa ideia:
 
-As a result, your implementation of `componentWillReceiveProps` MUST NOT assume that your props have changed. If you want an operation (such as a network request) to occur only when props have changed, your `componentWillReceiveProps` code needs to check to see if the props actually changed.
+ * O antigo `mydata` e o novo `mydata` são na verdade o mesmo objeto físico (apenas o valor interno do objeto mudou). Como as referências são triplamente iguais, fazer uma verificação de igualdade não nos diz se o valor mudou. A única solução possível seria ter criado uma cópia profunda dos dados e, posteriormente, fazer uma comparação profunda - mas isso pode ser proibitivamente caro para grandes estruturas de dados (especialmente aquelas com ciclos).
+ * O objeto `mydata` pode conter referências para funções que capturaram variáveis dentro de clausuras. Não há como o React espiar dentro dessas clausuras e, portanto, não há como o React copiá-las e/ou verificar sua igualdade.
+ * O objeto `mydata` pode conter referências a objetos que são re-instanciados durante uma re-renderização do pai (ou seja, não são triplamente igual) mas são conceitualmente iguais (ou seja, mesmas chaves e mesmos valores). Uma comparação profunda (cara) poderia detectar isso, exceto que as funções apresentam um problema novamente porque não há uma forma confiável para comparar duas funções para verificar se elas são semanticamente equivalentes.
 
+Dadas as restrições da linguagem, às vezes é impossível alcançarmos semânticas de igualdade significativas. Nesses casos, o React irá chamar `componentWillReceiveProps` (mesmo que as props não tenham mudado) para que o componente tenha a oportunidade de examinar as novas props e agir de acordo.
 
+Como resultado, sua implementação do `componentWillReceiveProps` NÂO DEVE assumir que suas props foram alteradas. Se você deseja que uma operação (como uma solicitação de rede) ocorra apenas quando props foram alteradas, o código do `componentWillReceiveProps` precisa verificar se as props foram realmente alteradas.

content/blog/2016-01-08-A-implies-B-does-not-imply-B-implies-A.md

@@ -1,10 +1,10 @@
 ---
-title: "Discontinuing IE 8 Support in React DOM"
+title: "Descontinuando o Suporte ao IE 8 no React DOM"
 author: [sophiebits]
 ---
 
-Since its 2013 release, React has supported all popular browsers, including Internet Explorer 8 and above. We handle normalizing many quirks present in old browser versions, including event system differences, so that your app code doesn't have to worry about most browser bugs.
+Desde seu lançamento em 2013, o React oferece suporte a todos os navegadores populares, incluindo o Internet Explorer 8 e superior. Lidamos com a normalização de muitas peculiaridades presentes nas versões antigas do navegador, incluindo diferenças no sistema de eventos, para que o código do seu aplicativo não precise se preocupar com a maioria dos erros do navegador.
 
-Today, Microsoft [discontinued support for older versions of IE](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support). Starting with React v15, we're discontinuing React DOM's support for IE 8. We've heard that most React DOM apps already don't support old versions of Internet Explorer, so this shouldn't affect many people. This change will help us develop faster and make React DOM even better. (We won't actively remove IE 8–related code quite yet, but we will deprioritize new bugs that are reported. If you need to support IE 8 we recommend you stay on React v0.14.)
+Hoje, a Microsoft [interrompeu o suporte para versões mais antigas do IE](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support). A partir do React v15, descontinuamos o suporte do React DOM's para o IE 8. Ouvimos dizer que a maioria dos aplicativos React DOM já não suporta versões antigas do Internet Explorer, portanto, isso não deve afetar muitas pessoas. Essa alteração nos ajudará a desenvolver mais rapidamente e tornar o React DOM ainda melhor. (Ainda não removeremos ativamente o código relacionado ao IE 8, mas nós iremos despriorizar novos bugs que sejam relatados. Se você precisar dar suporte ao IE 8 recomendamos que você permaneça no React v0.14.)
 
-React DOM will continue to support IE 9 and above for the foreseeable future.
+O React DOM continuará a oferecer suporte ao IE 9 e superior no futuro próximo.