Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pt-BR translation #38

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,3 +46,4 @@ Will be done with a help of [js-code-to-svg-flowchart tool](https://github.com/B
## Languages
- [Chinese](./stack/languages/chinese/book/Intro.md)
- [Korean](./stack/languages/korean/book/Intro.md)
- [Português](./stack/languages/portuguese/book/Intro.md)
112 changes: 112 additions & 0 deletions stack/languages/portuguese/book/Intro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,112 @@
## Intro

### Esquema, primeira impressão


[![](../images/intro/all-page-stack-reconciler-25-scale.jpg)](../images/intro/all-page-stack-reconciler.svg)

<em>Intro.0 Todo o esquema (clicável)</em>

Vamos dar uma olhada. Sem press. No geral, parece complexo mas na verdade ele descreve só dois processos: montagem e atualização. Eu pulei a desmontagem porque é meio que uma "montagem reversa" e ao remover simplificava o esquema. Aliás, **isso não bate 100%** com o código, e sim só grandes partes que descrevem a arquitetura. No total é mais ou menos 60% do código, mas os outros 40% não traria muito valor visual. Então, novamente, por simplicidade, eu omiti.

Numa primeira impressão, você provavelmente percebeu muitas cores no esquema. Cada item lógico (forma no esquema) está destacado na cor do módulo pai. Por exemplo, o `methodA` será vermelho se for chamado do `moduleB`, que é vermelho. Abaixo tem uma legenda pros módulos no esquema junto com o caminho de cada arquivo.

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/modules-src-path.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/modules-src-path.svg)

<em>Intro.1 Cores dos módulos (clicável)</em>

Vamos colocá-los no esquece pra ver **dependências entre módulos**.

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/files-scheme.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/files-scheme.svg)

<em>Intro.2 Dependências dos módulos (clicável)</em>

Como você provavelmente sabe, React foi feito para **suportar vários ambientes**.

- Mobile (**ReactNative**)
- Browser (**ReactDOM**)
- Renderização do servidor
- **ReactART** (para desenhar vetores gráficos pro React)
- etc.

Como resultado, vários arquivos são na verdade maiores do que parecem no esquema acima. Abaixo, o mesmo esquema com multi-suporte incluído.

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/modules-per-platform-scheme.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/7c2372e1/stack/images/intro/modules-per-platform-scheme.svg)

<em>Intro.3 Dependência de plataformas (clicável)</em>

Como você pode ver, alguns itens parecem duplicados. Isso mostra que eles tem uma implementação separada para cada plataforma. Vamos pegar algo simples como ReactEventListener. Obviamente, sua implementação vai ser diferente para diferentes plataformas!
Tecnicamente, como pode imaginar, esses módulos dependentes de plataformas devem de alguma forma serem injetados ou conectados com o fluxo lógico e, na verdade, existem muitos desses injetores. Devido ao seu uso ser parte de um pattern de composição padrão, escolhi omití-los. De novo, por simplicidade.

Vamos aprender o fluxo lógico do **React DOM** em um **browser padrão**. É a plataforma mais utilizada e cobre completamente todas as ideias arquiteturais do React. Então, vamos lá!


### Amostra de código

Qual é a melhor forma de aprender sobre o código de um framework ou biblioteca? Isso mesmo, lendo e debuggando o código. Beleza, vamos debuggar **dois processos**: **ReactDOM.render** e **componente.setState**, que mapeiam na montagem e na atualização. Vamos olhar o código que podemos escrever do começo. O que precisamos? Provavelmente vários pequenos componentes com renderizações simples, para que seja mais fácil debuggar.

