Update Docs CI with mdbook translation support (#516)

* Update Docs CI with mdbook translation support #514

* install mdbook with --rev

.github/workflows/docs.yml

@@ -15,10 +15,16 @@ jobs:
     steps:
       - uses: actions/checkout@v2
 
+      # NOTE: Comment out when https://github.com/rust-lang/mdBook/pull/1306 is merged and released
+      # - name: Setup mdBook
+      #   uses: peaceiris/actions-mdbook@v1
+      #   with:
+      #     mdbook-version: "0.4.10"
+
+      # NOTE: Delete when the previous one is enabled
       - name: Setup mdBook
-        uses: peaceiris/actions-mdbook@v1
-        with:
-          mdbook-version: "0.4.10"
+        run: |
+          cargo install mdbook --git https://github.com/Ruin0x11/mdBook.git --branch localization --rev e74fdb1
 
       - name: Build
         run: cd docs &&

docs/guide/book.toml

@@ -34,5 +34,5 @@ boost-paragraph = 1
 expand = true
 heading-split-level = 2
 
-[output.html.redirect]
-"/format/config.html" = "configuration/index.html"
+# [output.html.redirect]
+# "/format/config.html" = "configuration/index.html"

docs/guide/src/en/__unused/event_javascript.rs

@@ -4,7 +4,7 @@
 Instead of passing a closure, you can also pass a string to event handlers – this lets you use JavaScript (if your renderer can execute JavaScript):
 
 ```rust
-{{#include ../../examples/event_javascript.rs:rsx}}
+{{#include ../../../examples/event_javascript.rs:rsx}}
 ```
 
 

docs/guide/src/en/async/spawn.md

@@ -3,7 +3,7 @@
 The `use_future` and `use_coroutine` hooks are useful if you want to unconditionally spawn the future. Sometimes, though, you'll want to only spawn a future in response to an event, such as a mouse click. For example, suppose you need to send a request when the user clicks a "log in" button. For this, you can use `cx.spawn`:
 
 ```rust
-{{#include ../../examples/spawn.rs:spawn}}
+{{#include ../../../examples/spawn.rs:spawn}}
 ```
 
 > Note: `spawn` will always spawn a *new* future. You most likely don't want to call it on every render.
@@ -15,7 +15,7 @@ However, since you'll typically need a way to update the value of a hook, you ca
 To make this a bit less verbose, Dioxus exports the `to_owned!` macro which will create a binding as shown above, which can be quite helpful when dealing with many values.
 
 ```rust
-{{#include ../../examples/spawn.rs:to_owned_macro}}
+{{#include ../../../examples/spawn.rs:to_owned_macro}}
 ```
 
 Calling `spawn` will give you a `JoinHandle` which lets you cancel or pause the future.
@@ -25,5 +25,5 @@ Calling `spawn` will give you a `JoinHandle` which lets you cancel or pause the
 Sometimes, you might want to spawn a background task that needs multiple threads or talk to hardware that might block your app code. In these cases, we can directly spawn a Tokio task from our future. For Dioxus-Desktop, your task will be spawned onto Tokio's Multithreaded runtime:
 
 ```rust
-{{#include ../../examples/spawn.rs:tokio}}
+{{#include ../../../examples/spawn.rs:tokio}}
 ```

docs/guide/src/en/async/use_future.md

@@ -5,7 +5,7 @@
 For example, we can make an API request inside `use_future`:
 
 ```rust
-{{#include ../../examples/use_future.rs:use_future}}
+{{#include ../../../examples/use_future.rs:use_future}}
 ```
 
 The code inside `use_future` will be submitted to the Dioxus scheduler once the component has rendered.
@@ -15,7 +15,7 @@ We can use `.value()` to get the result of the future. On the first run, since t
 We can then render that result:
 
 ```rust
-{{#include ../../examples/use_future.rs:render}}
+{{#include ../../../examples/use_future.rs:render}}
 ```
 
 
@@ -29,5 +29,5 @@ Often, you will need to run the future again every time some value (e.g. a prop)
 
 
 ```rust
-{{#include ../../examples/use_future.rs:dependency}}
+{{#include ../../../examples/use_future.rs:dependency}}
 ```

docs/guide/src/en/best_practices/antipatterns.md

@@ -9,7 +9,7 @@ Fragments don't mount a physical element to the DOM immediately, so Dioxus must
 Only Component and Fragment nodes are susceptible to this issue. Dioxus mitigates this with components by providing an API for registering shared state without the Context Provider pattern.
 
 ```rust
-{{#include ../../examples/anti_patterns.rs:nested_fragments}}
+{{#include ../../../examples/anti_patterns.rs:nested_fragments}}
 ```
 
 ## Incorrect Iterator Keys
@@ -17,7 +17,7 @@ Only Component and Fragment nodes are susceptible to this issue. Dioxus mitigate
 As described in the conditional rendering chapter, list items must have unique keys that are associated with the same items across renders. This helps Dioxus associate state with the contained components, and ensures good diffing performance. Do not omit keys, unless you know that the list is static and will never change.
 
 ```rust
-{{#include ../../examples/anti_patterns.rs:iter_keys}}
+{{#include ../../../examples/anti_patterns.rs:iter_keys}}
 ```
 
 ## Avoid Interior Mutability in Props

docs/guide/src/en/describing_ui/component_children.md

@@ -3,13 +3,13 @@
 In some cases, you may wish to create a component that acts as a container for some other content, without the component needing to know what that content is. To achieve this, create a prop of type `Element`:
 
 ```rust
-{{#include ../../examples/component_element_props.rs:Clickable}}
+{{#include ../../../examples/component_element_props.rs:Clickable}}
 ```
 
 Then, when rendering the component, you can pass in the output of `cx.render(rsx!(...))`:
 
 ```rust
-{{#include ../../examples/component_element_props.rs:Clickable_usage}}
+{{#include ../../../examples/component_element_props.rs:Clickable_usage}}
 ```
 
 > Note: Since `Element<'a>` is a borrowed prop, there will be no memoization.
@@ -21,11 +21,11 @@ Then, when rendering the component, you can pass in the output of `cx.render(rsx
 Rather than passing the RSX through a regular prop, you may wish to accept children similarly to how elements can have children. The "magic" `children` prop lets you achieve this:
 
 ```rust
-{{#include ../../examples/component_children.rs:Clickable}}
+{{#include ../../../examples/component_children.rs:Clickable}}
 ```
 
 This makes using the component much simpler: simply put the RSX inside the `{}` brackets – and there is no need for a `render` call or another macro!
 
 ```rust
-{{#include ../../examples/component_children.rs:Clickable_usage}}
+{{#include ../../../examples/component_children.rs:Clickable_usage}}
 ```

docs/guide/src/en/describing_ui/component_props.md

@@ -20,12 +20,12 @@ There are 2 flavors of Props structs:
 Owned Props are very simple – they don't borrow anything. Example:
 
 ```rust
-{{#include ../../examples/component_owned_props.rs:Likes}}
+{{#include ../../../examples/component_owned_props.rs:Likes}}
 ```
 
 You can then pass prop values to the component the same way you would pass attributes to an element:
 ```rust
-{{#include ../../examples/component_owned_props.rs:App}}
+{{#include ../../../examples/component_owned_props.rs:App}}
 ```
 
 ![Screenshot: Likes component](./images/component_owned_props_screenshot.png)
@@ -37,13 +37,13 @@ Owning props works well if your props are easy to copy around – like a single
 Rust allows for something more efficient – borrowing the String as a `&str` – this is what Borrowed Props are for!
 
 ```rust
-{{#include ../../examples/component_borrowed_props.rs:TitleCard}}
+{{#include ../../../examples/component_borrowed_props.rs:TitleCard}}
 ```
 
 We can then use the component like this:
 
 ```rust
-{{#include ../../examples/component_borrowed_props.rs:App}}
+{{#include ../../../examples/component_borrowed_props.rs:App}}
 ```
 ![Screenshot: TitleCard component](./images/component_borrowed_props_screenshot.png)
 
@@ -57,13 +57,13 @@ The `#[derive(Props)]` macro has some features that let you customize the behavi
 You can create optional fields by using the `Option<…>` type for a field:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:OptionalProps}}
+{{#include ../../../examples/component_props_options.rs:OptionalProps}}
 ```
 
 Then, you can choose to either provide them or not:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:OptionalProps_usage}}
+{{#include ../../../examples/component_props_options.rs:OptionalProps_usage}}
 ```
 
 ### Explicitly Required `Option`s
@@ -71,13 +71,13 @@ Then, you can choose to either provide them or not:
 If you want to explicitly require an `Option`, and not an optional prop, you can annotate it with `#[props(!optional)]`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:ExplicitOption}}
+{{#include ../../../examples/component_props_options.rs:ExplicitOption}}
 ```
 
 Then, you have to explicitly pass either `Some("str")` or `None`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:ExplicitOption_usage}}
+{{#include ../../../examples/component_props_options.rs:ExplicitOption_usage}}
 ```
 
 ### Default Props
@@ -85,13 +85,13 @@ Then, you have to explicitly pass either `Some("str")` or `None`:
 You can use `#[props(default = 42)]` to make a field optional and specify its default value:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:DefaultComponent}}
+{{#include ../../../examples/component_props_options.rs:DefaultComponent}}
 ```
 
 Then, similarly to optional props, you don't have to provide it:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:DefaultComponent_usage}}
+{{#include ../../../examples/component_props_options.rs:DefaultComponent_usage}}
 ```
 
 ### Automatic Conversion with `.into`
@@ -99,13 +99,13 @@ Then, similarly to optional props, you don't have to provide it:
 It is common for Rust functions to accept `impl Into<SomeType>` rather than just `SomeType` to support a wider range of parameters. If you want similar functionality with props, you can use `#[props(into)]`. For example, you could add it on a `String` prop – and `&str` will also be automatically accepted, as it can be converted into `String`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:IntoComponent}}
+{{#include ../../../examples/component_props_options.rs:IntoComponent}}
 ```
 
 Then, you can use it so:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:IntoComponent_usage}}
+{{#include ../../../examples/component_props_options.rs:IntoComponent_usage}}
 ```
 
 ## The `inline_props` macro

docs/guide/src/en/describing_ui/components.md

@@ -5,7 +5,7 @@ Just like you wouldn't want to write a complex program in a single, long, `main`
 A component is a Rust function, named in UpperCammelCase, that takes a `Scope` parameter and returns an `Element` describing the UI it wants to render. In fact, our `App` function is a component!
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:component}}
+{{#include ../../../examples/hello_world_desktop.rs:component}}
 ```
 
 > You'll probably want to add `#![allow(non_snake_case)]` to the top of your crate to avoid warnings about the function name
@@ -13,13 +13,13 @@ A component is a Rust function, named in UpperCammelCase, that takes a `Scope` p
 A Component is responsible for some rendering task – typically, rendering an isolated part of the user interface. For example, you could have an `About` component that renders a short description of Dioxus Labs:
 
 ```rust
-{{#include ../../examples/components.rs:About}}
+{{#include ../../../examples/components.rs:About}}
 ```
 
 Then, you can render your component in another component, similarly to how elements are rendered:
 
 ```rust
-{{#include ../../examples/components.rs:App}}
+{{#include ../../../examples/components.rs:App}}
 ```
 
 ![Screenshot containing the About component twice](./images/screenshot_about_component.png)

docs/guide/src/en/describing_ui/index.md

@@ -5,7 +5,7 @@ Dioxus is a *declarative* framework. This means that instead of telling Dioxus w
 You have already seen a simple example or RSX syntax in the "hello world" application:
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:component}}
+{{#include ../../../examples/hello_world_desktop.rs:component}}
 ```
 
 Here, we use the `rsx!` macro to *declare* that we want a `div` element, containing the text `"Hello, world!"`. Dioxus takes the RSX and constructs a UI from it.
@@ -15,7 +15,7 @@ Here, we use the `rsx!` macro to *declare* that we want a `div` element, contain
 RSX is very similar to HTML in that it describes elements with attributes and children. Here's an empty `div` element in RSX, as well as the resulting HTML:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:empty}}
+{{#include ../../../examples/rsx_overview.rs:empty}}
 ```
 ```html
 <div></div>
@@ -23,10 +23,10 @@ RSX is very similar to HTML in that it describes elements with attributes and ch
 
 ### Children
 
-To add children to an element, put them inside the `{}` brackets. They can be either other elements, or text. For example, you could have an `ol` (ordered list) element, containing 3 `li` (list item) elements, each of which contains some text: 
+To add children to an element, put them inside the `{}` brackets. They can be either other elements, or text. For example, you could have an `ol` (ordered list) element, containing 3 `li` (list item) elements, each of which contains some text:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:children}}
+{{#include ../../../examples/rsx_overview.rs:children}}
 ```
 ```html
 <ol>
@@ -43,7 +43,7 @@ You can also "group" elements by wrapping them in `Fragment {}`. This will not c
 > Note: you can also render multiple elements at the top level of `rsx!` and they will be automatically grouped – no need for an explicit `Fragment {}` there.
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:fragments}}
+{{#include ../../../examples/rsx_overview.rs:fragments}}
 ```
 
 ```html
@@ -58,7 +58,7 @@ You can also "group" elements by wrapping them in `Fragment {}`. This will not c
 
 Attributes are also specified inside the `{}` brackets, using the `name: value` syntax. You can provide the value as a literal in the RSX:
 ```rust
-{{#include ../../examples/rsx_overview.rs:attributes}}
+{{#include ../../../examples/rsx_overview.rs:attributes}}
 ```
 ```html
 <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ" class="primary_button" autofocus="true">Log In</a>
@@ -71,7 +71,7 @@ Attributes are also specified inside the `{}` brackets, using the `name: value`
 Dioxus has a pre-configured set of attributes that you can use. RSX is validated at compile time to make sure you didn't specify an invalid attribute. If you want to override this behavior with a custom attribute name, specify the attribute in quotes:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:custom_attributes}}
+{{#include ../../../examples/rsx_overview.rs:custom_attributes}}
 ```
 ```html
 <b customAttribute="value">
@@ -84,7 +84,7 @@ Dioxus has a pre-configured set of attributes that you can use. RSX is validated
 Similarly to how you can [format](https://doc.rust-lang.org/rust-by-example/hello/print/fmt.html) Rust strings, you can also interpolate in RSX text. Use `{variable}` to Display the value of a variable in a string, or `{variable:?}` to use the Debug representation:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:formatting}}
+{{#include ../../../examples/rsx_overview.rs:formatting}}
 ```
 ```html
 
@@ -99,7 +99,7 @@ Similarly to how you can [format](https://doc.rust-lang.org/rust-by-example/hell
 You can include arbitrary Rust expressions within RSX, but you must escape them in `[]` brackets:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:expression}}
+{{#include ../../../examples/rsx_overview.rs:expression}}
 ```
 ```html
 <span>DIOXUS</span>

docs/guide/src/en/describing_ui/special_attributes.md

@@ -10,7 +10,7 @@ For example, shipping a markdown-to-Dioxus converter might significantly bloat y
 
 
 ```rust
-{{#include ../../examples/dangerous_inner_html.rs:dangerous_inner_html}}
+{{#include ../../../examples/dangerous_inner_html.rs:dangerous_inner_html}}
 ```
 
 > Note! This attribute is called "dangerous_inner_html" because it is **dangerous** to pass it data you don't trust. If you're not careful, you can easily expose [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) attacks to your users.
@@ -25,7 +25,7 @@ Most attributes, when rendered, will be rendered exactly as the input you provid
 So this RSX wouldn't actually render the `hidden` attribute:
 
 ```rust
-{{#include ../../examples/boolean_attribute.rs:boolean_attribute}}
+{{#include ../../../examples/boolean_attribute.rs:boolean_attribute}}
 ```
 ```html
 <div>hello</div>

docs/guide/src/en/getting_started/desktop.md

@@ -41,5 +41,5 @@ cargo add dioxus --features desktop
 Edit your `main.rs`:
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:all}}
+{{#include ../../../examples/hello_world_desktop.rs:all}}
 ```

docs/guide/src/en/getting_started/tui.md

@@ -21,10 +21,10 @@ cd demo
 cargo add dioxus --features tui
 ```
 
-Then, edit your `main.rs` with the basic template. 
+Then, edit your `main.rs` with the basic template.
 
 ```rust
-{{#include ../../examples/hello_world_tui.rs}}
+{{#include ../../../examples/hello_world_tui.rs}}
 ```
 
 To run our app:
@@ -36,7 +36,7 @@ cargo run
 Press "ctrl-c" to close the app. To switch from "ctrl-c" to  just "q" to quit you can launch the app with a configuration to disable the default quit and use the root TuiContext to quit on your own.
 
 ```rust
-{{#include ../../examples/hello_world_tui_no_ctrl_c.rs}}
+{{#include ../../../examples/hello_world_tui_no_ctrl_c.rs}}
 ```
 
 ## Notes

docs/guide/src/en/getting_started/web.md

@@ -61,7 +61,7 @@ Add an `index.html` for Trunk to use. Make sure your "mount point" element has a
 
 Edit your `main.rs`:
 ```rust
-{{#include ../../examples/hello_world_web.rs}}
+{{#include ../../../examples/hello_world_web.rs}}
 ```
 
 

docs/guide/src/en/interactivity/custom_hooks.md

@@ -9,7 +9,7 @@ To avoid repetition, you can encapsulate business logic based on existing hooks
 For example, if many components need to access an `AppSettings` struct, you can create a "shortcut" hook:
 
 ```rust
-{{#include ../../examples/hooks_composed.rs:wrap_context}}
+{{#include ../../../examples/hooks_composed.rs:wrap_context}}
 ```
 
 ## Custom Hook Logic

docs/guide/src/en/interactivity/dynamic_rendering.md

@@ -7,7 +7,7 @@ Sometimes you want to render different things depending on the state/props. With
 To render different elements based on a condition, you could use an `if-else` statement:
 
 ```rust
-{{#include ../../examples/conditional_rendering.rs:if_else}}
+{{#include ../../../examples/conditional_rendering.rs:if_else}}
 ```
 
 > You could also use `match` statements, or any Rust function to conditionally render different things.
@@ -18,7 +18,7 @@ To render different elements based on a condition, you could use an `if-else` st
 Since `Element` is a `Option<VNode>`, components accepting `Element` as a prop can actually inspect its contents, and render different things based on that. Example:
 
 ```rust
-{{#include ../../examples/component_children_inspect.rs:Clickable}}
+{{#include ../../../examples/component_children_inspect.rs:Clickable}}
 ```
 
 You can't mutate the `Element`, but if you need a modified version of it, you can construct a new one based on its attributes/children/etc.
@@ -29,7 +29,7 @@ You can't mutate the `Element`, but if you need a modified version of it, you ca
 To render nothing, you can return `None` from a component. This is useful if you want to conditionally hide something:
 
 ```rust
-{{#include ../../examples/conditional_rendering.rs:conditional_none}}
+{{#include ../../../examples/conditional_rendering.rs:conditional_none}}
 ```
 
 This works because the `Element` type is just an alias for `Option<VNode>`
@@ -50,7 +50,7 @@ For this, Dioxus accepts iterators that produce `Element`s. So we need to:
 Example: suppose you have a list of comments you want to render. Then, you can render them like this:
 
 ```rust
-{{#include ../../examples/rendering_lists.rs:render_list}}
+{{#include ../../../examples/rendering_lists.rs:render_list}}
 ```
 
 ### The `key` Attribute

docs/guide/src/en/interactivity/event_handlers.md

@@ -9,7 +9,7 @@ Event handlers are similar to regular attributes, but their name usually starts
 For example, to handle clicks on an element, we can specify an `onclick` handler:
 
 ```rust
-{{#include ../../examples/event_click.rs:rsx}}
+{{#include ../../../examples/event_click.rs:rsx}}
 ```
 
 ## The `Event` object
@@ -30,7 +30,7 @@ To learn what the different event types provide, read the [events module docs](h
 When you have e.g. a `button` inside a `div`, any click on the `button` is also a click on the `div`. For this reason, Dioxus propagates the click event: first, it is triggered on the target element, then on parent elements. If you want to prevent this behavior, you can call `cancel_bubble()` on the event:
 
 ```rust
-{{#include ../../examples/event_click.rs:rsx}}
+{{#include ../../../examples/event_click.rs:rsx}}
 ```
 
 ## Prevent Default
@@ -40,7 +40,7 @@ Some events have a default behavior. For keyboard events, this might be entering
 In some instances, might want to avoid this default behavior. For this, you can add the `prevent_default` attribute with the name of the handler whose default behavior you want to stop. This attribute is special: you can attach it multiple times for multiple attributes:
 
 ```rust
-{{#include ../../examples/event_prevent_default.rs:prevent_default}}
+{{#include ../../../examples/event_prevent_default.rs:prevent_default}}
 ```
 
 Any event handlers will still be called.
@@ -52,15 +52,15 @@ Any event handlers will still be called.
 Sometimes, you might want to make a component that accepts an event handler. A simple example would be a `FancyButton` component, which accepts an `on_click` handler:
 
 ```rust
-{{#include ../../examples/event_handler_prop.rs:component_with_handler}}
+{{#include ../../../examples/event_handler_prop.rs:component_with_handler}}
 ```
 
 Then, you can use it like any other handler:
 
 ```rust
-{{#include ../../examples/event_handler_prop.rs:usage}}
+{{#include ../../../examples/event_handler_prop.rs:usage}}
 ```
 
 > Note: just like any other attribute, you can name the handlers anything you want! Though they must start with `on`, for the prop to be automatically turned into an `EventHandler` at the call site.
-> 
+>
 > You can also put custom data in the event, rather than e.g. `MouseData`

docs/guide/src/en/interactivity/hooks.md

@@ -2,7 +2,7 @@
 
 So far our components, being Rust functions, had no state – they were always rendering the same thing. However, in a UI component, it is often useful to have stateful functionality to build user interactions. For example, you might want to track whether the user has openend a drop-down, and render different things accordingly.
 
-For stateful logic, you can use hooks. Hooks are Rust functions that take a reference to `ScopeState` (in a component, you can pass `&cx`), and provide you with functionality and state. 
+For stateful logic, you can use hooks. Hooks are Rust functions that take a reference to `ScopeState` (in a component, you can pass `&cx`), and provide you with functionality and state.
 
 ## `use_state` Hook
 
@@ -15,7 +15,7 @@ For stateful logic, you can use hooks. Hooks are Rust functions that take a refe
 For example, you might have seen the counter example, in which state (a number) is tracked using the `use_state` hook:
 
 ```rust
-{{#include ../../examples/hooks_counter.rs:component}}
+{{#include ../../../examples/hooks_counter.rs:component}}
 ```
 ![Screenshot: counter app](./images/counter.png)
 
@@ -26,7 +26,7 @@ Every time the component's state changes, it re-renders, and the component funct
 You can use multiple hooks in the same component if you want:
 
 ```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)
 
@@ -37,7 +37,7 @@ The above example might seem a bit magic, since Rust functions are typically not
 But how can Dioxus differentiate between multiple hooks in the same component? As you saw in the second example, both `use_state` functions were called with the same parameters, so how come they can return different things when the counters are different?
 
 ```rust
-{{#include ../../examples/hooks_counter_two_state.rs:use_state_calls}}
+{{#include ../../../examples/hooks_counter_two_state.rs:use_state_calls}}
 ```
 
 This is only possible because the two hooks are always called in the same order, so Dioxus knows which is which. So the order you call hooks matters, which is why you must follow certain rules when using hooks:
@@ -52,17 +52,17 @@ These rules mean that there are certain things you can't do with hooks:
 
 ### No Hooks in Conditionals
 ```rust
-{{#include ../../examples/hooks_bad.rs:conditional}}
+{{#include ../../../examples/hooks_bad.rs:conditional}}
 ```
 
 ### No Hooks in Closures
 ```rust
-{{#include ../../examples/hooks_bad.rs:closure}}
+{{#include ../../../examples/hooks_bad.rs:closure}}
 ```
 
 ### No Hooks in Loops
 ```rust
-{{#include ../../examples/hooks_bad.rs:loop}}
+{{#include ../../../examples/hooks_bad.rs:loop}}
 ```
 
 ## `use_ref` Hook
@@ -76,7 +76,7 @@ Thankfully, there is another hook for that, `use_ref`! It is similar to `use_sta
 Here's a simple example that keeps a list of events in a `use_ref`. We can acquire write access to the state with `.write()`, and then just `.push` a new value to the state:
 
 ```rust
-{{#include ../../examples/hooks_use_ref.rs:component}}
+{{#include ../../../examples/hooks_use_ref.rs:component}}
 ```
 
 > The return values of `use_state` and `use_ref`, (`UseState` and `UseRef`, respectively) are in some ways similar to [`Cell`](https://doc.rust-lang.org/std/cell/) and [`RefCell`](https://doc.rust-lang.org/std/cell/struct.RefCell.html) – they provide interior mutability. However, these Dioxus wrappers also ensure that the component gets re-rendered whenever you change the state.

docs/guide/src/en/interactivity/sharing_state.md

@@ -12,7 +12,7 @@ For example, suppose we want to build a meme editor. We want to have an input to
 
 We start with a `Meme` component, responsible for rendering a meme with a given caption:
 ```rust
-{{#include ../../examples/meme_editor.rs:meme_component}}
+{{#include ../../../examples/meme_editor.rs:meme_component}}
 ```
 
 > Note that the `Meme` component is unaware where the caption is coming from – it could be stored in `use_state`, `use_ref`, or a constant. This ensures that it is very reusable – the same component can be used for a meme gallery without any changes!
@@ -20,12 +20,12 @@ We start with a `Meme` component, responsible for rendering a meme with a given
 We also create a caption editor, completely decoupled from the meme. The caption editor must not store the caption itself – otherwise, how will we provide it to the `Meme` component? Instead, it should accept the current caption as a prop, as well as an event handler to delegate input events to:
 
 ```rust
-{{#include ../../examples/meme_editor.rs:caption_editor}}
+{{#include ../../../examples/meme_editor.rs:caption_editor}}
 ```
 
 Finally, a third component will render the other two as children. It will be responsible for keeping the state and passing down the relevant props.
 ```rust
-{{#include ../../examples/meme_editor.rs:meme_editor}}
+{{#include ../../../examples/meme_editor.rs:meme_editor}}
 ```
 ![Meme Editor Screenshot: An old plastic skeleton sitting on a park bench. Caption: "me waiting for a language feature"](./images/meme_editor_screenshot.png)
 
@@ -44,23 +44,23 @@ Dioxus offers a better solution than this "prop drilling" – providing context.
 First, we have to create a struct for our dark mode configuration:
 
 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:DarkMode_struct}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:DarkMode_struct}}
 ```
 
-Now, in a top-level component (like `App`), we can provide the `DarkMode` context to all children components: 
+Now, in a top-level component (like `App`), we can provide the `DarkMode` context to all children components:
 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:context_provider}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:context_provider}}
 ```
 
 As a result, any child component of `App` (direct or not), can access the `DarkMode` context.
 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:use_context}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:use_context}}
 ```
 
 > `use_context` returns `Option<UseSharedState<DarkMode>>` here. If the context has been provided, the value is `Some(UseSharedState)`, which you can call `.read` or `.write` on, similarly to `UseRef`. Otherwise, the value is `None`.
 
 For example, here's how we would implement the dark mode toggle, which both reads the context (to determine what color it should render) and writes to it (to toggle dark mode):
 ```rust
-{{#include ../../examples/meme_editor_dark_mode.rs:toggle}}
+{{#include ../../../examples/meme_editor_dark_mode.rs:toggle}}
 ```
 

docs/guide/src/en/interactivity/user_input.md

@@ -7,7 +7,7 @@ Interfaces often need to provide a way to input data: e.g. text, numbers, checkb
 With controlled inputs, you are directly in charge of the state of the input. This gives you a lot of flexibility, and makes it easy to keep things in sync. For example, this is how you would create a controlled text input:
 
 ```rust
-{{#include ../../examples/input_controlled.rs:component}}
+{{#include ../../../examples/input_controlled.rs:component}}
 ```
 
 Notice the flexibility – you can:
@@ -24,7 +24,7 @@ As an alternative to controlled inputs, you can simply let the platform keep tra
 Since you don't necessarily have the current value of the uncontrolled input in state, you can access it either by listening to `oninput` events (similarly to controlled components), or, if the input is part of a form, you can access the form data in the form events (e.g. `oninput` or `onsubmit`):
 
 ```rust
-{{#include ../../examples/input_uncontrolled.rs:component}}
+{{#include ../../../examples/input_uncontrolled.rs:component}}
 ```
 ```
 Submitted! UiEvent { data: FormData { value: "", values: {"age": "very old", "date": "1966", "name": "Fred"} } }

docs/guide/src/pt-br/async/spawn.md

@@ -3,7 +3,7 @@
 Os **"hooks"** `use_future` e `use_coroutine` são úteis se você quiser gerar incondicionalmente o `Future`. Às vezes, porém, você desejará apenas gerar um `Future` em resposta a um evento, como um clique do mouse. Por exemplo, suponha que você precise enviar uma solicitação quando o usuário clicar em um botão "log in". Para isso, você pode usar `cx.spawn`:
 
 ```rust
-{{#include ../../examples/spawn.rs:spawn}}
+{{#include ../../../examples/spawn.rs:spawn}}
 ```
 
 > Nota: `spawn` sempre gerará um _novo_ `Future`. Você provavelmente não quer chamá-lo em cada renderização.
@@ -15,7 +15,7 @@ No entanto, como você normalmente precisa de uma maneira de atualizar o valor d
 Para tornar isso um pouco menos detalhado, o Dioxus exporta a macro `to_owned!` que criará uma ligação como mostrado acima, o que pode ser bastante útil ao lidar com muitos valores.
 
 ```rust
-{{#include ../../examples/spawn.rs:to_owned_macro}}
+{{#include ../../../examples/spawn.rs:to_owned_macro}}
 ```
 
 Calling `spawn` will give you a `JoinHandle` which lets you cancel or pause the future.
@@ -25,5 +25,5 @@ Calling `spawn` will give you a `JoinHandle` which lets you cancel or pause the
 Às vezes, você pode querer gerar uma tarefa em segundo plano que precise de vários _threads_ ou conversar com o hardware que pode bloquear o código do seu aplicativo. Nesses casos, podemos gerar diretamente uma tarefa Tokio do nosso `Future`. Para Dioxus-Desktop, sua tarefa será gerada no tempo de execução Multi-Tarefado do Tokio:
 
 ```rust
-{{#include ../../examples/spawn.rs:tokio}}
+{{#include ../../../examples/spawn.rs:tokio}}
 ```

docs/guide/src/pt-br/async/use_future.md

@@ -5,7 +5,7 @@
 Por exemplo, podemos fazer uma solicitação de API dentro de `use_future`:
 
 ```rust
-{{#include ../../examples/use_future.rs:use_future}}
+{{#include ../../../examples/use_future.rs:use_future}}
 ```
 
 O código dentro de `use_future` será enviado ao agendador do Dioxus assim que o componente for renderizado.
@@ -15,7 +15,7 @@ Podemos usar `.value()` para obter o resultado do `Future`. Na primeira execuç
 Podemos então renderizar esse resultado:
 
 ```rust
-{{#include ../../examples/use_future.rs:render}}
+{{#include ../../../examples/use_future.rs:render}}
 ```
 
 ## Reiniciando o `Future`
@@ -27,5 +27,5 @@ O identificador `UseFuture` fornece um método `restart`. Ele pode ser usado par
 Muitas vezes, você precisará executar o `Future` novamente toda vez que algum valor (por exemplo, uma prop) mudar. Ao invés de `.restart` manualmente, você pode fornecer uma tupla de "dependências" para o gancho. Ele executará automaticamente o `Future` quando qualquer uma dessas dependências for alterada. Exemplo:
 
 ```rust
-{{#include ../../examples/use_future.rs:dependency}}
+{{#include ../../../examples/use_future.rs:dependency}}
 ```

docs/guide/src/pt-br/best_practices/antipatterns.md

@@ -9,7 +9,7 @@ Os fragmentos não montam um elemento físico no DOM imediatamente, então o Dio
 Apenas os nós Componente e Fragmento são suscetíveis a esse problema. O Dioxus atenua isso com componentes fornecendo uma API para registrar o estado compartilhado sem o padrão _Context Provider_.
 
 ```rust
-{{#include ../../examples/anti_patterns.rs:nested_fragments}}
+{{#include ../../../examples/anti_patterns.rs:nested_fragments}}
 ```
 
 ## Chaves do Iterador Incorretas
@@ -17,7 +17,7 @@ Apenas os nós Componente e Fragmento são suscetíveis a esse problema. O Dioxu
 Conforme descrito no capítulo de renderização condicional, os itens da lista devem ter _keys_ exclusivas associadas aos mesmos itens nas renderizações. Isso ajuda o Dioxus a associar o estado aos componentes contidos e garante um bom desempenho de diferenciação. Não omita as _keys_, a menos que você saiba que a lista é estática e nunca será alterada.
 
 ```rust
-{{#include ../../examples/anti_patterns.rs:iter_keys}}
+{{#include ../../../examples/anti_patterns.rs:iter_keys}}
 ```
 
 ## Evite Mutabilidade Interior em `Props`

docs/guide/src/pt-br/describing_ui/component_children.md

@@ -3,13 +3,13 @@
 Em alguns casos, você pode desejar criar um componente que atue como um contêiner para algum outro conteúdo, sem que o componente precise saber qual é esse conteúdo. Para conseguir isso, crie uma _prop_ do tipo `Element`:
 
 ```rust
-{{#include ../../examples/component_element_props.rs:Clickable}}
+{{#include ../../../examples/component_element_props.rs:Clickable}}
 ```
 
 Então, ao renderizar o componente, você pode passar a saída de `cx.render(rsx!(...))`:
 
 ```rust
-{{#include ../../examples/component_element_props.rs:Clickable_usage}}
+{{#include ../../../examples/component_element_props.rs:Clickable_usage}}
 ```
 
 > Nota: Como `Element<'a>` é uma _prop_ emprestado, não haverá memoização.
@@ -21,11 +21,11 @@ Então, ao renderizar o componente, você pode passar a saída de `cx.render(rsx
 Em vez de passar o `RSX` através de uma _prop_ regular, você pode querer aceitar filhos da mesma forma que os elementos podem ter filhos. O prop "mágico" `children` permite que você consiga isso:
 
 ```rust
-{{#include ../../examples/component_children.rs:Clickable}}
+{{#include ../../../examples/component_children.rs:Clickable}}
 ```
 
 Isso torna o uso do componente muito mais simples: basta colocar o `RSX` dentro dos colchetes `{}` – e não há necessidade de uma chamada `render` ou outra macro!
 
 ```rust
-{{#include ../../examples/component_children.rs:Clickable_usage}}
+{{#include ../../../examples/component_children.rs:Clickable_usage}}
 ```

docs/guide/src/pt-br/describing_ui/component_props.md

@@ -20,13 +20,13 @@ Existem 2 tipos de estruturas Props:
 _Props_ próprios são muito simples – eles não emprestam nada. Exemplo:
 
 ```rust
-{{#include ../../examples/component_owned_props.rs:Likes}}
+{{#include ../../../examples/component_owned_props.rs:Likes}}
 ```
 
 Você pode então passar valores de _prop_ para o componente da mesma forma que você passaria atributos para um elemento:
 
 ```rust
-{{#include ../../examples/component_owned_props.rs:App}}
+{{#include ../../../examples/component_owned_props.rs:App}}
 ```
 
 ![Screenshot: Likes component](./images/component_owned_props_screenshot.png)
@@ -38,13 +38,13 @@ Possuir _props_ funciona bem se seus _props_ forem fáceis de copiar – como um
 Rust permite algo mais eficiente – emprestar a `String` como um `&str` – é para isso que servem as _props emprestadas_!
 
 ```rust
-{{#include ../../examples/component_borrowed_props.rs:TitleCard}}
+{{#include ../../../examples/component_borrowed_props.rs:TitleCard}}
 ```
 
 Podemos então usar o componente assim:
 
 ```rust
-{{#include ../../examples/component_borrowed_props.rs:App}}
+{{#include ../../../examples/component_borrowed_props.rs:App}}
 ```
 
 ![Screenshot: TitleCard component](./images/component_borrowed_props_screenshot.png)
@@ -58,13 +58,13 @@ A macro `#[derive(Props)]` tem alguns recursos que permitem personalizar o compo
 Você pode criar campos opcionais usando o tipo `Option<…>` para um campo:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:OptionalProps}}
+{{#include ../../../examples/component_props_options.rs:OptionalProps}}
 ```
 
 Em seguida, você pode optar por fornecê-los ou não:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:OptionalProps_usage}}
+{{#include ../../../examples/component_props_options.rs:OptionalProps_usage}}
 ```
 
 ### `Option` Explicitamente Obrigatórias
@@ -72,13 +72,13 @@ Em seguida, você pode optar por fornecê-los ou não:
 Se você quiser exigir explicitamente uma `Option`, e não uma _prop_ opcional, você pode anotá-la com `#[props(!optional)]`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:ExplicitOption}}
+{{#include ../../../examples/component_props_options.rs:ExplicitOption}}
 ```
 
 Então, você tem que passar explicitamente `Some("str")` ou `None`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:ExplicitOption_usage}}
+{{#include ../../../examples/component_props_options.rs:ExplicitOption_usage}}
 ```
 
 ### Props Padrão
@@ -86,13 +86,13 @@ Então, você tem que passar explicitamente `Some("str")` ou `None`:
 Você pode usar `#[props(default = 42)]` para tornar um campo opcional e especificar seu valor padrão:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:DefaultComponent}}
+{{#include ../../../examples/component_props_options.rs:DefaultComponent}}
 ```
 
 Então, da mesma forma que _props_ opcionais, você não precisa fornecê-lo:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:DefaultComponent_usage}}
+{{#include ../../../examples/component_props_options.rs:DefaultComponent_usage}}
 ```
 
 ### Conversão Automática com `.into`
@@ -100,13 +100,13 @@ Então, da mesma forma que _props_ opcionais, você não precisa fornecê-lo:
 É comum que as funções Rust aceitem `impl Into<SomeType>` em vez de apenas `SomeType` para suportar uma ampla gama de parâmetros. Se você quiser uma funcionalidade semelhante com _props_, você pode usar `#[props(into)]`. Por exemplo, você pode adicioná-lo em uma prop `String` – e `&str` também será aceito automaticamente, pois pode ser convertido em `String`:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:IntoComponent}}
+{{#include ../../../examples/component_props_options.rs:IntoComponent}}
 ```
 
 Então, você pode usá-lo assim:
 
 ```rust
-{{#include ../../examples/component_props_options.rs:IntoComponent_usage}}
+{{#include ../../../examples/component_props_options.rs:IntoComponent_usage}}
 ```
 
 ## A macro `inline_props`

docs/guide/src/pt-br/describing_ui/components.md

@@ -5,7 +5,7 @@ Assim como você não gostaria de escrever um programa complexo em uma única e
 Um componente é uma função Rust, nomeada em _UpperCammelCase_, que recebe um parâmetro `Scope` e retorna um `Element` descrevendo a interface do usuário que deseja renderizar. Na verdade, nossa função `App` é um componente!
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:component}}
+{{#include ../../../examples/hello_world_desktop.rs:component}}
 ```
 
 > Você provavelmente desejará adicionar `#![allow(non_snake_case)]` no topo de sua caixa para evitar avisos sobre o nome da função
@@ -13,13 +13,13 @@ Um componente é uma função Rust, nomeada em _UpperCammelCase_, que recebe um
 Um Componente é responsável por alguma tarefa de renderização – normalmente, renderizando uma parte isolada da interface do usuário. Por exemplo, você pode ter um componente `About` que renderiza uma breve descrição do Dioxus Labs:
 
 ```rust
-{{#include ../../examples/components.rs:About}}
+{{#include ../../../examples/components.rs:About}}
 ```
 
 Em seguida, você pode renderizar seu componente em outro componente, da mesma forma que os elementos são renderizados:
 
 ```rust
-{{#include ../../examples/components.rs:App}}
+{{#include ../../../examples/components.rs:App}}
 ```
 
 ![Captura de tela contendo o componente Sobre duas vezes](./images/screenshot_about_component.png)

docs/guide/src/pt-br/describing_ui/index.md

@@ -5,7 +5,7 @@ Dioxus é uma estrutura _declarativa_. Isso significa que, em vez de dizer ao Di
 Você já viu um exemplo simples ou sintaxe `RSX` no aplicativo "hello world":
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:component}}
+{{#include ../../../examples/hello_world_desktop.rs:component}}
 ```
 
 Aqui, usamos a macro `rsx!` para _declarar_ que queremos um elemento `div`, contendo o texto `"Hello, world!"`. Dioxus pega o RSX e constrói uma interface do usuário a partir dele.
@@ -15,7 +15,7 @@ Aqui, usamos a macro `rsx!` para _declarar_ que queremos um elemento `div`, cont
 O RSX é muito semelhante ao HTML, pois descreve elementos com atributos e filhos. Aqui está um elemento `div` vazio no RSX, bem como o HTML resultante:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:empty}}
+{{#include ../../../examples/rsx_overview.rs:empty}}
 ```
 
 ```html
@@ -27,7 +27,7 @@ O RSX é muito semelhante ao HTML, pois descreve elementos com atributos e filho
 Para adicionar filhos a um elemento, coloque-os dentro dos colchetes `{}`. Eles podem ser outros elementos ou texto. Por exemplo, você pode ter um elemento `ol` (lista ordenada), contendo 3 elementos `li` (item da lista), cada um dos quais contém algum texto:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:children}}
+{{#include ../../../examples/rsx_overview.rs:children}}
 ```
 
 ```html
@@ -45,7 +45,7 @@ Você também pode "agrupar" elementos envolvendo-os em `Fragment {}`. Isso não
 > Nota: você também pode renderizar vários elementos no nível superior de `rsx!` e eles serão agrupados automaticamente – não há necessidade de um `Fragment {}` explícito lá.
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:fragments}}
+{{#include ../../../examples/rsx_overview.rs:fragments}}
 ```
 
 ```html
@@ -61,7 +61,7 @@ Você também pode "agrupar" elementos envolvendo-os em `Fragment {}`. Isso não
 Os atributos também são especificados dentro dos colchetes `{}`, usando a sintaxe `name: value`. Você pode fornecer o valor como um literal no RSX:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:attributes}}
+{{#include ../../../examples/rsx_overview.rs:attributes}}
 ```
 
 ```html
@@ -80,7 +80,7 @@ Os atributos também são especificados dentro dos colchetes `{}`, usando a sint
 Dioxus tem um conjunto pré-configurado de atributos que você pode usar. O RSX é validado em tempo de compilação para garantir que você não especificou um atributo inválido. Se você quiser substituir esse comportamento por um nome de atributo personalizado, especifique o atributo entre aspas:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:custom_attributes}}
+{{#include ../../../examples/rsx_overview.rs:custom_attributes}}
 ```
 
 ```html
@@ -92,7 +92,7 @@ Dioxus tem um conjunto pré-configurado de atributos que você pode usar. O RSX
 Da mesma forma que você pode [formatar](https://doc.rust-lang.org/rust-by-example/hello/print/fmt.html) Rust _strings_, você também pode interpolar no texto RSX. Use `{variable}` para exibir o valor de uma variável em uma _string_, ou `{variable:?}` para usar a representação `Debug`:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:formatting}}
+{{#include ../../../examples/rsx_overview.rs:formatting}}
 ```
 
 ```html
@@ -108,7 +108,7 @@ Da mesma forma que você pode [formatar](https://doc.rust-lang.org/rust-by-examp
 Você pode incluir expressões Rust arbitrárias dentro do RSX, mas deve escapá-las entre colchetes `[]`:
 
 ```rust
-{{#include ../../examples/rsx_overview.rs:expression}}
+{{#include ../../../examples/rsx_overview.rs:expression}}
 ```
 
 ```html

docs/guide/src/pt-br/describing_ui/special_attributes.md

@@ -9,7 +9,7 @@ Se você estiver trabalhando com itens pré-renderizados, modelos ou uma bibliot
 Por exemplo, enviar um conversor de markdown para Dioxus pode aumentar significativamente o tamanho final do aplicativo. Em vez disso, você desejará pré-renderizar sua remarcação para HTML e, em seguida, incluir o HTML diretamente em sua saída. Usamos essa abordagem para a [página inicial do Dioxus](https://dioxuslabs.com):
 
 ```rust
-{{#include ../../examples/dangerous_inner_html.rs:dangerous_inner_html}}
+{{#include ../../../examples/dangerous_inner_html.rs:dangerous_inner_html}}
 ```
 
 > Nota! Esse atributo é chamado de "dangerous_inner_html" porque é **perigoso** passar dados que você não confia. Se você não for cuidadoso, poderá facilmente expor ataques de [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) aos seus usuários.
@@ -23,7 +23,7 @@ A maioria dos atributos, quando renderizados, serão renderizados exatamente com
 Portanto, este RSX não renderizaria o atributo `hidden`:
 
 ```rust
-{{#include ../../examples/boolean_attribute.rs:boolean_attribute}}
+{{#include ../../../examples/boolean_attribute.rs:boolean_attribute}}
 ```
 
 ```html

docs/guide/src/pt-br/getting_started/desktop.md

@@ -42,5 +42,5 @@ cargo add dioxus --features desktop
 Edite seu `main.rs`:
 
 ```rust
-{{#include ../../examples/hello_world_desktop.rs:all}}
+{{#include ../../../examples/hello_world_desktop.rs:all}}
 ```

docs/guide/src/pt-br/getting_started/tui.md

@@ -23,7 +23,7 @@ cargo add dioxus --features tui
 Em seguida, edite seu `main.rs` com o modelo básico.
 
 ```rust
-{{#include ../../examples/hello_world_tui.rs}}
+{{#include ../../../examples/hello_world_tui.rs}}
 ```
 
 Para executar nosso aplicativo:
@@ -35,7 +35,7 @@ cargo run
 Pressione "ctrl-c" para fechar o aplicativo. Para mudar de "ctrl-c" para apenas "q" para sair, você pode iniciar o aplicativo com uma configuração para desativar o sair padrão e usar a raiz TuiContext para sair por conta própria.
 
 ```rust
-{{#include ../../examples/hello_world_tui_no_ctrl_c.rs}}
+{{#include ../../../examples/hello_world_tui_no_ctrl_c.rs}}
 ```
 
 ## Notas

docs/guide/src/pt-br/getting_started/web.md

@@ -64,7 +64,7 @@ Adicione um `index.html` para o `Trunk` usar. Certifique-se de que seu elemento
 Edite seu `main.rs`:
 
 ```rust
-{{#include ../../examples/hello_world_web.rs}}
+{{#include ../../../examples/hello_world_web.rs}}
 ```
 
 E para servir nosso aplicativo:

docs/guide/src/pt-br/interactivity/custom_hooks.md

@@ -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

docs/guide/src/pt-br/interactivity/dynamic_rendering.md

@@ -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`

docs/guide/src/pt-br/interactivity/event_handlers.md

@@ -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.

docs/guide/src/pt-br/interactivity/hooks.md

@@ -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.

docs/guide/src/pt-br/interactivity/sharing_state.md

@@ -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}}
 ```

docs/guide/src/pt-br/interactivity/user_input.md

@@ -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}}
 ```
 
 ```