Update Docs CI with mdbook translation support (#516)

* Update Docs CI with mdbook translation support #514 * install mdbook with --rev
2022-08-04 10:26:04 -05:00
1 parent df5338f4e6
commit 9538cfe733
@@ -9,7 +9,7 @@ Para evitar a repetição, você pode encapsular a lógica de negócios com base
 Por exemplo, se muitos componentes precisam acessar uma _struct_ `AppSettings`, você pode criar um gancho de "atalho":

 ```rust
-{{#include ../../examples/hooks_composed.rs:wrap_context}}
+{{#include ../../../examples/hooks_composed.rs:wrap_context}}
 ```

 ## Lógica de Hook Personalizada
@@ -7,7 +7,7 @@
 Para renderizar diferentes elementos com base em uma condição, você pode usar uma instrução `if-else`:

 ```rust
-{{#include ../../examples/conditional_rendering.rs:if_else}}
+{{#include ../../../examples/conditional_rendering.rs:if_else}}
 ```

 > Você também pode usar instruções `match`, ou qualquer função Rust para renderizar condicionalmente coisas diferentes.
@@ -17,7 +17,7 @@ Para renderizar diferentes elementos com base em uma condição, você pode usar
 Como `Element` é uma `Option<VNode>`, os componentes que aceitam `Element` como _prop_ podem realmente inspecionar seu conteúdo e renderizar coisas diferentes com base nisso. Exemplo:

 ```rust
-{{#include ../../examples/component_children_inspect.rs:Clickable}}
+{{#include ../../../examples/component_children_inspect.rs:Clickable}}
 ```

 Você não pode modificar o `Element`, mas se precisar de uma versão modificada dele, você pode construir um novo baseado em seus atributos/filhos/etc.
@@ -27,7 +27,7 @@ Você não pode modificar o `Element`, mas se precisar de uma versão modificada
 Para renderizar nada, você pode retornar `None` de um componente. Isso é útil se você deseja ocultar algo condicionalmente:

 ```rust
-{{#include ../../examples/conditional_rendering.rs:conditional_none}}
+{{#include ../../../examples/conditional_rendering.rs:conditional_none}}
 ```

 Isso funciona porque o tipo `Element` é apenas um alias para `Option<VNode>`
@@ -48,7 +48,7 @@ Para isso, o Dioxus aceita iteradores que produzem `Element`s. Então precisamos
 Exemplo: suponha que você tenha uma lista de comentários que deseja renderizar. Então, você pode renderizá-los assim:

 ```rust
-{{#include ../../examples/rendering_lists.rs:render_list}}
+{{#include ../../../examples/rendering_lists.rs:render_list}}
 ```

 ### O Atributo `key`
@@ -9,7 +9,7 @@ Os manipuladores de eventos são semelhantes aos atributos regulares, mas seus n
 Por exemplo, para manipular cliques em um elemento, podemos especificar um manipulador `onclick`:

 ```rust
-{{#include ../../examples/event_click.rs:rsx}}
+{{#include ../../../examples/event_click.rs:rsx}}
 ```

 ## O Objeto `Evento`
@@ -30,7 +30,7 @@ Para saber o que os diferentes tipos de eventos fornecem, leia os [documentos do
 Quando você tem, por exemplo um `button` dentro de um `div`, qualquer clique no `button` também é um clique no `div`. Por esta razão, Dioxus propaga o evento click: primeiro, ele é acionado no elemento alvo, depois nos elementos pai. Se você quiser evitar esse comportamento, você pode chamar `cancel_bubble()` no evento:

 ```rust
-{{#include ../../examples/event_click.rs:rsx}}
+{{#include ../../../examples/event_click.rs:rsx}}
 ```

 ## Prevenir o Padrão
@@ -40,7 +40,7 @@ Alguns eventos têm um comportamento padrão. Para eventos de teclado, isso pode
 Em alguns casos, você pode querer evitar esse comportamento padrão. Para isso, você pode adicionar o atributo `prevent_default` com o nome do manipulador cujo comportamento padrão você deseja interromper. Este atributo é especial: você pode anexá-lo várias vezes para vários atributos:

 ```rust
-{{#include ../../examples/event_prevent_default.rs:prevent_default}}
+{{#include ../../../examples/event_prevent_default.rs:prevent_default}}
 ```

 Quaisquer manipuladores de eventos ainda serão chamados.
@@ -52,13 +52,13 @@ Quaisquer manipuladores de eventos ainda serão chamados.
 Às vezes, você pode querer criar um componente que aceite um manipulador de eventos. Um exemplo simples seria um componente `FancyButton`, que aceita um manipulador `on_click`:

 ```rust
-{{#include ../../examples/event_handler_prop.rs:component_with_handler}}
+{{#include ../../../examples/event_handler_prop.rs:component_with_handler}}
 ```

 Então, você pode usá-lo como qualquer outro manipulador:

 ```rust
-{{#include ../../examples/event_handler_prop.rs:usage}}
+{{#include ../../../examples/event_handler_prop.rs:usage}}
 ```

 > Nota: assim como qualquer outro atributo, você pode nomear os manipuladores como quiser! Embora eles devam começar com `on`, para que o prop seja automaticamente transformado em um `EventHandler` no local da chamada.
@@ -15,7 +15,7 @@ Para lógica com estado, você pode usar _hooks_. _Hooks_ são funções Rust qu
 Por exemplo, você pode ter visto o exemplo do contador, no qual o estado (um número) é rastreado usando o _hook_ `use_state`:

 ```rust
-{{#include ../../examples/hooks_counter.rs:component}}
+{{#include ../../../examples/hooks_counter.rs:component}}
 ```

 ![Screenshot: counter app](./images/counter.png)
@@ -27,7 +27,7 @@ Toda vez que o estado do componente muda, ele é renderizado novamente e a funç
 Você pode usar vários _hooks_ no mesmo componente se quiser:

 ```rust
-{{#include ../../examples/hooks_counter_two_state.rs:component}}
+{{#include ../../../examples/hooks_counter_two_state.rs:component}}
 ```

 ![Screenshot: app with two counters](./images/counter_two_state.png)
@@ -39,7 +39,7 @@ O exemplo acima pode parecer um pouco mágico, já que as funções Rust normalm
 Mas como Dioxus pode diferenciar entre vários _hooks_ no mesmo componente? Como você viu no segundo exemplo, ambas as funções `use_state` foram chamadas com os mesmos parâmetros, então como elas podem retornar coisas diferentes quando os contadores são diferentes?

 ```rust
-{{#include ../../examples/hooks_counter_two_state.rs:use_state_calls}}
+{{#include ../../../examples/hooks_counter_two_state.rs:use_state_calls}}
 ```

 Isso só é possível porque os dois _hooks_ são sempre chamados na mesma ordem, então Dioxus sabe qual é qual. Portanto, a ordem em que você chama os _hooks_ é importante, e é por isso que você deve seguir certas regras ao usar os _hooks_:
@@ -55,19 +55,19 @@ Essas regras significam que há certas coisas que você não pode fazer com _hoo
 ### Sem Hooks em Condicionais

 ```rust
-{{#include ../../examples/hooks_bad.rs:conditional}}
+{{#include ../../../examples/hooks_bad.rs:conditional}}
 ```

 ### Sem Hooks em Closures

 ```rust
-{{#include ../../examples/hooks_bad.rs:closure}}
+{{#include ../../../examples/hooks_bad.rs:closure}}
 ```

 ### Sem Hooks em Loops

 ```rust
-{{#include ../../examples/hooks_bad.rs:loop}}
+{{#include ../../../examples/hooks_bad.rs:loop}}
 ```

 ## Gancho `use_ref`
@@ -81,7 +81,7 @@ Felizmente, existe outro _hook_ para isso, `use_ref`! É semelhante ao `use_stat
 Aqui está um exemplo simples que mantém uma lista de eventos em um `use_ref`. Podemos adquirir acesso de escrita ao estado com `.write()`, e então apenas `.push` um novo valor para o estado:

 ```rust
-{{#include ../../examples/hooks_use_ref.rs:component}}
+{{#include ../../../examples/hooks_use_ref.rs:component}}
 ```

 > Os valores de retorno de `use_state` e `use_ref`, (`UseState` e `UseRef`, respectivamente) são de alguma forma semelhantes a [`Cell`](https://doc.rust-lang.org/std/ cell/) e [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html) – eles fornecem mutabilidade interior. No entanto, esses _wrappers_ do Dioxus também garantem que o componente seja renderizado novamente sempre que você alterar o estado.
@@ -13,7 +13,7 @@ Por exemplo, suponha que queremos construir um editor de memes. Queremos ter uma
 Começamos com um componente `Meme`, responsável por renderizar um meme com uma determinada legenda:

 ```rust
-{{#include ../../examples/meme_editor.rs:meme_component}}
+{{#include ../../../examples/meme_editor.rs:meme_component}}
 ```

 > Observe que o componente `Meme` não sabe de onde vem a legenda – ela pode ser armazenada em `use_state`, `use_ref` ou uma constante. Isso garante que seja muito reutilizável - o mesmo componente pode ser usado para uma galeria de memes sem nenhuma alteração!
@@ -21,13 +21,13 @@ Começamos com um componente `Meme`, responsável por renderizar um meme com uma
 Também criamos um editor de legendas, totalmente desacoplado do meme. O editor de legendas não deve armazenar a legenda em si – caso contrário, como iremos fornecê-la ao componente `Meme`? Em vez disso, ele deve aceitar a legenda atual como um suporte, bem como um manipulador de eventos para delegar eventos de entrada para:

 ```rust
-{{#include ../../examples/meme_editor.rs:caption_editor}}
+{{#include ../../../examples/meme_editor.rs:caption_editor}}
 ```

 Finalmente, um terceiro componente renderizará os outros dois como filhos. Ele será responsável por manter o estado e passar os _props_ relevantes.

 ```rust
-{{#include ../../examples/meme_editor.rs:meme_editor}}
+{{#include ../../../examples/meme_editor.rs:meme_editor}}
 ```

 ![Captura de tela do editor de memes: Um velho esqueleto de plástico sentado em um banco de parque. Legenda: "eu esperando por um recurso de idioma"](./images/meme_editor_screenshot.png)
@@ -47,19 +47,19 @@ A Dioxus oferece uma solução melhor do que esta "perfuração com hélice" –
 Primeiro, temos que criar um _struct_ para nossa configuração de modo escuro:

 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:DarkMode_struct}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:DarkMode_struct}}
 ```

 Agora, em um componente de nível superior (como `App`), podemos fornecer o contexto `DarkMode` para todos os componentes filhos:

 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:context_provider}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:context_provider}}
 ```

 Como resultado, qualquer componente filho de `App` (direto ou não), pode acessar o contexto `DarkMode`.

 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:use_context}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:use_context}}
 ```

 > `use_context` retorna `Option<UseSharedState<DarkMode>>` aqui. Se o contexto foi fornecido, o valor é `Some(UseSharedState)`, que você pode chamar `.read` ou `.write`, similarmente a `UseRef`. Caso contrário, o valor é `None`.
@@ -67,5 +67,5 @@ Como resultado, qualquer componente filho de `App` (direto ou não), pode acessa
 Por exemplo, aqui está como implementaríamos a alternância do modo escuro, que lê o contexto (para determinar a cor que deve renderizar) e grava nele (para alternar o modo escuro):

 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:toggle}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:toggle}}
 ```
@@ -7,7 +7,7 @@ As interfaces geralmente precisam fornecer uma maneira de inserir dados: por exe
 Com entradas controladas, você fica diretamente responsável pelo estado da entrada. Isso lhe dá muita flexibilidade e facilita manter as coisas em sincronia. Por exemplo, é assim que você criaria uma entrada de texto controlada:

 ```rust
-{{#include ../../examples/input_controlled.rs:component}}
+{{#include ../../../examples/input_controlled.rs:component}}
 ```

 Observe a flexibilidade - você pode:
@@ -25,7 +25,7 @@ Como alternativa às entradas controladas, você pode simplesmente deixar a plat
 Como você não tem necessariamente o valor atual da entrada não controlada no estado, você pode acessá-lo ouvindo os eventos `oninput` (de maneira semelhante aos componentes controlados) ou, se a entrada for parte de um formulário, você pode acessar os dados do formulário nos eventos do formulário (por exemplo, `oninput` ou `onsubmit`):

 ```rust
-{{#include ../../examples/input_uncontrolled.rs:component}}
+{{#include ../../../examples/input_uncontrolled.rs:component}}
 ```

 ```