```javascript
class ChildCmp extends React.Component {
render() {
return <div> {this.props.childMessage} </div>
}
}

class ExampleApplication extends React.Component {
constructor(props) {
super(props);
this.state = {message: 'no message'};
}

componentWillMount() {
//...
}

componentDidMount() {
/* setTimeout(()=> {
this.setState({ message: 'timeout state message' });
}, 1000); */
}

shouldComponentUpdate(nextProps, nextState, nextContext) {
return true;
}

componentDidUpdate(prevProps, prevState, prevContext) {
//...
}

componentWillReceiveProps(nextProps) {
//...
}

componentWillUnmount() {
//...
}

onClickHandler() {
/* this.setState({ message: 'click state message' }); */
}

render() {
return <div>
<button onClick={this.onClickHandler.bind(this)}> set state button </button>
<ChildCmp childMessage={this.state.message} />
And some text as well!
</div>
}
}

ReactDOM.render(
<ExampleApplication hello={'world'} />,
document.getElementById('container'),
function() {}
);
```

Estamos pronto para começar. Vamos para a primeira parte do esquema. Um a um, vamos passar por todas elas.

[Próxima página: Parte 0 >>](./Part-0.md)


[Home](../../README.md)
95 changes: 95 additions & 0 deletions stack/languages/portuguese/book/Part-0.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
## Parte 0

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0.svg)

<em>0.0 Parte 0 (clicável)</em>

### ReactDOM.render
Beleza, vamos começar com a chamada do ReactDOM.render.

O ponto de entrada é ReactDom.render. Nosso app inicia sua renderização no DOM por aqui. Criei um componente simples `<ExampleApplication/>` para debuggar mais facilmente. Então, a primeira coisa que acontece é **JSX vai ser transformado em elementos React**. Eles são bem simples, quase objetos em uma estrutura simples. Eles apenas representam o que foi retornado da renderização do componente, nada mais. Alguns campos já devem ser familiares como props, key e ref. Property type se refere ao objeto markup descrito pelo JSX. Então, no nosso caso, é a classe `ExampleApplication`, mas também pode ser apenas a string `button` pra tag Button, etc. Também, durante a criação do elemento React, React vai mergear `defaultProps` com `props` (se tiverem sido especificadas) e validar `propTypes`.

Dá uma olhada no código fonte pra mais detalhes: `src\isomorphic\classic\element\ReactElement.js`.

### ReactMount
Você pode ver o módulo chamado `ReactMount` (01). Ele contém a lógica da montagem de componentes. Na verdade, não existe lógica dentro do `ReactDOM`, é apenas uma interface pra trabalhar com o `ReactMount`, então quando você chama `ReactDOM.render` você tecnicamente chama `ReactMount.render`. O que é essa montagem?
> Montagem é o processo de inicializar um componente React ao criar seus elementos DOM representativos e inserindo eles no `container` fornecido.

Pelo menos o comentário no código descreve dessa forma. Bem, o que isso realmente quer dizer? Beleza, vamos imaginar a próxima transformação:


[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/mounting-scheme-1-small.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/mounting-scheme-1-small.svg)

<em>0.1 JSX para HTML (clicável)</em>

React precisa **transformar as descrições do(s) seu(s) componente(s) em HTML** para colocá-los em um documento. Como fazemos chegar lá? Ele precisa lidar com todas **props, event listeners, compenentes aninhados** e lógica. É necessário granular sua descrição alto nível (componentes) para dados baixo nível (HTML) que podem ser colocados numa página web. Isso é tudo que a montagem é.


[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/mounting-scheme-1-big.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/mounting-scheme-1-big.svg)

<em>0.1 JSX para HTML, estendido (clicável)</em>

Beleza, vamos continuar. Mas... é hora de fatos interessantes! Sim, vamos falar algumas coisas interessantes durante nossa jornada, pra ser mais "divertido".

> Fato interessante: Tenha certeza que o scroll é monitorado (02)

> Engraçado, durante a primeira renderização do componente raiz, o React inicia scroll listeners e cacheia valores do scroll pra que a o código da aplicação consiga acessá-los sem que seja trigado reflows. Na verdade, devido a diferentes implementações de renderizações em browsers, alguns dos valores do DOM não são estáticos, eles são calculados toda vez que você os usa no código. Claro, isso afeta a performance. Na verdade, é apenas pra browsers mais antigos, que não suportam `pageX` e `pageY`. React tenta otimizar isso também. Legal. Como pode ver, fazer uma ferramenta rápida requer o uso de várias técnicas, essa do scroll é um bom exemplo.

