`, a tag filha deve ser apenas uma dessas: `option`, `optgroup`, ou `#text`. Essas regras são definidas em https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inselect. Você provavelmente já viu esse módulo em ação, ele popula errors como:
+ <div> cannot appear as a descendant of <p> .
+
+### Beleza, terminamos a **Parte 0**
+
+Vamos recapitular o que vimos aqui. Vamos olhar para o esquema mais uma vez, remover as partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-A.svg)
+
+0.4 Parte 0 simplificada (clicável)
+
+E provavelmente devemos arrumar espaços e alinhamentos também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-B.svg)
+
+0.5 Parte 0 simplificado & refatorado (clicável)
+
+Boa. Na verdade, é isso que acontece aqui. Então podemos pegar o essencial da *Parte 0* e usar para o esquema final da `montagem`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-C.svg)
+
+0.6 Parte 0 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 1 >>](./Part-1.md)
+
+[<< Página anterior: Intro](./Intro.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-1.md b/stack/languages/portuguese/book/Part-1.md
new file mode 100644
index 0000000..8e172a1
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-1.md
@@ -0,0 +1,90 @@
+## Parte 1
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1.svg)
+
+1.0 Parte 1 (clicável)
+
+### Transação
+
+Bem, a instância do componente deve ser de alguma forma **conectada** com o ecossistema do React e, obviamente, **ter alguma influência** sobre ela. Tem um módulo dedicado `ReactUpdates` que ajuda com isso. Como você sabe, **React faz atualizações em pedaços**, isso significa que coleta operações e processa elas **juntas**. Isso é sempre melhor porque permite aplicar algumas **pré-condições** e **pós-condições** apenas uma vez para toda a lista de itens (pedaço) ao invés de fazer para cada item.
+
+O que realmente ajuda a lidar com esse pré/pós processamento? Verdade, **transação**! Para alguns pode ser uma palavra nova, ou pelo menos a interpretação para as necessidades de UI, então vamos falar um pouco mais sobre isso e começar com um exemplo simples.
+
+Imagine o "canal de comunicações". Você precisa abrir uma conexão, enviar a mensagem e fechar a conexão. Isso pode ser muito se você enviar várias mensagens uma a uma. Ao invés, você pode abrir a conexão apenas uma vez, mandar todas as mensagens pendentes e fechar a conexão depois.
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/communication-channel.svg)
+
+1.1 Exemplo bem real de uma transação (clicável)
+
+Beleza, vamos pensar em coisas mais abstratas então. Imagine que "mandar mensagem" é qualquer operação que você queira fazer e "abrir/fechar conexão" é pré/pós processamento durante o ato da operação. E então, imagine que você pode definir qualquer par abrir-fechar separadamente e usá-los com quaisquer métodos que você queira (podemos chamá-los de envolvedores (wrappers), porque na verdade, cada par envolve métodos de ações). Soa bem, né?
+
+Voltando ao React. Transação é um pattern muito utilizado dentro do React. Tirando o comportamento de wrapping, a transação permite que a aplicação resete o fluxo de transação, bloquear execuções simultâneas se a transação está já em progresso e mais. Existem muitas classes diferentes de transação, cada uma descreve um comportamento específico, mas todas elas estendem do módulo `Transaction`. As diferenças entre transações são específicas pela lista exata de wrappers de transação. Wrappers são só um objeto que contêm métodos de inicialização e fechamento.
+
+Então, **a ideia é**:
+* chamar cada wrapper.initialize e cachear os valores retornados (podem ser utilizados depois)
+* chamar o próprio método de transação
+* chamar cada wrapper.close
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/transaction.svg)
+
+1.2 Implementação do Transaction (clicável)
+
+Vamos ver alguns **outros casos de uso** para transações em React:
+* Preservar os ranges de inputs de seleção antes/depois da reconciliação restaurando a seleção mesmo no evento de um erro inesperado.
+* Desativando eventos enquanto rearranja o DOM prevenindo focos/blur, enquanto garante que depois, o sistema de eventos é reativado.
+* Fazer um flush de uma fila de mutações do DOM para a thread de UI principal depois que uma reconciliação acontece na thread worker.
+* Invocar qualquer callback coletado de `componentDidUpdate` depois de renderizar o novo conteúdo.
+
+Bem, vamos voltar ao nosso caso.
+
+Como podemos ver, React usa `ReactDefaultBatchingStrategyTransaction` (1). Como já vimos, a principal coisa sobre uma transação são seus wrappers. Então, podemos dar uma olhada nos wrappers e descobrir qual é exatamente a transação definida. Beleza, existem dois wrappers: `FLUSH_BATCHED_UPDATES`, `RESET_BATCHED_UPDATES`. Vamos olhar o código:
+
+```javascript
+//\src\renderers\shared\stack\reconciler\ReactDefaultBatchingStrategy.js#19
+var RESET_BATCHED_UPDATES = {
+ initialize: emptyFunction,
+ close: function() {
+ ReactDefaultBatchingStrategy.isBatchingUpdates = false;
+ },
+};
+
+var FLUSH_BATCHED_UPDATES = {
+ initialize: emptyFunction,
+ close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),
+}
+
+var TRANSACTION_WRAPPERS = [FLUSH_BATCHED_UPDATES, RESET_BATCHED_UPDATES];
+```
+
+Então, você consegue ver qual a cara dele. Para essa transação não há pré-condições. Os métodos `initialize` estão vazios, mas um dos métodos `close` é bem interessante. Ele chama `ReactUpdates.flushBatchedUpdates`. O que isso significa? Ele na verdade inicia a verificação de componentes sujos com mais re-renderização. Está acompanhando? Nós chamamos o método de montagem e fazemos um wrap exatamente nessa transação porque depois da montagem, React checa pra ver o que foi afetado pelo componente montado e o atualiza.
+
+Beleza, vamos dar uma olhada no método que foi feito um wrap na transação. Bem, na verdade, isso nos leva a outra transação...
+
+### Beleza, acabamos a *Parte 1*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-A.svg)
+
+1.3 Parte 1 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-B.svg)
+
+1.4 Parte 1 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 1* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-C.svg)
+
+1.5 Parte 1 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 2 >>](./Part-2.md)
+
+[<< Página anterior: Parte 0](./Part-0.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-10.md b/stack/languages/portuguese/book/Part-10.md
new file mode 100644
index 0000000..dfdd263
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-10.md
@@ -0,0 +1,71 @@
+## Parte 10
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/10/part-10.svg)
+
+10.0 Parte 10 (clicável)
+
+### Componentes sujos
+
+Como pode ver, o React faz o loop pelo `dirtyComponents`(1), e chama `ReactUpdates.runBatchedUpdates`(2), pela transação! Transação? A nova, mas por quê? Vamos ver.
+
+O tipo de transação é `ReactUpdatesFlushTransaction` e, como já mencionamos antes, precisamos checar os `wrappers` pra entender o que a transação realmente faz. Uma pequena dica do comentário do código:
+
+> 'Os wrappers do ReactUpdatesFlushTransaction vão limpar o array do dirtyComponents e fazer qualquer atualização enfileirada pelos handlers prontos para montagem (ou seja, componentDidUpdate)'
+
+Mas, de toda forma, precisamos provar isso. Existem dois wrappers `NESTED_UPDATES` e `UPDATE_QUEUEING`. Na fase `initialize` armazenamos `dirtyComponentsLength` (3) e, como pode ver no `close`, React compara, talvez durante a atualização o número de flush dos componentes sujos mudou, então obviamente é necessário rodar `flushBatchedUpdates` mais uma vez. Sem mágica, tudo bem direto.
+
+Bem... uma mágica na verdade acontece. `ReactUpdatesFlushTransaction` sobrescreve o método `Transaction.perform`, porque... na verdade ele precisa do comportamento do `ReactReconcileTransaction` (transação que é usada durante a montagem e permite manter o estado do app seguro). Então, dentro do método `ReactUpdatesFlushTransaction.perform`, `ReactReconcileTransaction` é usado também, então é feito o wrapper do método da transação mais uma vez
+
+Tecnicamente, ele tem essa cara:
+
+```javascript
+[NESTED_UPDATES, UPDATE_QUEUEING].initialize()
+[SELECTION_RESTORATION, EVENT_SUPPRESSION, ON_DOM_READY_QUEUEING].initialize()
+
+method -> ReactUpdates.runBatchedUpdates
+
+[SELECTION_RESTORATION, EVENT_SUPPRESSION, ON_DOM_READY_QUEUEING].close()
+[NESTED_UPDATES, UPDATE_QUEUEING].close()
+```
+
+Vamos voltar a transação no final para ter certeza de como isso ajuda a terminar o trabalho do método, mas agora vamos ver os detalhes do `ReactUpdates.runBatchedUpdates`(2) (`\src\renderers\shared\stack\reconciler\ReactUpdates.js#125`).
+
+A primeira coisa que devemos fazer logo no início é ordenar o array do `dirtyComponents`. Como ordenar? Pelo `mount order` (número inteiro que foi setado para um componente quando a instância foi montada), isso significa que os pais (que foram montados primeiro) serão atualizados primeiros, os filhos depois, assim por diante.
+
+O próximo passo é aumentarmos o `updateBatchNumber`, é algo como o ID para a reconciliação atual. De acordo com o comentário no código:
+
+> 'Qualquer atualização enfileirada durante a reconciliação precisar ser feitas depois desse batch inteiro. Se não, se o dirtyComponents é [A, B] onde A possui filhos B e C, B poderia ser atualizado duas vezes num único batch se a renderização do C enfilera uma atualização ao B (já que B já foi atualizado, deveríamos pulá-lo, e a única forma de saber se foi é checando a contagem do batch).'
+
+Isso ajuda a evitar atualizações duplicadas para os mesmos componentes.
+
+Parabéns, agora fazemos o loop pelo `dirtyComponents` e passamos cada componente pro `ReactReconciler.performUpdateIfNecessary` (5), onde o método `performUpdateIfNecessary` será chamado pela instância `ReactCompositeComponent`, então, vamos para o código do `ReactCompositeComponent` novamente e seu método `updateComponent`. Podemos achar algo interessante para nós, então, vamos olhar mais a fundo.
+
+### Beleza, terminamos a *Parte 10*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/10/part-10-A.svg)
+
+10.1 Parte 10 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/10/part-10-B.svg)
+
+10.2 Parte 10 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 10* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/10/part-10-C.svg)
+
+10.3 Parte 10 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 11 >>](./Part-11.md)
+
+[<< Página anterior: Parte 9](./Part-9.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-11.md b/stack/languages/portuguese/book/Part-11.md
new file mode 100644
index 0000000..f6b54b8
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-11.md
@@ -0,0 +1,47 @@
+## Parte 11
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/11/part-11.svg)
+
+11.0 Parte 11 (clicável)
+
+### Atualizar componente
+
+Comentário no código que descreve o método diz:
+
+> 'Fazer uma atualização em um componente montado. Os métodos componentWillReceiveProps e shouldComponentUpdate são chamados e então (assumindo que o estado não é pulado) os métodos de atualização do lifecycle que sobraram são chamados e a representação do DOM é atualizada. Por padrão, isso implementa o algoritmo de renderização e reconciliação do React. Clientes sofisticados podem querer sobrescrever isso.'
+
+Beleza... parece fazer sentido.
+
+A primeira coisa que checamos é se as `props` foram mudadas, tecnicamente, o método `updateComponent` pode ser chamado em dois cenários diferentes se `setState` foi chamado ou `props` mudarem. Se `props` foi realmente mudada, então o método de life-cycle `componentWillReceiveProps` será chamado. Depois, React recalcula o `nextState` (2) baseado no `pending state queue` (fila de objetos de estado parcial que fizemos antes, no nosso caso a fila será algo como [{message: "click state message"}]). Claro, no caso de apenas atualização da `props` o estado não será alterado.
+
+Bem, próximo passo, nós fazemos o `shouldUpdate` ter o valor padrão `true` (3). É por isso que quando `shouldComponentUpdate` não está especificado, o componente é atualizado por padrão. Então, checamos se não é `force update`. Como você sabe, é possível chamar `forceUpdate` do componente para atualizá-lo, ao invés de mudar `state` ou `props`, mas, de acordo com a documentação oficial do React, usar esse método é má-prática. Então, no caso de um force update o componente vai ser atualizado permanentemente, se não o método `shouldComponentUpdate` será chamado, e `shouldUpdate` será re-atribuído com o resultado do valor. Se for determinado que um componente não deva ser atualizado, o React ainda precisa setar `props` e `state` mas encurta o resto da atualização.
+
+### Beleza, terminamos a *Parte 11*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/11/part-11-A.svg)
+
+11.1 Parte 11 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/11/part-11-B.svg)
+
+11.2 Parte 11 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 11* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/11/part-11-C.svg)
+
+11.3 Parte 11 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 12 >>](./Part-12.md)
+
+[<< Página anterior: Parte 10](./Part-10.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-12.md b/stack/languages/portuguese/book/Part-12.md
new file mode 100644
index 0000000..73ad4b2
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-12.md
@@ -0,0 +1,72 @@
+## Parte 12
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/12/part-12.svg)
+
+12.0 Parte 12 (clicável)
+
+### Se componentes devem realmente atualizar..
+
+É bem no início da atualização, isso significa que é um bom lugar para chamar o hook `componentWillUpdate` se ele foi especificado (1). Então re-renderizamos o componente e enfileiramos a chamada de mais um método bem conhecido, o `componentDidUpdate` (adiamos a chamada, porque ele deve ser chamado bem no fim da atualização).
+E a re-renderização? Na verdade, o que precisamos fazer aqui é chamar o método `render` do componente e atualizar o DOM de acordo. Então, o primeiro passo, chamamos o método `render` (2) da nossa instância (`ExampleApplication`) e guardamos o resultado da renderização (elementos React que foram retornados de uma chamada de método). Então, comparamos ao elemento previamente renderizado e vemos se o DOM deve ser realmente atualizado.
+
+Essa é uma das melhores features do React, ele evita atualizações redundantes do DOM, o que faz a performance dele ser muito boa.
+Pelo comentário no código, o método `shouldUpdateReactComponent` (3):
+> 'determina se a instância existente deve ser atualizada ao invés de ser destruída ou substituída por uma nova instância'.
+
+Então, resumindo, o método checa se o elemento deve ser completamente substituído, ou seja, o antigo deve ser `unmounted` primeiro, o novo elemento (pegamos do `render`) deve ser montado e markup, recebendo pelo método `mount`, deve ser colocado ao invés do elemento atual, ou, se o elemento deve ser parcialmente atualizado. A principal razão para substituir o elemento completamente é o caso de quando o novo elemento está vazio (foi removido pela lógica do `render`) ou o seu tipo é diferente, ex. era `div` mas agora é outra coisa. Vamos ver o código, é bem simples.
+
+```javascript
+///src/renderers/shared/shared/shouldUpdateReactComponent.js#25
+
+function shouldUpdateReactComponent(prevElement, nextElement) {
+ var prevEmpty = prevElement === null || prevElement === false;
+ var nextEmpty = nextElement === null || nextElement === false;
+ if (prevEmpty || nextEmpty) {
+ return prevEmpty === nextEmpty;
+ }
+
+ var prevType = typeof prevElement;
+ var nextType = typeof nextElement;
+ if (prevType === 'string' || prevType === 'number') {
+ return (nextType === 'string' || nextType === 'number');
+ } else {
+ return (
+ nextType === 'object' &&
+ prevElement.type === nextElement.type &&
+ prevElement.key === nextElement.key
+ );
+ }
+}
+```
+
+Beleza, no caso do nosso `ExampleApplication` nós acabamos de atualizar a propriedade `state` o que não afeta muito o `render` então vamos com o segundo cenário, ou seja `update`.
+
+### Beleza, terminamos a *Parte 12*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/12/part-12-A.svg)
+
+12.1 Parte 12 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/12/part-12-B.svg)
+
+12.2 Parte 12 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 12* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/12/part-12-C.svg)
+
+12.3 Parte 12 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 13 >>](./Part-13.md)
+
+[<< Página anterior: Parte 11](./Part-11.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-13.md b/stack/languages/portuguese/book/Part-13.md
new file mode 100644
index 0000000..19e3c59
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-13.md
@@ -0,0 +1,39 @@
+## Parte 13
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/13/part-13.svg)
+
+13.0 Parte 13 (clicável)
+
+### Receber o componente (próximo elemento, sendo mais preciso)
+
+Bem, pelo `ReactReconciler.receiveComponent` o React na verdade chama `receiveComponente` pelo `ReactDOMComponent` e passa o próximo elemento ali. Faz a reatribuição dele na instância do componente DOM e chama o método de atualização. O método `updateComponent` na verdade faz duas ações: atualiza as propriedades do DOM e os filhos DOM, baseado nas props `prev` e `next`. Bom pra nós, já analisamos o método `_updateDOMProperties` (`src\renderers\dom\shared\ReactDOMComponent.js#946`). Como se lembra, esse método basicamente processa propriedades e atributos de elementos HTML, computa estilos, lida com event listeners, etc. O que sobra é `_updateDOMChildren` (`src\renderers\dom\shared\ReactDOMComponent.js#1076`).
+
+### Beleza, terminamos a *Parte 13*. Essa foi curta.)
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/13/part-13-A.svg)
+
+13.1 Parte 13 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/13/part-13-B.svg)
+
+13.2 Parte 13 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 13* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/13/part-13-C.svg)
+
+13.3 Parte 13 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 14 >>](./Part-14.md)
+
+[<< Página anterior: Parte 12](./Part-12.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-14.md b/stack/languages/portuguese/book/Part-14.md
new file mode 100644
index 0000000..8332c16
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-14.md
@@ -0,0 +1,131 @@
+## Parte 14
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/14/part-14.svg)
+
+14.0 Parte 14 (clicável)
+
+### A última!
+
+O método reconcilia os filhos com as várias propriedades que afetam o conteúdo deles. Há muitos possíveis cenários, mas tecnicamente apenas dois grandes casos. Ou os filhos ainda são 'complexos', ou seja, são componentes React e o React deve passar várias vezes pelas suas camadas até chegar ao nível de conteúdo, ou, os filhos são simples, strings ou números (conteúdo).
+
+O switcher é um tipo de `nextProps.children` (1), e para nosso caso, temos o componente `ExampleApplication` com três filhos: `button`, `ChildCmp` e `text string`.
+
+Beleza, vamos ver como ele funciona.
+
+A primeira iteração com `ExampleApplication children`. Obviamente, o tipo de filho não é 'conteúdo', então vamos para o caso 'complexo'. Pegamos todos os filhos e, um a um passamos por praticamente o mesmo cenário que fizemos com seu componente pai. Aliás, a parte de verificação do `shouldUpdateReactComponent` (2) pode confundir, parece que a verificação verifica a atualização ou não, mas na verdade, ele checa atualização ou deleta&cria (nós pulamos o ramo de NÃO no esquema pra manter simples). Também, depois, comparamos os filhos antigos e os atuais e se algum tiver sido removido, desmontamos o componente e também o removemos.
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/14/children-update.svg)
+
+14.1 Atualização dos filhos (clicável)
+
+Então, na segunda iteração, processamos `button`, esse será nosso caso simples, porque o tipo do botão `children` é do tipo 'text', porque o botão só contém o título 'set state button'. Então checamos se o texto anterior é o mesmo de agora, beleza, o texto não foi alterado, então não precisamos atualizar `button` então? Faz sentido. 'Coisas do DOM Virtual' em ação. Agora fica mais claro, o React mantém a representação interna do DOM e só toca o DOM real se for necessário. Tendo uma excelente performance como resultado.
+
+Então, acho que você já pegou a ideia, colocamos o `ChildCmp` para atualizar, e seus filhos até que chegamos nos itens mais baixo-nível (conteúdo) e sermos capazes de atualizá-los. Seu conteúdo foi modificado, lembra que `this.props.message` é atualizada com o 'click state message' pelas chamadas `click` e `setState`.
+
+```javascript
+//...
+onClickHandler() {
+ this.setState({ message: 'click state message' });
+}
+
+render() {
+ return
+ set state button
+ 14.2 Parte 14 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/14/part-14-B.svg)
+
+14.3 Parte 14 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 14* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/14/part-14-C.svg)
+
+14.4 Parte 14 essencial (clicável)
+
+E terminamos! Na verdade, terminamos com updating. Vamos ver abaixo!
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/14/updating-parts-C.svg)
+
+14.5 Updating (clicável)
+
+[<< Página anterior: Parte 13](./Part-13.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-2.md b/stack/languages/portuguese/book/Part-2.md
new file mode 100644
index 0000000..1e4d53e
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-2.md
@@ -0,0 +1,56 @@
+## Parte 2
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/2/part-2.svg)
+
+2.0 Parte 2 (clicável)
+
+### Mais uma transação
+
+Dessa vez é `ReactReconcileTransaction`. Como você já sabe, o que mais nos interessa é o wrapper da transação. Existem três wrappers:
+
+```javascript
+//\src\renderers\dom\client\ReactReconcileTransaction.js#89
+var TRANSACTION_WRAPPERS = [
+ SELECTION_RESTORATION,
+ EVENT_SUPPRESSION,
+ ON_DOM_READY_QUEUEING,
+];
+```
+
+Como podemos ver esses wrappers são mais usados para **manter o estado atual**, travar alguns valores mutáveis antes de chamadas de métodos, e liberá-los após. Então, o React se assegura que, por exemplo, a lista de seleção (o input de texto atualmente selecionado) não é atrapalhado pelo realização da transação (ser selecionado no `initialize` e restaurar no `close`). Ele também suprime eventos (foco/blur) que podem ser despachados inadvertidamente devido a manipulações de alto nível no DOM (como temporariamente remover um input de texto do DOM) então ele **desabilita `ReactBrowserEventEmitter`** no `initialize` e habilita no `close`.
+
+Bem, estamos bem próximos de iniciar a montagem do componente, que vai nos retornar um markup pronto pra ser colocado no DOM. Na verdade `ReactReconciler.mountComponent` é apenas um wrapper, ou, é mais correto dizer "mediador". Ele delega o método de montagem para os módulos de componentes. Esse é um momento importante, então vamos destacá-lo:
+
+> O módulo`ReactReconciler` sempre é chamado em casos que a implementação de alguma lógica **depende da plataforma**, como esse caso. Montagem é diferente por plataforma, então o "módulo principal" conversa com o `ReactReconciler` e `ReactReconciler` sabe o que fazer depois.
+
+Beleza, vamos para o método do componente `mountComponent`. Provavelmente esse método você já ouviu falar. Ele inicializa o componente, renderiza o markup, e registra os event listeners. Depois de um longo caminho, finalmente vemos uma chamada de montagem de componente. Depois de chamar a montagem, devemos pegar os elementos HTML que por sua vez podem ser colocados no documento.
+
+### Beleza, terminamos a *Parte 2*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/2/part-2-A.svg)
+
+2.1 Parte 2 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/2/part-2-B.svg)
+
+2.2 Parte 2 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 2* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/2/part-2-C.svg)
+
+2.3 Parte 2 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 3 >>](./Part-3.md)
+
+[<< Página anterior: Parte 1](./Part-1.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-3.md b/stack/languages/portuguese/book/Part-3.md
new file mode 100644
index 0000000..d6a0cf7
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-3.md
@@ -0,0 +1,101 @@
+## Parte 3
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/3/part-3.svg)
+
+3.0 Parte 3 (clicável)
+
+### Montagem
+
+O método `componentMount` é uma das maiores partes da nossa jornada! O método que é interessante pra nós é o `ReactCompositeComponent.mountComponent` (1).
+
+Se você se lembra, mencionei que o **primeiro componente que é colocado na árvore de componentes** é o `TopLevelWrapper` (classe interna do React). Aqui, nós vamos montá-lo. Mas... é basicamente um wrapper vazio, então é um pouco tedioso fazer o debug. Ele não afeta o fluxo em nada, então, sugiro pular e ir para o filho.
+
+É assim que a montagem de uma árvore funciona, você monta o pai, depois o filho, e o filho do filho, daí em diante. Depois que o `TopLevelWrapper` é montado, o filho dele (`ReactCompositeComponent`, que gerencia o componente `ExampleApplication`) vai ser colocado na mesma fase.
+
+Beleza, estamos de volta ao passo (1). Vamos ver o que tem dentro. Têm algumas ações importantes que vão acontecer, então vamos discutir a lógica com detalhes.
+
+### Atribuindo uma instância updater
+
+Esse `updater` (2), retornado do `transaction.getUpdateQueue()`, é na verdade o módulo `ReactUpdateQueue`. Então por que é **atribuído aqui**? Bem, porque `ReactCompositoComponent` (a classe que estamos estudando) é usada em todas as plataformas, mas updaters são diferentes, então o atribuímos dinamicamente durante a montagem dependendo da plataforma
+
+Beleza. Não precisamos realmente desse `updater` no momento, mas fique com ele na memória. `updater` é muito **importante**, ele vai ser usado em breve por um método de componente bem conhecido, o **`setState`**.
+
+Na verdade, o `updater` não é só atribuído a uma instância durante essa fase, a instância do componente (seu componente customizado) é também estendido com `props`, `context` e `refs`.
+
+Olhe o código abaixo:
+
+```javascript
+// \src\renderers\shared\stack\reconciler\ReactCompositeComponent.js#255
+// These should be set up in the constructor, but as a convenience for
+// simpler class abstractions, we set them up after the fact.
+inst.props = publicProps;
+inst.context = publicContext;
+inst.refs = emptyObject;
+inst.updater = updateQueue;
+```
+
+E então você consegue acessar `props` no seu código por uma instância, por exemplo `this.props`.
+
+### Criando uma instância ExampleApplication
+
+Ao chamar `_constructComponent` (3) e passando por diversos métodos de construção, finalmente `new ExampleApplication()` vai ser criado. Esse é o momento que o construtor do nosso código será chamado. Então, é a primeira vez que nosso código foi tocado pelo ecossistema do React. Boa.
+
+### Fazendo a montagem inicial
+
+Então, passamos pela montagem (4) e a primeira coisa que deve acontecer aqui é a chamada de `componentWillMount` (se ele for especificado, claro). É o primeiro método que vemos dos life-cycle hooks. Aliás, um pouco mais abaixo você consegue ver `componentDidMOunt`, mas na verdade ele só é colocado na fila de transação porque ele não deve ser chamado diretamente. Só acontece bem no fim, quando as operações de montagem terminaram. Também, você possivelmente poderia adicionar chamadas `setState` dentro de `componentWillMount`. Nesse caso, o estamo com certeza será re-computado, mas sem chamar o método `render` (não faz sentido, porque o componente ainda não está montado).
+
+A documentação oficial prva isso:
+
+> `componentWillMount()` é invocado imediatamente antes da montagem ocorrer. Ele é chamado antes de `render()`, então mudar o estado nesse método não vai resultar numa re-renderização.
+
+Vamos só olhar o código, só pra ter certeza :)
+
+```javascript
+// \src\renderers\shared\stack\reconciler\ReactCompositeComponent.js#476
+if (inst.componentWillMount) {
+ //..
+ inst.componentWillMount();
+
+ // When mounting, calls to `setState` by `componentWillMount` will set
+ // `this._pendingStateQueue` without triggering a re-render.
+ if (this._pendingStateQueue) {
+ inst.state = this._processPendingState(inst.props, inst.context);
+ }
+}
+```
+
+Verdade. Bem, mas quando o `state` é recalculado, nós chamamos o método `render`. Sim, exatamente o que especificamos em nossos componentes! Então, mais um toque no 'nosso' código.
+
+Beleza, agora é criar a instância do componente React. Hm... o que? Parece que já vimos essa chamada `this._instantiateReactComponent`(5) né? É verdade, mas daquela vez instanciamos um `ReactCompositeComponent` para o nosso componente `ExampleAppliaction`. Agora, vamos criar instâncias do DOM Virtual para seu filho baseado no elemento que pegamos do método `render`. Para o nosso caso, o método render retorna `div`, então a representação do DOM Virtual para ele é `ReactDOMComponent`. Quando a instância é criada, chamamos `ReactReconciler.mountComponent` novamente, mas dessa vez como `internalInstance`, nós passamos uma instância de `ReactDOMComponent` recém-criada.
+
+E, chamamos `mountComponent` nela...
+
+### Beleza, terminamos a *Parte 3*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/3/part-3-A.svg)
+
+3.1 Parte 3 simplificada (clicável)
+
+And we should probably fix spaces and alignment as well:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/3/part-3-B.svg)
+
+3.2 Parte 3 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 3* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/3/part-3-C.svg)
+
+3.3 Parte 3 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 4 >>](./Part-4.md)
+
+[<< Página anterior: Parte 2](./Part-2.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-4.md b/stack/languages/portuguese/book/Part-4.md
new file mode 100644
index 0000000..6f26348
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-4.md
@@ -0,0 +1,53 @@
+## Parte 4
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/4/part-4.svg)
+
+4.0 Parte 4 (clicável)
+
+### Montagem do filho
+
+Loucura, né? Vamos continuar com a investigação do método `mount`.
+
+Então, se `_tag` contêm uma tag 'complexa' (1), como video, form, textarea, etc., será necessário wrapping adicional. Isso adiciona mais event listeners para cada evento de mídia, como 'volumeChange' pra tags `audio`, ou apenas faz o wrap de comportamentos nativos de tags como `select`, `textarea`, etc.
+
+Existem muitos wrappers para elementos como esse, como `ReactDOMSelect` e `ReactDOMTextarea` (dentro de src\renderers\dom\client\wrappers\ ). No nosso caso é simplesmente `div`, sem processamento adicional.
+
+### Validação de props
+
+O próximo método de validação é chamado para ter certeza que as `props` internas são setadas corretamente, se não vai resultar em erros. Por exemplo, se `props.dangerouslySetInnerHTML` é setada (geralmente fazemos isso quando tentamos inserir HTML por uma string) e o objeto `__html` está faltando, esse erro irá acontecer:
+
+> `props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. Please visit https://fb.me/react-invariant-dangerously-set-inner-html for more information.
+
+### Criar elemento HTML
+
+Então, o elemento HTML será criado (3) por `document.createElement`, que vai instanciar o HTML real `div` para a gente. Antes trabalhávamos apenas com a representação virtual e agora, você pode ver pela primeira vez.
+
+### Beleza, terminamos a *Parte 4*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/4/part-4-A.svg)
+
+4.1 Parte 4 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/4/part-4-B.svg)
+
+4.2 Parte 4 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 4* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/4/part-4-C.svg)
+
+4.3 Parte 4 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 5 >>](./Part-5.md)
+
+[<< Página anterior: Parte 3](./Part-3.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-5.md b/stack/languages/portuguese/book/Part-5.md
new file mode 100644
index 0000000..edb31ea
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-5.md
@@ -0,0 +1,70 @@
+## Parte 5
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/5/part-5.svg)
+
+5.0 Parte 5 (clicável)
+
+### Atualizar propriedades DOM
+
+Beleza, isso dá um pouco de medo né? A ideia principal é aplicar o diff de forma eficiente da `props` antiga e a nova. Olha o comentário do método no código:
+
+> "Reconcilia as propriedades ao detectar diferenças nos valores da propriedade e atualiza o DOM como necessário. Essa função é provavelmente a parte mais crítica para otimização de performance."
+
+São dois loops na verdade. Primeiro, pelo `props` anterior e depois pelo próximo `props`. No nosso caso, com a montagem, `lastProps` (anterior) é vazia (obviamente, é a primeira vez que atribuímos props), mas, vamos ver o que está acontecendo aqui.
+
+### Último loop em `props`
+
+No primeiro passo, checamos se `nextProps` contém o mesmo valor. Se sim, apenas pulamos, porque vai ser tratado depois no próximo loop de `nextProps`. Então, resetamos os valores de estilo, deletamos event listeners (se eles tiverem sido setados antes), e removemos os atributos e propriedades do DOM. Para atributos, conferimos que não são uma das `RESERVED_PROPS`, que é `prop`, como `children` ou `dangerouslySetInnerHTML`.
+
+### Próximo loop em `props`
+
+Aqui, o primeiro passo é checar se `prop` mudou, ou seja se o próximo valor é diferente do antigo. Se não, não fazemos nada. Para `styles` (você pode ter notado que é tratado de forma levemente diferente) nós atualizamos os valores que mudaram desde `lastProp`. Então, adicionamos os event listeners (sim, exatamente aqueles como `onClick`, etc.). Vamos analisar com mais detalhes.
+
+O importante é, por todo o app React, todo trabalho é passado por eventos 'sintéticos'. Nada especial, são só mais alguns wrappers para um trabalho mais eficiente. A próxima coisa, o módulo mediador para gerenciar event listeners é `EventPluginHub` (`src\renderers\shared\stack\event\EventPluginHub.js`). Ele contém um mapa `listenerBank` para cacheamento e gerenciar todos os listeners.
+
+Nós vamos adicionar nossos event listeners mas não agora. O ponto é que devemos adicionar listeners quando o componente e o elemento DOM está pronto para lidar com eventos. Parece que atrasamos a execução aqui, mas você pode se perguntar, como saberemos quando esse momento chegar? Bem, é hora da próxima resposta! Você lembra que passamos `transaction` por todos os métodos e chamadas? Exatamente! Fizemos isso porque pode ser útil exatamente para esse tipo de situação. Vamos ver o código.
+
+```javascript
+//src\renderers\dom\shared\ReactDOMComponent.js#222
+transaction.getReactMountReady().enqueue(putListener, {
+ inst: inst,
+ registrationName: registrationName,
+ listener: listener,
+});
+```
+
+Ok, depois dos event listeners, setamos os atributos e valores do DOM. Assim como antes, pra atributos precisamos ter certeza que não são uma das `RESERVED_PROPS`, que é uma `prop`, como `children` ou `dangerouslySetInnerHTML`.
+
+Durante o processamento da última e próxima props, computamos a configuração de `styleUpdates` e passamos para o módulo `CSSPropertyOperations`.
+
+Terminamos de atualizar as propriedades. Seguimos.
+
+### Beleza, terminamos a *Parte 5*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/5/part-5-A.svg)
+
+5.1 Parte 5 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/5/part-5-B.svg)
+
+5.2 Parte 5 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 5* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/5/part-5-C.svg)
+
+5.3 Parte 5 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 6 >>](./Part-6.md)
+
+[<< Página anterior: Parte 4](./Part-4.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-6.md b/stack/languages/portuguese/book/Part-6.md
new file mode 100644
index 0000000..6f9c8ad
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-6.md
@@ -0,0 +1,65 @@
+## Parte 6
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/6/part-6.svg)
+
+6.0 Parte 6 (clicável)
+
+### Criar os filhos iniciais
+
+Parece que o elemento em si terminou, então podemos continuar com os filhos. Dois passos aqui: filhos devem ser montados (`this.mountChildren`)(1) e conectados ao pai (`DOMLazyTree.queueChild`)(2). Vamos olhar para a montagem dos filhos porque é obviamente mais interessante.
+
+Existe um módulo separado chamado `ReactMultiChild` (`src\renderers\shared\stack\reconciler\ReactMultiChild.js`) para gerenciar filhos. Boa, vamos olhar o método `mountChildren` então. Ele também contém duas principais tarefas. Primeiro, instaciamos os filhos (usando `ReactChildReconciler` pra isso) e montamos. O que os filhos são aqui? Podem ser uma simples tag HTML ou outro componente customizado. Para lidar com o HTML precisamos instaciar `ReactDOMComponent` e para componentes customizados `ReactCompositeComponent`. O fluxo de montagem, de novo, depende de qual tipo de filho ele é.
+
+### Mais uma vez
+
+Se você ainda está lendo isso, provavelmente é hora de clarificar e revisar o processo geral mais uma vez. Vamos fazer uma pausa e recoletar a sequência de objetos.
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/6/overall-mounting-scheme.svg)
+
+6.1 Esquema geral de montagem (clicável)
+
+1) React instancia `ReactCompositeComponent` pra cada um de seus componentes customizados (com lifecycle hooks como `componentWillMount`, etc.) e o monta.
+
+2) Durante a montagem, inicialmente, uma instância de seu componente customizado será criada (`constructor` é chamado).
+
+3) Então, o método render é chamado (para um exemplo simples, render retorna `div`) e `React.createElement` cria os elementos React. Ele pode ser chamado diretamente ou depois do parsing do JSX pelo Babel e substituindo tags na sua renderização. Mas, não é exatamente o que precisamos, vamos ver o próximo abaixo.
+
+4) Precisamos de um componente DOM para nossa `div`. Então, durante o processo de instanciação, criamos instâncias do `ReactDOMComponent` pelos elementos-objetos (mencionados acima).
+
+5) Então, precisamos montar o componente DOM. Isso significa que criamos os elementos DOM e atribuímos event listeners, etc.
+
+6) Então, processamos os filhos iniciais do nosso componente DOM. Criamos instâncias deles e os montamos também. Dependendo do que cada item dos filhos são, uma componente customizado ou só uma tag HTML, voltamos para o passo 1) ou 5) respectivamente. E então novamente para todos os elementos aninhados.
+
+É isso. Bem direto como pode ver.
+
+Então, a montagem basicamente terminou. Terminou o método `componentDidMount`! Parabéns.
+
+### Beleza, terminamos a *Parte 6*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/6/part-6-A.svg)
+
+6.2 Parte 6 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/6/part-6-B.svg)
+
+6.3 Parte 6 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 6* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/6/part-6-C.svg)
+
+6.4 Parte 6 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 7 >>](./Part-7.md)
+
+[<< Página anterior: Parte 5](./Part-5.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-7.md b/stack/languages/portuguese/book/Part-7.md
new file mode 100644
index 0000000..b0d5c26
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-7.md
@@ -0,0 +1,55 @@
+## Parte 7
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/7/part-7.svg)
+
+7.0 Parte 7 (clicável)
+
+### De volta ao início
+
+Depois da montagem sendo resultado da execução do método, temos elementos HTML prontos para serem inseridos em um documento. Na verdade, `markup` (1) é gerado, mas `mountComponent`, apesar do nome, não é markup HTML. É uma estrutura de dados com campos `children`, `node` (verdadeiros nós do DOM), etc. Mas, temos nosso elemento HTML para inserir no contêiner (aquele especificado como contêiner na chamada `ReactDOM.render`). Enquanto adicionamos no DOM, React vai apagar tudo que estava lá antes. `DOMLazyTree` (2) é uma classe que faz algumas operações com estruturas de dados de árvores, que é o que na verdade fazemos enquanto trabalhamos com o DOM.
+
+A última coisa é `parentNode.insertBefore(tree.node)`(3), em que `parentNode` é o nó contêiner `div` e `tree.node` é nosso nó div `ExampleApplication`. Boa, os elementos HTML que foram criados durante a montagem foram finalmente inseridos no documento.
+
+Então, é isso? Não exatamente. Como pode lembrar, a chamada `mount` foi feito um wrap numa transação. Isso significa que devemos fechá-la. Vamos olhar a lista de wrappers `close`. Basicamente, devemos restaurar alguns comportamentos trancados `ReactInputSelection.restoreSelection()`, `ReactBrowserEventEmitter.setEnabled(previouslyEnabled)`, mas também, precisamos notificar todos os callbacks `this.reactMountReady.notifyAll`(4) que colocamos na fila do `transaction.reactMountReady` antes. Um deles é o nosso conhecido `componentDidMount`, que será disparado exatamente no wrapper `close`.
+
+Agora você tem clareza do que o 'component did mount' significa. Boa!
+
+### Mais uma transação para fechar
+
+Bem, na verdade, essa transação não foi a única. Esquecemos mais uma que foi usada para o wrap da chamada do `ReactMount.batchedMountComponentIntoNode`. Vamos fechá-la também.
+
+Aqui, olhamos o wrapper `ReactUpdates.flushBatchedUpdates`(5), que irá processar `dirtyComponents`. Parece interessante, né? Bem, é uma boa ou má notícia. Acabamos de fazer nossa primeira montagem, então não tem nenhum componente sujo ainda. Isso significa que é uma chamada ociosa. Então, também podemos fechar essa transação e dizer que a estratégia de atualizações em batch terminou.
+
+### Beleza, terminamos a *Parte 7*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/7/part-7-A.svg)
+
+7.1 Parte 7 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/7/part-7-B.svg)
+
+7.2 Parte 7 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 7* e usar para o esquema final de `mounting`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/7/part-7-C.svg)
+
+7.3 Parte 7 essencial (clicável)
+
+E terminamos! Na verdade, terminamos a montagem. Vamos ver abaixo!
+
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/7/mounting-parts-C.svg)
+
+7.4 Montagem (clicável)
+
+[Próxima página: Parte 8 >>](./Part-8.md)
+
+[<< Página anterior: Parte 6](./Part-6.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-8.md b/stack/languages/portuguese/book/Part-8.md
new file mode 100644
index 0000000..9ceb040
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-8.md
@@ -0,0 +1,51 @@
+## Parte 8
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/8/part-8.svg)
+
+8.0 Parte 8 (clicável)
+
+### `this.setState`
+
+Sabemos como a montagem funciona, mas agora, vamos pro outro lado. Sim, o método `setStade`, mais um pedaço do bolo!
+
+Antes de tudo, por que podemos chamar um método chamado `setState`? Bem, isso é bem claro, herdamos nosso componente pelo `ReactComponent`. Beleza, então é fácil achar essa classe no código do React e olhar esse método `setState`.
+
+```javascript
+//src\isomorphic\modern\class\ReactComponent.js#68
+this.updater.enqueueSetState(this, partialState)
+```
+Como pode ver, existe uma interface `updater`. Mas o que `updater` é? Bem, se você checar o processo de montagem que acabamos de analisar, durante `mountComponent`, a instância recebe a propriedade `updater` como uma referência a `ReactUpdateQueue` (`src\renderers\shared\stack\reconciler\ReactUpdateQueue.js`).
+
+Bem, indo fundo dentro do método `enqueueSetState` (1) e vendo que, primeiramente, ele passa o estado parcial (uma estado parcial é um objeto que você passa pelo `this.setState`) para `_pendingStateQueue` (2) de instância interna (apenas pra lembrar: instância pública é na verdade nosso componente customizado `ExampleApplication` e, instância interna é o `ReactCompositeComponent` que foi criado durante a montagem), depois, fazemos o `enqueueUpdate`, que checa se atualizações estão em progresso e colocam nosso componente na lsita de `dirtyComponents`, se não, iniciamos a transação de atualização e colocamos o componente na lista de `dirtyComponents`.
+
+Resumindo, cada componente possui sua própria lista de estados pendentes, ou seja, cada vez que você chama `setState` em uma transação, você só está colocando os objetos numa fila e então depois eles serão mergeados num estado do componente um a um. E, quando você chama `setState`, você adiciona seu componente na lista de `dirtyComponents`. Provavelmente, você está pensando, como o `dirtyComponents` é processado? Certo, essa é a próxima parte importante do quebra-cabeças...
+
+### Beleza, terminamos a *Parte 8*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/8/part-8-A.svg)
+
+8.1 Parte 8 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/8/part-8-B.svg)
+
+8.2 Parte 8 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 8* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/8/part-8-C.svg)
+
+8.3 Parte 8 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 9 >>](./Part-9.md)
+
+[<< Página anterior: Parte 7](./Part-7.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/Part-9.md b/stack/languages/portuguese/book/Part-9.md
new file mode 100644
index 0000000..4ec3544
--- /dev/null
+++ b/stack/languages/portuguese/book/Part-9.md
@@ -0,0 +1,74 @@
+## Parte 9
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/9/part-9.svg)
+
+9.0 Parte 9 (clicável)
+
+### Vamos voltar um pouco...
+
+Como você percebeu no esquema, a chamada do método do `setState`, pode ser disparada de várias formas, com ou sem impacto externo (ou seja, 'ação do usuário'). Vamos pegar dois casos: no primeiro caso, a chamada do método é disparada pelo clique do mouse, e depois, vem do `setTimeout` no `componentDidMount`.
+
+O que realmente faz essa diferença? Bem, como você se lembra, o React processa atualizações em massa (`batches`), isso significa que a lista de atualizações devem ser de alguma forma coletadas e depois fazer o `flush`. Mas quando o evento do mouse aparece, ele é tratado no topo e depois, passando por diversas camadas de wrappers, a atualização vai iniciar.
+
+Aliás, como pode ver isso acontece somente se `ReactEventListener` está `enabled` (1), e, se você se lembra, durante a fase de montagem do componente, um dos wrappers de `ReactReconcileTransaction` o desabilita e faz a montagem ser segura. Inteligente! Mas, e o caso do `setTimeout`? Também é simples, antes de colocar um componente na lista de `dirtyComponents`, o React vai se certificar que a transação iniciou (foi aberta), e então depois, vai ser fechada e fazer o flush das atualizações.
+
+Como você sabe, React implementa 'eventos sintéticos', um 'açúcar sintático' que na verdade faz o wrap em eventos nativos. Mas depois, eles ainda tentam se comportar como estamos acostumados com eventos. Você pode ver o comentário no código:
+
+> 'Para ajudar o desenvolvimento podemos ter uma melhor integração com ferramentas dev ao simular um evento real do browser'
+
+```javascript
+var fakeNode = document.createElement('react');
+
+ReactErrorUtils.invokeGuardedCallback = function (name, func, a) {
+ var boundFunc = func.bind(null, a);
+ var evtType = 'react-' + name;
+
+ fakeNode.addEventListener(evtType, boundFunc, false);
+
+ var evt = document.createEvent('Event');
+ evt.initEvent(evtType, false, false);
+
+ fakeNode.dispatchEvent(evt);
+ fakeNode.removeEventListener(evtType, boundFunc, false);
+};
+```
+Beleza, de volta às nossas atualizações mais uma vez. A abordagem é:
+
+1. Chamar setState
+2. Abrir transação de batching se não estiver aberta ainda
+3. Adicionar componentes afetados à lista `dirtyComponents`
+4. Fechar transação chamando `ReactUpdates.flushBatchedUpdates`, que na verdade significa 'processar tudo que foi coletado no `dirtyComponents`'.
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/9/set-state-update-start.svg)
+
+9.1 `setState` inicia (clicável)
+
+### Beleza, terminamos a *Parte 9*.
+
+Vamos recapitular como chegamos aqui. Vamos olhar o esquema mais uma vez, e remover partes redundantes menos importantes e fica assim:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/9/part-9-A.svg)
+
+9.2 Parte 9 simplificada (clicável)
+
+E devemos provavelmente arrumar espaçamento e alinhamento também:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/9/part-9-B.svg)
+
+9.3 Parte 9 simplificada & refatorada (clicável)
+
+Boa. Na verdade, é isso o que acontece aqui. Então podemos pegar o essencial da *Parte 9* e usar para o esquema final de `updating`:
+
+[](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/9/part-9-C.svg)
+
+9.6 Parte 9 essencial (clicável)
+
+E terminamos!
+
+
+[Próxima página: Parte 10 >>](./Part-10.md)
+
+[<< Página anterior: Parte 8](./Part-8.md)
+
+
+[Home](../../README.md)
diff --git a/stack/languages/portuguese/book/README.md b/stack/languages/portuguese/book/README.md
new file mode 100644
index 0000000..2782c33
--- /dev/null
+++ b/stack/languages/portuguese/book/README.md
@@ -0,0 +1,41 @@
+# Under the hood: React
+ Esse repositório contém uma explicação das partes internas do React. Na verdade, estava debuggando por todo o código e coloquei toda a lógica em esquemas visuais, fiz a análise, resumi e expliquei os principais conceitos e abordagens. já terminei com a versão Stack e agora trabalho com a próxima, a versão Fiber.
+
+### Queria automatizar o processo de "aprender e documentar" uma codebase complexa o máximo possível, então iniciar o [Codecrumbs project](https://codecrumbs.io/). Ele vai ajudar a construir projetos como o "Under the hood ReactJs" num tempo mais curto e de forma mais simples!
+
+
+Cada esquema é clicável e pode ser aberto numa nova aba, use para fazer zoom e conseguir fazer a leitura. Mantenha o artigo e o esquema que você está lendo em abas separadas, isso vai ajudar a bater o texto com o fluxo de código mais facilmente.
+
+Vamos falar aqui sobre as duas versões de React, atual com o reconciliados Stack e a próxima com Fiber (como você provavelmente sabe, a próxima versão de React será lançada em breve), então, você pode entender melhor como a versão atual de React funciona e dar valor pros grandes avanços do React-Fiber. Utilizamos o [React v15.4.2](https://github.com/facebook/react/tree/v15.4.2) para explicar como 'React legado' funciona e React v16.*.*** para ‘Fiber’. Vamos começar da antiga (me divirto dizendo isso) versão stack.
+
+
+## Reconciliador stack
+[](../../../../stack/images/intro/all-page-stack-reconciler.svg)
+
+O esquema inteiro é dividido em 15 partes, vamos iniciar.
+
+> Leia em um melhor formado pelo [github-pages](https://bogdan-lyashenko.github.io/Under-the-hood-ReactJS/).
+
+* [Intro](../../../../stack/languages/portuguese/book/Intro.md)
+* [Parte 0](../../../../stack/languages/portuguese/book/Part-0.md)
+* [Parte 1](../../../../stack/languages/portuguese/book/Part-1.md)
+* [Parte 2](../../../../stack/languages/portuguese/book/Part-2.md)
+* [Parte 3](../../../../stack/languages/portuguese/book/Part-3.md)
+* [Parte 4](../../../../stack/languages/portuguese/book/Part-4.md)
+* [Parte 5](../../../../stack/languages/portuguese/book/Part-5.md)
+* [Parte 6](../../../../stack/languages/portuguese/book/Part-6.md)
+* [Parte 7](../../../../stack/languages/portuguese/book/Part-7.md)
+* [Parte 8](../../../../stack/languages/portuguese/book/Part-8.md)
+* [Parte 9](../../../../stack/languages/portuguese/book/Part-9.md)
+* [Parte 10](../../../../stack/languages/portuguese/book/Part-10.md)
+* [Parte 11](../../../../stack/languages/portuguese/book/Part-11.md)
+* [Parte 12](../../../../stack/languages/portuguese/book/Part-12.md)
+* [Parte 13](../../../../stack/languages/portuguese/book/Part-13.md)
+* [Parte 14](../../../../stack/languages/portuguese/book/Part-14.md)
+
+
+
+## Fiber
+Vai ser feito com a ajuda da [ferramenta js-code-to-svg-flowchart](https://github.com/Bogdan-Lyashenko/js-code-to-svg-flowchart) depois.
+
+