### Instanciar o componente React

Olhe para o esquema, há uma criação de instância pelo número (03). Bem, é muito cedo para criar uma instância do `<ExampleApplication />` aqui. Na verdade, nós instanciamos `TopLevelWrapper` (classe interna do React). Vamos dar uma olhada no próximo esquema primeiro.

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/jsx-to-vdom.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/jsx-to-vdom.svg)

<em>0.3 JSX para VDOM (clicável)</em>

Você pode ver três fases, JSX para elementos React serão convertidos em um dos tipos internos de componentes React:
`ReactCompositeComponent` (para nossos próprios componentes), `ReactDOMComponent` (para tags HTML), e `ReactDOMTextComponent` (para nós de texto). Vamos omitir `ReactDOMTextComponent` e vamos apenas focar nos dois primeiros

Componentes internos? Interessante. Você já ouviu falar sobre **DOM Virtual** certo? DOM Virtual é meio que um componente interno do DOM que é usado pelo React pra não tocar diretamente no DOM durante as computações de diff e etc. Isso faz React ser rápido! Mas, na verdade, não há arquivos ou classes dentro do código fonte do React chamado "DOM Virtual". Estranho né? Bem, é porque o DOM Virtual é apenas um conceito, uma maneira de como trabalhar com o DOM real. Então, algumas pessoas dizem que o DOM Virtual se referem aos elementos React, mas na minha opinião, não é bem isso. Acho que o DOM Virtual se refere a essas três classes: `ReactCompositeComponent`, `ReactDOMComponent`, `ReactDOMTextComponent`. Você vai ver mais tarde o porquê.

OK, vamos terminar nossa instanciação aqui. Vamos criar uma instância de `ReactCompositeComponent`, mas na verdade não é porque colocamos `<ExampleApplication/>` no `ReactDOM.render`. React sempre inicia a renderização da árvore do componente pelo `TopLevelWrapper`. É como se fosse um wrapper ocioso, seu `render` (método de render do componente) vai retornar mais tarde `<ExampleApplication/>`, e só.

```javascript
//src\renderers\dom\client\ReactMount.js#277
TopLevelWrapper.prototype.render = function () {
return this.props.child;
};

```

Então, só `TopLevelWrapper` é criado, nada mais por enquanto. Continuando. Mas... antes, um fato interessante!
> Fato interessante: Validando DOM Nesting

> Quase sempre que componentes aninhados estão renderizando, eles estão sendo validados por um módulo dedicado para validação HTML chamado `validateDOMNesting`. Validação de DOM nesting significa verificação da hierarquia de tags `filho -> pai`. Por exemplo se uma tag pai é `<select>`, 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:
<em> &lt;div&gt; cannot appear as a descendant of &lt;p&gt; </em>.

### 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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-A.svg)

<em>0.4 Parte 0 simplificada (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-B.svg)

<em>0.5 Parte 0 simplificado & refatorado (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/0/part-0-C.svg)

<em>0.6 Parte 0 essencial (clicável)</em>

E terminamos!


[Próxima página: Parte 1 >>](./Part-1.md)

[<< Página anterior: Intro](./Intro.md)


[Home](../../README.md)
90 changes: 90 additions & 0 deletions stack/languages/portuguese/book/Part-1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
## Parte 1

[![](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1.svg)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1.svg)

<em>1.0 Parte 1 (clicável)</em>

### 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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/communication-channel.svg)

<em>1.1 Exemplo bem real de uma transação (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/transaction.svg)

<em>1.2 Implementação do Transaction (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-A.svg)

<em>1.3 Parte 1 simplificada (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-B.svg)

<em>1.4 Parte 1 simplificada & refatorada (clicável)</em>

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)](https://rawgit.com/Bogdan-Lyashenko/Under-the-hood-ReactJS/master/stack/images/1/part-1-C.svg)

<em>1.5 Parte 1 essencial (clicável)</em>

E terminamos!


[Próxima página: Parte 2 >>](./Part-2.md)

[<< Página anterior: Parte 0](./Part-0.md)


[Home](../../README.md)
Loading