""
, -] -nodes: [ - RootNode, -""
, -] -``` - -Next, Dioxus will create the dynamic text node. The diff algorithm decides that this node needs to be created, so Dioxus will generate the Mutation `HydrateText`. When the renderer receives this instruction, it will navigate to the placeholder text node in the template and replace it with the new text. - -```rust, no_run -instructions: [ - LoadTemplate { - name: "main.rs:1:1:0", - index: 0, - id: ElementId(1), - }, - HydrateText { - // the id to store the text node - id: ElementId(2), - // the text to set - text: "count: 0", - } -] -stack: [ - RootNode, -"count: 0"
, -] -nodes: [ - RootNode, -"count: 0"
, - "count: 0", -] -``` - -Remember, the h1 node is not attached to anything (it is unmounted) so Dioxus needs to generate an Edit that connects the h1 node to the Root. It depends on the situation, but in this case, we use `AppendChildren`. This pops the text node off the stack, leaving the Root element as the next element on the stack. - -```rust, no_run -instructions: [ - LoadTemplate { - name: "main.rs:1:1:0", - index: 0, - id: ElementId(1), - }, - HydrateText { - id: ElementId(2), - text: "count: 0", - }, - AppendChildren { - // the id of the parent node - id: ElementId(0), - // the number of nodes to pop off the stack and append - m: 1 - } -] -stack: [ - RootNode, -] -nodes: [ - RootNode, -"count: 0"
, - "count: 0", -] -``` - -Over time, our stack looked like this: - -```rust, no_run -[Root] -[Root,""
] -[Root,"count: 0"
] -[Root] -``` - -Conveniently, this approach completely separates the Virtual DOM and the Real DOM. Additionally, these edits are serializable, meaning we can even manage UIs across a network connection. This little stack machine and serialized edits make Dioxus independent of platform specifics. - -Dioxus is also really fast. Because Dioxus splits the diff and patch phase, it's able to make all the edits to the RealDOM in a very short amount of time (less than a single frame) making rendering very snappy. It also allows Dioxus to cancel large diffing operations if higher priority work comes in while it's diffing. - -This little demo serves to show exactly how a Renderer would need to process a mutation stream to build UIs. - -## Event loop - -Like most GUIs, Dioxus relies on an event loop to progress the VirtualDOM. The VirtualDOM itself can produce events as well, so it's important for your custom renderer can handle those too. - -The code for the WebSys implementation is straightforward, so we'll add it here to demonstrate how simple an event loop is: - -```rust, no_run, ignore -pub async fn run(&mut self) -> dioxus_core::error::Result<()> { - // Push the body element onto the WebsysDom's stack machine - let mut websys_dom = crate::new::WebsysDom::new(prepare_websys_dom()); - websys_dom.stack.push(root_node); - - // Rebuild or hydrate the virtualdom - let mutations = self.internal_dom.rebuild(); - websys_dom.apply_mutations(mutations); - - // Wait for updates from the real dom and progress the virtual dom - loop { - let user_input_future = websys_dom.wait_for_event(); - let internal_event_future = self.internal_dom.wait_for_work(); - - match select(user_input_future, internal_event_future).await { - Either::Left((_, _)) => { - let mutations = self.internal_dom.work_with_deadline(|| false); - websys_dom.apply_mutations(mutations); - }, - Either::Right((event, _)) => websys_dom.handle_event(event), - } - - // render - } -} -``` - -It's important to decode what the real events are for your event system into Dioxus' synthetic event system (synthetic meaning abstracted). This simply means matching your event type and creating a Dioxus `UserEvent` type. Right now, the virtual event system is modeled almost entirely around the HTML spec, but we are interested in slimming it down. - -```rust, no_run, ignore -fn virtual_event_from_websys_event(event: &web_sys::Event) -> VirtualEvent { - match event.type_().as_str() { - "keydown" => { - let event: web_sys::KeyboardEvent = event.clone().dyn_into().unwrap(); - UserEvent::KeyboardEvent(UserEvent { - scope_id: None, - priority: EventPriority::Medium, - name: "keydown", - // This should be whatever element is focused - element: Some(ElementId(0)), - data: Arc::new(KeyboardData{ - char_code: event.char_code(), - key: event.key(), - key_code: event.key_code(), - alt_key: event.alt_key(), - ctrl_key: event.ctrl_key(), - meta_key: event.meta_key(), - shift_key: event.shift_key(), - location: event.location(), - repeat: event.repeat(), - which: event.which(), - }) - }) - } - _ => todo!() - } -} -``` - -## Custom raw elements - -If you need to go as far as relying on custom elements/attributes for your renderer – you totally can. This still enables you to use Dioxus' reactive nature, component system, shared state, and other features, but will ultimately generate different nodes. All attributes and listeners for the HTML and SVG namespace are shuttled through helper structs that essentially compile away. You can drop in your elements any time you want, with little hassle. However, you must be sure your renderer can handle the new namespace. - -For more examples and information on how to create custom namespaces, see the [`dioxus_html` crate](https://github.com/DioxusLabs/dioxus/blob/master/packages/html/README.md#how-to-extend-it). - -# Native Core - -If you are creating a renderer in rust, the [native-core](https://github.com/DioxusLabs/dioxus/tree/master/packages/native-core) crate provides some utilities to implement a renderer. It provides an abstraction over Mutations and Templates and contains helpers that can handle the layout and text editing for you. - -## The RealDom - -The `RealDom` is a higher-level abstraction over updating the Dom. It uses an entity component system to manage the state of nodes. This system allows you to modify insert and modify arbitrary components on nodes. On top of this, the RealDom provides a way to manage a tree of nodes, and the State trait provides a way to automatically add and update these components when the tree is modified. It also provides a way to apply `Mutations` to the RealDom. - -### Example - -Let's build a toy renderer with borders, size, and text color. -Before we start let's take a look at an example element we can render: - -```rust, no_run -cx.render(rsx!{ - div{ - color: "red", - p{ - border: "1px solid black", - "hello world" - } - } -}) -``` - -In this tree, the color depends on the parent's color. The layout depends on the children's layout, the current text, and the text size. The border depends on only the current node. - -In the following diagram arrows represent dataflow: - -[](https://mermaid.live/edit#pako:eNqllV1vgjAUhv8K6W4wkQVa2QdLdrHsdlfukmSptEhjoaSWqTH-9xVwONAKst70g5739JzzlO5BJAgFAYi52EQJlsr6fAszS7d1sVhKnCdWJDJFt6peLVs5-9owohK7HFrVcFJ_pxnpmK8VVvRkTJikkWIiaxy1dhP23bUwW1WW5WbPrrqJ4ziR4EJ6dtVN2ls5y1ZztePUcrWZFCvqVEcPPDffvlyS1XoLIQnVgnVvVPR6FU9Zc-6dV453ojjOPbuetRJ57gIeXQR3cez7rjtteZyZQ2j5MqmjqwE0ZW0VKx9RKtgpFewp1aw3sXXFy6TWgiYlv8mfq1scD8ofbBCAfQg8_AMBOAyBxzEIwA4CxgQ99QbQkjnD2KT7_CfxGF8_9WXQEsq5sDZCcjICOXRCri4h6r3NA38Q6Jdi1EOx5w3DGDYYI6MUvJFjM3VoGHUeGoMd6mBnDmh2E3fo7O4Yhf0x4OkBmIKUyhQzol_GfbkcApXQlIYg0EOC5SoEYXbQ-3ChxHyXRSBQsqBTUOREx_7OsAY3BUGM-VqvUsKUkB_1U6vf05gtweEHTk4_HQ) - -[//]: # "%% mermaid flow chart" -[//]: # "flowchart TB" -[//]: # " subgraph context" -[//]: # " text_width(text width)" -[//]: # " end" -[//]: # " subgraph state" -[//]: # " direction TB" -[//]: # " subgraph div state" -[//]: # " direction TB" -[//]: # " state1(state)---color1(color)" -[//]: # " linkStyle 0 stroke-width:10px;" -[//]: # " state1---border1(border)" -[//]: # " linkStyle 1 stroke-width:10px;" -[//]: # " text_width-.->layout_width1(layout width)" -[//]: # " linkStyle 2 stroke:#ff5500,stroke-width:4px;" -[//]: # " state1---layout_width1" -[//]: # " linkStyle 3 stroke-width:10px;" -[//]: # " end" -[//]: # " subgraph p state" -[//]: # " direction TB" -[//]: # " state2(state)---color2(color)" -[//]: # " linkStyle 4 stroke-width:10px;" -[//]: # " color1-.->color2" -[//]: # " linkStyle 5 stroke:#0000ff,stroke-width:4px;" -[//]: # " state2---border2(border)" -[//]: # " linkStyle 6 stroke-width:10px;" -[//]: # " text_width-.->layout_width2(layout width)" -[//]: # " linkStyle 7 stroke:#ff5500,stroke-width:4px;" -[//]: # " state2---layout_width2" -[//]: # " linkStyle 8 stroke-width:10px;" -[//]: # " layout_width2-.->layout_width1" -[//]: # " linkStyle 9 stroke:#00aa00,stroke-width:4px;" -[//]: # " end" -[//]: # " subgraph hello world state" -[//]: # " direction TB" -[//]: # " state3(state)---border3(border)" -[//]: # " linkStyle 10 stroke-width:10px;" -[//]: # " state3---color3(color)" -[//]: # " linkStyle 11 stroke-width:10px;" -[//]: # " color2-.->color3" -[//]: # " linkStyle 12 stroke:#0000ff,stroke-width:4px;" -[//]: # " text_width-.->layout_width3(layout width)" -[//]: # " linkStyle 13 stroke:#ff5500,stroke-width:4px;" -[//]: # " state3---layout_width3" -[//]: # " linkStyle 14 stroke-width:10px;" -[//]: # " layout_width3-.->layout_width2" -[//]: # " linkStyle 15 stroke:#00aa00,stroke-width:4px;" -[//]: # " end" -[//]: # " end" - -To help in building a Dom, native-core provides the State trait and a RealDom struct. The State trait provides a way to describe how states in a node depend on other states in its relatives. By describing how to update a single node from its relations, native-core will derive a way to update the states of all nodes for you. Once you have a state you can provide it as a generic to RealDom. RealDom provides all of the methods to interact and update your new dom. - -Native Core cannot create all of the required methods for the State trait, but it can derive some of them. To implement the State trait, you must implement the following methods and let the `#[partial_derive_state]` macro handle the rest: - -```rust, no_run, ignore -{{#include ../../../examples/custom_renderer.rs:derive_state}} -``` - -Lets take a look at how to implement the State trait for a simple renderer. - -```rust, no_run -{{#include ../../../examples/custom_renderer.rs:state_impl}} -``` - -Now that we have our state, we can put it to use in our RealDom. We can update the RealDom with apply_mutations to update the structure of the dom (adding, removing, and changing properties of nodes) and then update_state to update the States for each of the nodes that changed. - -```rust, no_run -{{#include ../../../examples/custom_renderer.rs:rendering}} -``` - -## Layout - -For most platforms, the layout of the Elements will stay the same. The [layout_attributes](https://docs.rs/dioxus-native-core/latest/dioxus_native_core/layout_attributes/index.html) module provides a way to apply HTML attributes a [Taffy](https://docs.rs/taffy/latest/taffy/index.html) layout style. - -## Text Editing - -To make it easier to implement text editing in rust renderers, `native-core` also contains a renderer-agnostic cursor system. The cursor can handle text editing, selection, and movement with common keyboard shortcuts integrated. - -```rust, no_run -{{#include ../../../examples/custom_renderer.rs:cursor}} -``` - -## Conclusion - -That should be it! You should have nearly all the knowledge required on how to implement your renderer. We're super interested in seeing Dioxus apps brought to custom desktop renderers, mobile renderers, video game UI, and even augmented reality! If you're interested in contributing to any of these projects, don't be afraid to reach out or join the [community](https://discord.gg/XgGxMSkvUM). diff --git a/docs/guide/src/en/describing_ui/component_children.md b/docs/guide/src/en/describing_ui/component_children.md deleted file mode 100644 index 7e329abbc..000000000 --- a/docs/guide/src/en/describing_ui/component_children.md +++ /dev/null @@ -1,31 +0,0 @@ -# Component Children - -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, no_run -{{#include ../../../examples/component_element_props.rs:Clickable}} -``` - -Then, when rendering the component, you can pass in the output of `cx.render(rsx!(...))`: - -```rust, no_run -{{#include ../../../examples/component_element_props.rs:Clickable_usage}} -``` - -> Note: Since `Element<'a>` is a borrowed prop, there will be no memoization. - -> Warning: While it may compile, do not include the same `Element` more than once in the RSX. The resulting behavior is unspecified. - -## The `children` field - -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, no_run -{{#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, no_run -{{#include ../../../examples/component_children.rs:Clickable_usage}} -``` diff --git a/docs/guide/src/en/describing_ui/component_props.md b/docs/guide/src/en/describing_ui/component_props.md deleted file mode 100644 index 947ec5f70..000000000 --- a/docs/guide/src/en/describing_ui/component_props.md +++ /dev/null @@ -1,144 +0,0 @@ -# Component Props - -Just like you can pass arguments to a function, you can pass props to a component that customize its behavior! The components we've seen so far didn't accept any props – so let's write some components that do. - -## `#[derive(Props)]` - -Component props are a single struct annotated with `#[derive(Props)]`. For a component to accept props, the type of its argument must be `Scope
-
-```
-
-### Children
-
-To add children to an element, put them inside the `{}` brackets after all attributes and listeners in the element. They can be other elements, text, or [components](components.md). For example, you could have an `ol` (ordered list) element, containing 3 `li` (list item) elements, each of which contains some text:
-
-```rust, no_run
-{{#include ../../../examples/rsx_overview.rs:children}}
-```
-
-```html
-ES
- 42
- {}
--
-
- First Item -
- Second Item -
- Third Item -
First Item
-Second Item
-``` - -### Expressions - -You can include arbitrary Rust expressions as children within RSX that implements [IntoDynNode](https://docs.rs/dioxus-core/0.3/dioxus_core/trait.IntoDynNode.html). This is useful for displaying data from an [iterator](https://doc.rust-lang.org/stable/book/ch13-02-iterators.html#processing-a-series-of-items-with-iterators): - -```rust, no_run -{{#include ../../../examples/rsx_overview.rs:expression}} -``` - -```html -DIOXUS0123456789 -``` - -### Loops - -In addition to iterators you can also use for loops directly within RSX: - -```rust, no_run -{{#include ../../../examples/rsx_overview.rs:loops}} -``` - -```html -0
-1
-2
-0
-1
-2
-```
-
-### If statements
-
-You can also use if statements without an else branch within RSX:
-
-```rust, no_run
-{{#include ../../../examples/rsx_overview.rs:ifstatements}}
-```
-
-```html
-true
-```
diff --git a/docs/guide/src/en/describing_ui/special_attributes.md b/docs/guide/src/en/describing_ui/special_attributes.md
deleted file mode 100644
index 4ba7a40f1..000000000
--- a/docs/guide/src/en/describing_ui/special_attributes.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Special Attributes
-
-While most attributes are simply passed on to the HTML, some have special behaviors.
-
-## The HTML Escape Hatch
-
-If you're working with pre-rendered assets, output from templates, or output from a JS library, then you might want to pass HTML directly instead of going through Dioxus. In these instances, reach for `dangerous_inner_html`.
-
-For example, shipping a markdown-to-Dioxus converter might significantly bloat your final application size. Instead, you'll want to pre-render your markdown to HTML and then include the HTML directly in your output. We use this approach for the [Dioxus homepage](https://dioxuslabs.com):
-
-```rust, no_run
-{{#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.
->
-> If you're handling untrusted input, make sure to sanitize your HTML before passing it into `dangerous_inner_html` – or just pass it to a Text Element to escape any HTML tags.
-
-## Boolean Attributes
-
-Most attributes, when rendered, will be rendered exactly as the input you provided. However, some attributes are considered "boolean" attributes and just their presence determines whether they affect the output. For these attributes, a provided value of `"false"` will cause them to be removed from the target element.
-
-So this RSX wouldn't actually render the `hidden` attribute:
-
-```rust, no_run
-{{#include ../../../examples/boolean_attribute.rs:boolean_attribute}}
-```
-
-```html
-hello
-```
-
-Not all attributes work like this however. _Only the following attributes_ have this behavior:
-
-- `allowfullscreen`
-- `allowpaymentrequest`
-- `async`
-- `autofocus`
-- `autoplay`
-- `checked`
-- `controls`
-- `default`
-- `defer`
-- `disabled`
-- `formnovalidate`
-- `hidden`
-- `ismap`
-- `itemscope`
-- `loop`
-- `multiple`
-- `muted`
-- `nomodule`
-- `novalidate`
-- `open`
-- `playsinline`
-- `readonly`
-- `required`
-- `reversed`
-- `selected`
-- `truespeed`
-
-For any other attributes, a value of `"false"` will be sent directly to the DOM.
diff --git a/docs/guide/src/en/fullstack/getting_started.md b/docs/guide/src/en/fullstack/getting_started.md
deleted file mode 100644
index 401af1d43..000000000
--- a/docs/guide/src/en/fullstack/getting_started.md
+++ /dev/null
@@ -1,102 +0,0 @@
-> This guide assumes you read the [Web](web.md) guide and installed the [Dioxus-cli](https://github.com/DioxusLabs/cli)
-
-# Getting Started
-
-## Setup
-
-For this guide, we're going to show how to use Dioxus with [Axum](https://docs.rs/axum/latest/axum/), but `dioxus-fullstack` also integrates with the [Warp](https://docs.rs/warp/latest/warp/) and [Salvo](https://docs.rs/salvo/latest/salvo/) web frameworks.
-
-Make sure you have Rust and Cargo installed, and then create a new project:
-
-```shell
-cargo new --bin demo
-cd demo
-```
-
-Add `dioxus` and `dioxus-fullstack` as dependencies:
-
-```shell
-cargo add dioxus
-cargo add dioxus-fullstack --features axum, ssr
-```
-
-Next, add all the Axum dependencies. This will be different if you're using a different Web Framework
-
-```shell
-cargo add tokio --features full
-cargo add axum
-```
-
-Your dependencies should look roughly like this:
-
-```toml
-[dependencies]
-axum = "*"
-dioxus = { version = "*" }
-dioxus-fullstack = { version = "*", features = ["axum", "ssr"] }
-tokio = { version = "*", features = ["full"] }
-```
-
-Now, set up your Axum app to serve the Dioxus app.
-
-```rust, no_run
-{{#include ../../../examples/server_basic.rs}}
-```
-
-Now, run your app with `cargo run` and open `http://localhost:8080` in your browser. You should see a server-side rendered page with a counter.
-
-## Hydration
-
-Right now, the page is static. We can't interact with the buttons. To fix this, we can hydrate the page with `dioxus-web`.
-
-First, modify your `Cargo.toml` to include two features, one for the server called `ssr`, and one for the client called `web`.
-
-```toml
-[dependencies]
-# Common dependancies
-dioxus = { version = "*" }
-dioxus-fullstack = { version = "*" }
-
-# Web dependancies
-dioxus-web = { version = "*", features=["hydrate"], optional = true }
-
-# Server dependancies
-axum = { version = "0.6.12", optional = true }
-tokio = { version = "1.27.0", features = ["full"], optional = true }
-
-[features]
-default = []
-ssr = ["axum", "tokio", "dioxus-fullstack/axum"]
-web = ["dioxus-web"]
-```
-
-Next, we need to modify our `main.rs` to use either hydrate on the client or render on the server depending on the active features.
-
-```rust, no_run
-{{#include ../../../examples/hydration.rs}}
-```
-
-Now, build your client-side bundle with `dx build --features web` and run your server with `cargo run --features ssr`. You should see the same page as before, but now you can interact with the buttons!
-
-## Sycronizing props between the server and client
-
-Let's make the initial count of the counter dynamic based on the current page.
-
-### Modifying the server
-
-To do this, we must remove the serve_dioxus_application and replace it with a custom implementation of its four key functions:
-
-- Serve static WASM and JS files with serve_static_assets
-- Register server functions with register_server_fns (more information on server functions later)
-- Connect to the hot reload server with connect_hot_reload
-- A custom route that uses SSRState to server-side render the application
-
-### Modifying the client
-
-The only thing we need to change on the client is the props. `dioxus-fullstack` will automatically serialize the props it uses to server render the app and send them to the client. In the client section of `main.rs`, we need to add `get_root_props_from_document` to deserialize the props before we hydrate the app.
-
-```rust, no_run
-{{#include ../../../examples/hydration_props.rs}}
-```
-
-Now, build your client-side bundle with `dx build --features web` and run your server with `cargo run --features ssr`. Navigate to `http://localhost:8080/1` and you should see the counter start at 1. Navigate to `http://localhost:8080/2` and you should see the counter start at 2.
diff --git a/docs/guide/src/en/fullstack/index.md b/docs/guide/src/en/fullstack/index.md
deleted file mode 100644
index a9b39c8f1..000000000
--- a/docs/guide/src/en/fullstack/index.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Fullstack development
-
-So far you have learned about three different approaches to target the web with Dioxus:
-
-- [Client-side rendering with dioxus-web](../getting_started/web.md)
-- [Server-side rendering with dioxus-liveview](../getting_started/liveview.md)
-- [Server-side static HTML generation with dioxus-ssr](../getting_started/ssr.md)
-
-## Summary of Existing Approaches
-
-Each approach has its tradeoffs:
-
-### Client-side rendering
-
-- With Client side rendering, you send the entire content of your application to the client, and then the client generates all of the HTML of the page dynamically.
-
-- This means that the page will be blank until the JavaScript bundle has loaded and the application has initialized. This can result in **slower first render times and makes the page less SEO-friendly**.
-
-> SEO stands for Search Engine Optimization. It refers to the practice of making your website more likely to appear in search engine results. Search engines like Google and Bing use web crawlers to index the content of websites. Most of these crawlers are not able to run JavaScript, so they will not be able to index the content of your page if it is rendered client-side.
-
-- Client-side rendered applications need to use **weakly typed requests to communicate with the server**
-
-> Client-side rendering is a good starting point for most applications. It is well supported and makes it easy to communicate with the client/browser APIs
-
-### Liveview
-
-- Liveview rendering communicates with the server over a WebSocket connection. It essentially moves all of the work that Client-side rendering does to the server.
-
-- This makes it **easy to communicate with the server, but more difficult to communicate with the client/browser APIS**.
-
-- Each interaction also requires a message to be sent to the server and back which can cause **issues with latency**.
-
-- Because Liveview uses a websocket to render, the page will be blank until the WebSocket connection has been established and the first renderer has been sent form the websocket. Just like with client side rendering, this can make the page **less SEO-friendly**.
-
-- Because the page is rendered on the server and the page is sent to the client piece by piece, you never need to send the entire application to the client. The initial load time can be faster than client-side rendering with large applications because Liveview only needs to send a constant small websocket script regardless of the size of the application.
-
-> Liveview is a good fit for applications that already need to communicate with the server frequently (like real time collaborative apps), but don't need to communicate with as many client/browser APIs
-
-### Server-side rendering
-
-- Server-side rendering generates all of the HTML of the page on the server before the page is sent to the client. This means that the page will be fully rendered when it is sent to the client. This results in a faster first render time and makes the page more SEO-friendly. However, it **only works for static pages**.
-
-> Server-side rendering is not a good fit for purely static sites like a blog
-
-## A New Approach
-
-Each of these approaches has its tradeoffs. What if we could combine the best parts of each approach?
-
-- **Fast initial render** time like SSR
-- **Works well with SEO** like SSR
-- **Type safe easy communication with the server** like Liveview
-- **Access to the client/browser APIs** like Client-side rendering
-- **Fast interactivity** like Client-side rendering
-
-We can achieve this by rendering the initial page on the server (SSR) and then taking over rendering on the client (Client-side rendering). Taking over rendering on the client is called **hydration**.
-
-Finally, we can use [server functions](server_functions.md) to communicate with the server in a type-safe way.
-
-This approach uses both the dioxus-web and dioxus-ssr crates. To integrate those two packages and `axum`, `warp`, or `salvo`, Dioxus provides the `dioxus-fullstack` crate.
diff --git a/docs/guide/src/en/fullstack/server_functions.md b/docs/guide/src/en/fullstack/server_functions.md
deleted file mode 100644
index 581aa382a..000000000
--- a/docs/guide/src/en/fullstack/server_functions.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Communicating with the server
-
-`dixous-server` provides server functions that allow you to call an automatically generated API on the server from the client as if it were a local function.
-
-To make a server function, simply add the `#[server(YourUniqueType)]` attribute to a function. The function must:
-
-- Be an async function
-- Have arguments and a return type that both implement serialize and deserialize (with [serde](https://serde.rs/)).
-- Return a `Result` with an error type of ServerFnError
-
-You must call `register` on the type you passed into the server macro in your main function before starting your server to tell Dioxus about the server function.
-
-Let's continue building on the app we made in the [getting started](./getting_started.md) guide. We will add a server function to our app that allows us to double the count on the server.
-
-First, add serde as a dependency:
-
-```shell
-cargo add serde
-```
-
-Next, add the server function to your `main.rs`:
-
-```rust, no_run
-{{#include ../../../examples/server_function.rs}}
-```
-
-Now, build your client-side bundle with `dx build --features web` and run your server with `cargo run --features ssr`. You should see a new button that multiplies the count by 2.
-
-## Conclusion
-
-That's it! You've created a full-stack Dioxus app. You can find more examples of full-stack apps and information about how to integrate with other frameworks and desktop renderers in the [dioxus-fullstack examples directory](https://github.com/DioxusLabs/dioxus/tree/master/packages/server/examples).
diff --git a/docs/guide/src/en/getting_started/desktop.md b/docs/guide/src/en/getting_started/desktop.md
deleted file mode 100644
index 42fe5c1a2..000000000
--- a/docs/guide/src/en/getting_started/desktop.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Desktop Overview
-
-Build a standalone native desktop app that looks and feels the same across operating systems.
-
-Apps built with Dioxus are typically <5mb in size and use existing system resources, so they won't hog extreme amounts of RAM or memory.
-
-Examples:
-
-- [File Explorer](https://github.com/DioxusLabs/example-projects/blob/master/file-explorer)
-- [WiFi Scanner](https://github.com/DioxusLabs/example-projects/blob/master/wifi-scanner)
-
-[](https://github.com/DioxusLabs/example-projects/tree/master/file-explorer)
-
-## Support
-
-The desktop is a powerful target for Dioxus but is currently limited in capability when compared to the Web platform. Currently, desktop apps are rendered with the platform's WebView library, but your Rust code is running natively on a native thread. This means that browser APIs are _not_ available, so rendering WebGL, Canvas, etc is not as easy as the Web. However, native system APIs _are_ accessible, so streaming, WebSockets, filesystem, etc are all viable APIs. In the future, we plan to move to a custom web renderer-based DOM renderer with WGPU integrations.
-
-Dioxus Desktop is built off [Tauri](https://tauri.app/). Right now there aren't any Dioxus abstractions over the menubar, handling, etc, so you'll want to leverage Tauri – mostly [Wry](http://github.com/tauri-apps/wry/) and [Tao](http://github.com/tauri-apps/tao)) directly.
-
-# Getting started
-
-## Platform-Specific Dependencies
-
-Dioxus desktop renders through a web view. Depending on your platform, you might need to install some dependancies.
-
-### Windows
-
-Windows Desktop apps depend on WebView2 – a library that should be installed in all modern Windows distributions. If you have Edge installed, then Dioxus will work fine. If you _don't_ have Webview2, [then you can install it through Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/webview2/). MS provides 3 options:
-
-1. A tiny "evergreen" _bootstrapper_ that fetches an installer from Microsoft's CDN
-2. A tiny _installer_ that fetches Webview2 from Microsoft's CDN
-3. A statically linked version of Webview2 in your final binary for offline users
-
-For development purposes, use Option 1.
-
-### Linux
-
-Webview Linux apps require WebkitGtk. When distributing, this can be part of your dependency tree in your `.rpm` or `.deb`. However, likely, your users will already have WebkitGtk.
-
-```bash
-sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev libayatana-appindicator3-dev
-```
-
-When using Debian/bullseye `libappindicator3-dev` is no longer available but replaced by `libayatana-appindicator3-dev`.
-
-```bash
-# on Debian/bullseye use:
-sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev libayatana-appindicator3-dev
-```
-
-If you run into issues, make sure you have all the basics installed, as outlined in the [Tauri docs](https://tauri.studio/v1/guides/getting-started/prerequisites#setting-up-linux).
-
-### MacOS
-
-Currently – everything for macOS is built right in! However, you might run into an issue if you're using nightly Rust due to some permissions issues in our Tao dependency (which have been resolved but not published).
-
-## Creating a Project
-
-Create a new crate:
-
-```shell
-cargo new --bin demo
-cd demo
-```
-
-Add Dioxus and the desktop renderer as dependencies (this will edit your `Cargo.toml`):
-
-```shell
-cargo add dioxus
-cargo add dioxus-desktop
-```
-
-Edit your `main.rs`:
-
-```rust, no_run
-{{#include ../../../examples/hello_world_desktop.rs:all}}
-```
diff --git a/docs/guide/src/en/getting_started/fullstack.md b/docs/guide/src/en/getting_started/fullstack.md
deleted file mode 100644
index fa3ba67c2..000000000
--- a/docs/guide/src/en/getting_started/fullstack.md
+++ /dev/null
@@ -1 +0,0 @@
-# Fullstack
diff --git a/docs/guide/src/en/getting_started/hot_reload.md b/docs/guide/src/en/getting_started/hot_reload.md
deleted file mode 100644
index d207f361a..000000000
--- a/docs/guide/src/en/getting_started/hot_reload.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Setting Up Hot Reload
-
-1. Hot reloading allows much faster iteration times inside of rsx calls by interpreting them and streaming the edits.
-2. It is useful when changing the styling/layout of a program, but will not help with changing the logic of a program.
-3. Currently the cli only implements hot reloading for the web renderer. For TUI, desktop, and LiveView you can use the hot reload macro instead.
-
-# Web
-
-For the web renderer, you can use the dioxus cli to serve your application with hot reloading enabled.
-
-## Setup
-
-Install [dioxus-cli](https://github.com/DioxusLabs/cli).
-Hot reloading is automatically enabled when using the web renderer on debug builds.
-
-## Usage
-
-1. Run:
-
-```bash
-dx serve --hot-reload
-```
-
-2. Change some code within a rsx or render macro
-3. Open your localhost in a browser
-4. Save and watch the style change without recompiling
-
-# Desktop/Liveview/TUI/Server
-
-For desktop, LiveView, and tui, you can place the hot reload macro at the top of your main function to enable hot reloading.
-Hot reloading is automatically enabled on debug builds.
-
-For more information about hot reloading on native platforms and configuration options see the [dioxus-hot-reload](https://crates.io/crates/dioxus-hot-reload) crate.
-
-## Setup
-
-Add the following to your main function:
-
-```rust, no_run
-fn main() {
- hot_reload_init!();
- // launch your application
-}
-```
-
-## Usage
-
-1. Run:
-
-```bash
-cargo run
-```
-
-2. Change some code within a rsx or render macro
-3. Save and watch the style change without recompiling
-
-# Limitations
-
-1. The interpreter can only use expressions that existed on the last full recompile. If you introduce a new variable or expression to the rsx call, it will require a full recompile to capture the expression.
-2. Components, Iterators, and some attributes can contain arbitrary rust code and will trigger a full recompile when changed.
diff --git a/docs/guide/src/en/getting_started/index.md b/docs/guide/src/en/getting_started/index.md
deleted file mode 100644
index fbf0b2d05..000000000
--- a/docs/guide/src/en/getting_started/index.md
+++ /dev/null
@@ -1,34 +0,0 @@
-# Getting Started
-
-This section will help you set up your Dioxus project!
-
-## Prerequisites
-
-### An Editor
-
-Dioxus integrates very well with the [Rust-Analyzer LSP plugin](https://rust-analyzer.github.io) which will provide appropriate syntax highlighting, code navigation, folding, and more.
-
-### Rust
-
-Head over to [https://rust-lang.org](http://rust-lang.org) and install the Rust compiler.
-
-We strongly recommend going through the [official Rust book](https://doc.rust-lang.org/book/ch01-00-getting-started.html) _completely_. However, we hope that a Dioxus app can serve as a great first Rust project. With Dioxus, you'll learn about:
-
-- Error handling
-- Structs, Functions, Enums
-- Closures
-- Macros
-
-We've put a lot of care into making Dioxus syntax familiar and easy to understand, so you won't need deep knowledge of async, lifetimes, or smart pointers until you start building complex Dioxus apps.
-
-
-## Setup Guides
-
-Dioxus supports multiple platforms. Choose the platform you want to target below to get platform-specific setup instructions:
-
-- [Web](web.md): runs in the browser through WebAssembly
-- [Server Side Rendering](ssr.md): renders to HTML text on the server
-- [Liveview](liveview.md): runs on the server, renders in the browser using WebSockets
-- [Desktop](desktop.md): runs in a web view on desktop
-- [Mobile](mobile.md): runs in a web view on mobile
-- [Terminal UI](tui.md): renders text-based graphics in the terminal
\ No newline at end of file
diff --git a/docs/guide/src/en/getting_started/liveview.md b/docs/guide/src/en/getting_started/liveview.md
deleted file mode 100644
index 56847cab5..000000000
--- a/docs/guide/src/en/getting_started/liveview.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Liveview
-
-Liveview allows apps to _run_ on the server and _render_ in the browser. It uses WebSockets to communicate between the server and the browser.
-
-Examples:
-
-- [Axum Example](https://github.com/DioxusLabs/dioxus/tree/master/packages/liveview/examples/axum.rs)
-- [Salvo Example](https://github.com/DioxusLabs/dioxus/tree/master/packages/liveview/examples/salvo.rs)
-- [Warp Example](https://github.com/DioxusLabs/dioxus/tree/master/packages/liveview/examples/warp.rs)
-
-## Support
-
-Liveview is currently limited in capability when compared to the Web platform. Liveview apps run on the server in a native thread. This means that browser APIs are not available, so rendering WebGL, Canvas, etc is not as easy as the Web. However, native system APIs are accessible, so streaming, WebSockets, filesystem, etc are all viable APIs.
-
-## Setup
-
-For this guide, we're going to show how to use Dioxus Liveview with [Axum](https://docs.rs/axum/latest/axum/).
-
-Make sure you have Rust and Cargo installed, and then create a new project:
-
-```shell
-cargo new --bin demo
-cd app
-```
-
-Add Dioxus and the liveview renderer with the Axum feature as dependencies:
-
-```shell
-cargo add dioxus
-cargo add dioxus-liveview --features axum
-```
-
-Next, add all the Axum dependencies. This will be different if you're using a different Web Framework
-
-```
-cargo add tokio --features full
-cargo add axum
-```
-
-Your dependencies should look roughly like this:
-
-```toml
-[dependencies]
-axum = "0.4.5"
-dioxus = { version = "*" }
-dioxus-liveview = { version = "*", features = ["axum"] }
-tokio = { version = "1.15.0", features = ["full"] }
-```
-
-Now, set up your Axum app to respond on an endpoint.
-
-```rust, no_run
-{{#include ../../../examples/hello_world_liveview.rs:glue}}
-```
-
-And then add our app component:
-
-```rust, no_run
-{{#include ../../../examples/hello_world_liveview.rs:app}}
-```
-
-And that's it!
diff --git a/docs/guide/src/en/getting_started/mobile.md b/docs/guide/src/en/getting_started/mobile.md
deleted file mode 100644
index 72d597f51..000000000
--- a/docs/guide/src/en/getting_started/mobile.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Mobile App
-
-Build a mobile app with Dioxus!
-
-Example: [Todo App](https://github.com/DioxusLabs/example-projects/blob/master/ios_demo)
-
-## Support
-
-Mobile is currently the least-supported renderer target for Dioxus. Mobile apps are rendered with either the platform's WebView or experimentally through [WGPU](https://github.com/DioxusLabs/blitz). WebView doesn't support animations, transparency, and native widgets.
-
-Mobile support is currently best suited for CRUD-style apps, ideally for internal teams who need to develop quickly but don't care much about animations or native widgets.
-
-This guide is primarily targeted at iOS apps, however, you can follow it while using the `android` guide in `cargo-mobile`.
-
-## Getting Set up
-
-Getting set up with mobile can be quite challenging. The tooling here isn't great (yet) and might take some hacking around to get things working. macOS M1 is broadly unexplored and might not work for you.
-
-We're going to be using `cargo-mobile` to build for mobile. First, install it:
-
-```shell
-cargo install --git https://github.com/BrainiumLLC/cargo-mobile
-```
-
-And then initialize your app for the right platform. Use the `winit` template for now. Right now, there's no "Dioxus" template in cargo-mobile.
-
-```shell
-cargo mobile init
-```
-
-We're going to completely clear out the `dependencies` it generates for us, swapping out `winit` with `dioxus-mobile`.
-
-```toml
-
-[package]
-name = "dioxus-ios-demo"
-version = "0.1.0"
-authors = []
-edition = "2018"
-
-
-# leave the `lib` declaration
-[lib]
-crate-type = ["staticlib", "cdylib", "rlib"]
-
-
-# leave the binary it generates for us
-[[bin]]
-name = "dioxus-ios-demo-desktop"
-path = "gen/bin/desktop.rs"
-
-# clear all the dependencies
-[dependencies]
-mobile-entry-point = "0.1.0"
-dioxus = { version = "*"}
-dioxus-desktop = { version = "*" }
-simple_logger = "*"
-```
-
-Edit your `lib.rs`:
-
-```rust, no_run
-use dioxus::prelude::*;
-
-fn main() {
- dioxus_desktop::launch(app);
-}
-
-fn app(cx: Scope) -> Element {
- cx.render(rsx!{
- div {
- "hello world!"
- }
- })
-}
-```
diff --git a/docs/guide/src/en/getting_started/ssr.md b/docs/guide/src/en/getting_started/ssr.md
deleted file mode 100644
index 080efbb6d..000000000
--- a/docs/guide/src/en/getting_started/ssr.md
+++ /dev/null
@@ -1,71 +0,0 @@
-# Server-Side Rendering
-
-For lower-level control over the rendering process, you can use the `dioxus-ssr` crate directly. This can be useful when integrating with a web framework that `dioxus-server` does not support, or pre-rendering pages.
-
-## Setup
-
-For this guide, we're going to show how to use Dioxus SSR with [Axum](https://docs.rs/axum/latest/axum/).
-
-Make sure you have Rust and Cargo installed, and then create a new project:
-
-```shell
-cargo new --bin demo
-cd demo
-```
-
-Add Dioxus and the ssr renderer as dependencies:
-
-```shell
-cargo add dioxus
-cargo add dioxus-ssr
-```
-
-Next, add all the Axum dependencies. This will be different if you're using a different Web Framework
-
-```
-cargo add tokio --features full
-cargo add axum
-```
-
-Your dependencies should look roughly like this:
-
-```toml
-[dependencies]
-axum = "0.4.5"
-dioxus = { version = "*" }
-dioxus-ssr = { version = "*" }
-tokio = { version = "1.15.0", features = ["full"] }
-```
-
-Now, set up your Axum app to respond on an endpoint.
-
-```rust, no_run
-{{#include ../../../examples/hello_world_ssr.rs:main}}
-```
-
-And then add our endpoint. We can either render `rsx!` directly:
-
-```rust, no_run
-{{#include ../../../examples/hello_world_ssr.rs:endpoint}}
-```
-
-Or we can render VirtualDoms.
-
-```rust, no_run
-{{#include ../../../examples/hello_world_ssr.rs:second_endpoint}}
-```
-
-And then add our app component:
-
-```rust
-{{#include ../../../examples/hello_world_ssr.rs:component}}
-```
-
-And that's it!
-
-
-## Multithreaded Support
-
-The Dioxus VirtualDom, sadly, is not currently `Send`. Internally, we use quite a bit of interior mutability which is not thread-safe.
-When working with web frameworks that require `Send`, it is possible to render a VirtualDom immediately to a String – but you cannot hold the VirtualDom across an await point. For retained-state SSR (essentially LiveView), you'll need to spawn a VirtualDom on its own thread and communicate with it via channels or create a pool of VirtualDoms.
-You might notice that you cannot hold the VirtualDom across an await point. Because Dioxus is currently not ThreadSafe, it _must_ remain on the thread it started. We are working on loosening this requirement.
diff --git a/docs/guide/src/en/getting_started/tui.md b/docs/guide/src/en/getting_started/tui.md
deleted file mode 100644
index 504c01212..000000000
--- a/docs/guide/src/en/getting_started/tui.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Terminal UI
-
-You can build a text-based interface that will run in the terminal using Dioxus.
-
-
-
-> Note: this book was written with HTML-based platforms in mind. You might be able to follow along with TUI, but you'll have to adapt a bit.
-
-## Support
-
-TUI support is currently quite experimental. But, if you're willing to venture into the realm of the unknown, this guide will get you started.
-
-- It uses flexbox for the layout
-- It only supports a subset of the attributes and elements
-- Regular widgets will not work in the tui render, but the tui renderer has its own widget components that start with a capital letter. See the [widgets example](https://github.com/DioxusLabs/dioxus/blob/master/packages/dioxus-tui/examples/widgets.rs)
-- 1px is one character line height. Your regular CSS px does not translate
-- If your app panics, your terminal is wrecked. This will be fixed eventually
-
-## Getting Set up
-
-Start by making a new package and adding Dioxus and the TUI renderer as dependancies.
-
-```shell
-cargo new --bin demo
-cd demo
-cargo add dioxus
-cargo add dioxus-tui
-```
-
-Then, edit your `main.rs` with the basic template.
-
-```rust, no_run
-{{#include ../../../examples/hello_world_tui.rs}}
-```
-
-To run our app:
-
-```shell
-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, no_run
-{{#include ../../../examples/hello_world_tui_no_ctrl_c.rs}}
-```
diff --git a/docs/guide/src/en/getting_started/web.md b/docs/guide/src/en/getting_started/web.md
deleted file mode 100644
index 48818bf8f..000000000
--- a/docs/guide/src/en/getting_started/web.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Web
-
-Build single-page applications that run in the browser with Dioxus. To run on the Web, your app must be compiled to WebAssembly and depend on the `dioxus` and `dioxus-web` crates.
-
-A build of Dioxus for the web will be roughly equivalent to the size of a React build (70kb vs 65kb) but it will load significantly faster because [WebAssembly can be compiled as it is streamed](https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/).
-
-Examples:
-
-- [TodoMVC](https://github.com/DioxusLabs/example-projects/tree/master/todomvc)
-- [ECommerce](https://github.com/DioxusLabs/example-projects/tree/master/ecommerce-site)
-
-[](https://github.com/DioxusLabs/example-projects/blob/master/todomvc)
-
-> Note: Because of the limitations of Wasm, [not every crate will work](https://rustwasm.github.io/docs/book/reference/which-crates-work-with-wasm.html) with your web apps, so you'll need to make sure that your crates work without native system calls (timers, IO, etc).
-
-## Support
-
-The Web is the best-supported target platform for Dioxus.
-
-- Because your app will be compiled to WASM you have access to browser APIs through [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/introduction.html).
-- Dioxus provides hydration to resume apps that are rendered on the server. See the [fullstack](fullstack.md) getting started guide for more information.
-
-## Tooling
-
-To develop your Dioxus app for the web, you'll need a tool to build and serve your assets. We recommend using [dioxus-cli](https://github.com/DioxusLabs/dioxus/tree/master/packages/cli) which includes a build system, Wasm optimization, a dev server, and support hot reloading:
-
-```shell
-cargo install dioxus-cli
-```
-
-Make sure the `wasm32-unknown-unknown` target for rust is installed:
-
-```shell
-rustup target add wasm32-unknown-unknown
-```
-
-## Creating a Project
-
-Create a new crate:
-
-```shell
-cargo new --bin demo
-cd demo
-```
-
-Add Dioxus and the web renderer as dependencies (this will edit your `Cargo.toml`):
-
-```bash
-cargo add dioxus
-cargo add dioxus-web
-```
-
-Edit your `main.rs`:
-
-```rust, no_run
-{{#include ../../../examples/hello_world_web.rs}}
-```
-
-And to serve our app:
-
-```bash
-dx serve
-```
diff --git a/docs/guide/src/en/images/compiletimecorrect.png b/docs/guide/src/en/images/compiletimecorrect.png
deleted file mode 100644
index 8fab7509f..000000000
Binary files a/docs/guide/src/en/images/compiletimecorrect.png and /dev/null differ
diff --git a/docs/guide/src/en/images/component_tree.png b/docs/guide/src/en/images/component_tree.png
deleted file mode 100644
index d96924073..000000000
Binary files a/docs/guide/src/en/images/component_tree.png and /dev/null differ
diff --git a/docs/guide/src/en/images/diffing.png b/docs/guide/src/en/images/diffing.png
deleted file mode 100644
index 4c243bc75..000000000
Binary files a/docs/guide/src/en/images/diffing.png and /dev/null differ
diff --git a/docs/guide/src/en/images/dioxuslogo_full.png b/docs/guide/src/en/images/dioxuslogo_full.png
deleted file mode 100644
index 7d08f2af8..000000000
Binary files a/docs/guide/src/en/images/dioxuslogo_full.png and /dev/null differ
diff --git a/docs/guide/src/en/images/oldnew.png b/docs/guide/src/en/images/oldnew.png
deleted file mode 100644
index 5aca37e40..000000000
Binary files a/docs/guide/src/en/images/oldnew.png and /dev/null differ
diff --git a/docs/guide/src/en/images/publish.png b/docs/guide/src/en/images/publish.png
deleted file mode 100644
index b17d3bb06..000000000
Binary files a/docs/guide/src/en/images/publish.png and /dev/null differ
diff --git a/docs/guide/src/en/index.md b/docs/guide/src/en/index.md
deleted file mode 100644
index bbebb0bc9..000000000
--- a/docs/guide/src/en/index.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Introduction
-
-
-
-Dioxus is a portable, performant, and ergonomic framework for building cross-platform user interfaces in Rust. This guide will help you get started with writing Dioxus apps for the Web, Desktop, Mobile, and more.
-
-```rust, no_run
-fn app(cx: Scope) -> Element {
- let mut count = use_state(cx, || 0);
-
- cx.render(rsx!(
- h1 { "High-Five counter: {count}" }
- button { onclick: move |_| count += 1, "Up high!" }
- button { onclick: move |_| count -= 1, "Down low!" }
- ))
-}
-```
-
-Dioxus is heavily inspired by React. If you know React, getting started with Dioxus will be a breeze.
-
-> This guide assumes you already know some [Rust](https://www.rust-lang.org/)! If not, we recommend reading [_the book_](https://doc.rust-lang.org/book/ch01-00-getting-started.html) to learn Rust first.
-
-## Features
-
-- Desktop apps running natively (no Electron!) in less than 10 lines of code.
-- Incredibly ergonomic and powerful state management.
-- Comprehensive inline documentation – hover and guides for all HTML elements, listeners, and events.
-- Extremely memory efficient – 0 global allocations for steady-state components.
-- Multi-channel asynchronous scheduler for first-class async support.
-- And more! Read the [full release post](https://dioxuslabs.com/blog/introducing-dioxus/).
-
-### Multiplatform
-
-Dioxus is a _portable_ toolkit, meaning the Core implementation can run anywhere with no platform-dependent linking. Unlike many other Rust frontend toolkits, Dioxus is not intrinsically linked to WebSys. In fact, every element and event listener can be swapped out at compile time. By default, Dioxus ships with the `html` feature enabled, but this can be disabled depending on your target renderer.
-
-Right now, we have several 1st-party renderers:
-
-- WebSys (for WASM): Great support
-- Tao/Tokio (for Desktop apps): Good support
-- Tao/Tokio (for Mobile apps): Poor support
-- SSR (for generating static markup)
-- TUI/Rink (for terminal-based apps): Experimental
-
-## Stability
-
-Dioxus has not reached a stable release yet.
-
-Web: Since the web is a fairly mature platform, we expect there to be very little API churn for web-based features.
-
-Desktop: APIs will likely be in flux as we figure out better patterns than our ElectronJS counterpart.
-
-SSR: We don't expect the SSR API to change drastically in the future.
diff --git a/docs/guide/src/en/interactivity/custom_hooks.md b/docs/guide/src/en/interactivity/custom_hooks.md
deleted file mode 100644
index d075bb632..000000000
--- a/docs/guide/src/en/interactivity/custom_hooks.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# Custom Hooks
-
-Hooks are a great way to encapsulate business logic. If none of the existing hooks work for your problem, you can write your own.
-
-When writing your hook, you can make a function that accepts `cx: &ScopeState` as a parameter to accept a scope with any Props.
-
-## Composing Hooks
-
-To avoid repetition, you can encapsulate business logic based on existing hooks to create a new hook.
-
-For example, if many components need to access an `AppSettings` struct, you can create a "shortcut" hook:
-
-```rust, no_run
-{{#include ../../../examples/hooks_composed.rs:wrap_context}}
-```
-
-Or if you want to wrap a hook that persists reloads with the storage API, you can build on top of the use_ref hook to work with mutable state:
-
-```rust, no_run
-{{#include ../../../examples/hooks_composed.rs:use_storage}}
-```
-
-## Custom Hook Logic
-
-You can use [`cx.use_hook`](https://docs.rs/dioxus/latest/dioxus/prelude/struct.ScopeState.html#method.use_hook) to build your own hooks. In fact, this is what all the standard hooks are built on!
-
-`use_hook` accepts a single closure for initializing the hook. It will be only run the first time the component is rendered. The return value of that closure will be used as the value of the hook – Dioxus will take it, and store it for as long as the component is alive. On every render (not just the first one!), you will get a reference to this value.
-
-> Note: You can implement [`Drop`](https://doc.rust-lang.org/std/ops/trait.Drop.html) for your hook value – it will be dropped then the component is unmounted (no longer in the UI)
-
-Inside the initialization closure, you will typically make calls to other `cx` methods. For example:
-
-- The `use_state` hook tracks state in the hook value, and uses [`cx.schedule_update`](https://docs.rs/dioxus/latest/dioxus/prelude/struct.ScopeState.html#method.schedule_update) to make Dioxus re-render the component whenever it changes.
-
-Here is a simplified implementation of the `use_state` hook:
-
-```rust, no_run
-{{#include ../../../examples/hooks_custom_logic.rs:use_state}}
-```
-
-- The `use_context` hook calls [`cx.consume_context`](https://docs.rs/dioxus/latest/dioxus/prelude/struct.ScopeState.html#method.consume_context) (which would be expensive to call on every render) to get some context from the scope
-
-Here is an implementation of the `use_context` and `use_context_provider` hooks:
-
-```rust, no_run
-{{#include ../../../examples/hooks_custom_logic.rs:use_context}}
-```
-
-## Hook Anti-Patterns
-
-When writing a custom hook, you should avoid the following anti-patterns:
-
-- !Clone Hooks: To allow hooks to be used within async blocks, the hooks must be Clone. To make a hook clone, you can wrap data in Rc or Arc and avoid lifetimes in hooks.
-
-This version of use_state may seem more efficient, but it is not cloneable:
-
-```rust, no_run
-{{#include ../../../examples/hooks_anti_patterns.rs:non_clone_state}}
-```
-
-If we try to use this hook in an async block, we will get a compile error:
-
-```rust, no_run
-fn FutureComponent(cx: &ScopeState) -> Element {
- let my_state = my_use_state(cx, || 0);
- cx.spawn({
- to_owned![my_state];
- async move {
- my_state.set(1);
- }
- });
-
- todo!()
-}
-```
-
-But with the original version, we can use it in an async block:
-
-```rust, no_run
-fn FutureComponent(cx: &ScopeState) -> Element {
- let my_state = use_state(cx, || 0);
- cx.spawn({
- to_owned![my_state];
- async move {
- my_state.set(1);
- }
- });
-
- todo!()
-}
-```
diff --git a/docs/guide/src/en/interactivity/dynamic_rendering.md b/docs/guide/src/en/interactivity/dynamic_rendering.md
deleted file mode 100644
index 8d91650c3..000000000
--- a/docs/guide/src/en/interactivity/dynamic_rendering.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Dynamic Rendering
-
-Sometimes you want to render different things depending on the state/props. With Dioxus, just describe what you want to see using Rust control flow – the framework will take care of making the necessary changes on the fly if the state or props change!
-
-## Conditional Rendering
-
-To render different elements based on a condition, you could use an `if-else` statement:
-
-```rust, no_run
-{{#include ../../../examples/conditional_rendering.rs:if_else}}
-```
-
-> You could also use `match` statements, or any Rust function to conditionally render different things.
-
-### Improving the `if-else` Example
-
-You may have noticed some repeated code in the `if-else` example above. Repeating code like this is both bad for maintainability and performance. Dioxus will skip diffing static elements like the button, but when switching between multiple `rsx` calls it cannot perform this optimization. For this example either approach is fine, but for components with large parts that are reused between conditionals, it can be more of an issue.
-
-We can improve this example by splitting up the dynamic parts and inserting them where they are needed.
-
-```rust, no_run
-{{#include ../../../examples/conditional_rendering.rs:if_else_improved}}
-```
-
-### Inspecting `Element` props
-
-Since `Element` is a `Option-
-
- First Item -
- Second Item -
- Third Item -
First Item
-Second Item
-a group -of three -items -``` - -### Atributos - -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, no_run -{{#include ../../../examples/rsx_overview.rs:attributes}} -``` - -```html -Log In -``` - -> Nota: Todos os atributos definidos em `dioxus-html` seguem a convenção de nomenclatura snake_case. Eles transformam seus nomes `snake_case` em atributos `camelCase` do HTML. - -#### Atributos Personalizados - -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, no_run -{{#include ../../../examples/rsx_overview.rs:custom_attributes}} -``` - -```html - Rust is cool -``` - -### Interpolação - -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, no_run -{{#include ../../../examples/rsx_overview.rs:formatting}} -``` - -```html -
- Coordinates: (42, 0)
-
-```
-
-### Expressões
-
-Você pode incluir expressões Rust arbitrárias dentro do RSX, mas deve escapá-las entre colchetes `[]`:
-
-```rust, no_run
-{{#include ../../../examples/rsx_overview.rs:expression}}
-```
-
-```html
-DIOXUS
-```
diff --git a/docs/guide/src/pt-br/describing_ui/special_attributes.md b/docs/guide/src/pt-br/describing_ui/special_attributes.md
deleted file mode 100644
index 01bfe9b25..000000000
--- a/docs/guide/src/pt-br/describing_ui/special_attributes.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Atributos Especiais
-
-Enquanto a maioria dos atributos são simplesmente passados para o HTML, alguns têm comportamentos especiais.
-
-## A Escotilha de Escape do HTML
-
-Se você estiver trabalhando com itens pré-renderizados, modelos ou uma biblioteca JS, convém passar o HTML diretamente em vez de passar pelo Dioxus. Nesses casos, use `dangerous_inner_html`.
-
-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, no_run
-{{#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.
->
-> Se você estiver lidando com entradas não confiáveis, certifique-se de higienizar seu HTML antes de passá-lo para `dangerous_inner_html` – ou apenas passe-o para um elemento de texto para escapar de qualquer tag HTML.
-
-## Atributos Booleanos
-
-A maioria dos atributos, quando renderizados, serão renderizados exatamente como a entrada que você forneceu. No entanto, alguns atributos são considerados atributos "booleanos" e apenas sua presença determina se eles afetam a saída. Para esses atributos, um valor fornecido de `"false"` fará com que eles sejam removidos do elemento de destino.
-
-Portanto, este RSX não renderizaria o atributo `hidden`:
-
-```rust, no_run
-{{#include ../../../examples/boolean_attribute.rs:boolean_attribute}}
-```
-
-```html
-ES
- 42
-hello
-```
-
-No entanto, nem todos os atributos funcionam assim. _Apenas os seguintes atributos_ têm este comportamento:
-
-- `allowfullscreen`
-- `allowpaymentrequest`
-- `async`
-- `autofocus`
-- `autoplay`
-- `checked`
-- `controls`
-- `default`
-- `defer`
-- `disabled`
-- `formnovalidate`
-- `hidden`
-- `ismap`
-- `itemscope`
-- `loop`
-- `multiple`
-- `muted`
-- `nomodule`
-- `novalidate`
-- `open`
-- `playsinline`
-- `readonly`
-- `required`
-- `reversed`
-- `selected`
-- `truespeed`
-
-Para quaisquer outros atributos, um valor de `"false"` será enviado diretamente para o DOM.
diff --git a/docs/guide/src/pt-br/getting_started/desktop.md b/docs/guide/src/pt-br/getting_started/desktop.md
deleted file mode 100644
index 70f71aa1a..000000000
--- a/docs/guide/src/pt-br/getting_started/desktop.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Aplicativo de área de trabalho
-
-Crie um aplicativo de desktop nativo autônomo que tenha a mesma aparência em todos os sistemas operacionais.
-
-Os aplicativos criados com o Dioxus geralmente têm menos de 5 MB de tamanho e usam os recursos existentes do sistema, para que não consumam quantidades extremas de RAM ou memória.
-
-Exemplos:
-
-- [Explorador de arquivos](https://github.com/DioxusLabs/example-projects/blob/master/file-explorer)
-- [Scanner WiFi](https://github.com/DioxusLabs/example-projects/blob/master/wifi-scanner)
-
-[](https://github.com/DioxusLabs/example-projects/tree /master/file-explorer)
-
-## Suporte
-
-O desktop é uma plataforma poderosa para o Dioxus, mas atualmente é limitado em capacidade quando comparado à plataforma Web. Atualmente, os aplicativos de desktop são renderizados com a biblioteca WebView da própria plataforma, mas seu código Rust está sendo executado nativamente em um _thread_ nativo. Isso significa que as APIs do navegador _não_ estão disponíveis, portanto, renderizar WebGL, Canvas, etc. não é tão fácil quanto a Web. No entanto, as APIs do sistema nativo _são_ acessíveis, portanto, streaming, WebSockets, sistema de arquivos, etc., são todas APIs viáveis. No futuro, planejamos migrar para um renderizador DOM personalizado baseado em webrenderer com integrações WGPU.
-
-O Dioxus Desktop é construído a partir do [Tauri](https://tauri.app/). No momento, não há abstrações do Dioxus sobre atalhos de teclado, barra de menus, manuseio, etc., então você deve aproveitar o Tauri - principalmente [Wry](http://github.com/tauri-apps/wry/) e [ Tao](http://github.com/tauri-apps/tao)) diretamente.
-
-## Criando um projeto
-
-Crie uma nova caixa:
-
-```shell
-cargo new --bin demo
-cd demo
-```
-
-Adicione o Dioxus com o recurso `desktop` (isso irá editar o `Cargo.toml`):
-
-```shell
-cargo add dioxus
-cargo add dioxus-desktop
-```
-
-Edite seu `main.rs`:
-
-```rust, no_run
-{{#include ../../../examples/hello_world_desktop.rs:all}}
-```
diff --git a/docs/guide/src/pt-br/getting_started/hot_reload.md b/docs/guide/src/pt-br/getting_started/hot_reload.md
deleted file mode 100644
index 447169055..000000000
--- a/docs/guide/src/pt-br/getting_started/hot_reload.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Configurando o Hot Reload
-
-1. O recarregamento em tempo-real (_hot reload_) permite tempos de iteração muito mais rápidos dentro de chamadas 'rsx', interpretando-as e transmitindo as edições.
-2. É útil para alterar o estilo/layout de um programa, mas não ajudará na alteração da lógica de um programa.
-3. Atualmente, o cli implementa apenas o _hot-reload_ para o renderizador da web.
-
-# Configurar
-
-Instale o [dioxus-cli](https://github.com/DioxusLabs/cli).
-Habilite o recurso de _hot-reload_ no dioxus:
-
-```toml
-dioxus = { version = "*", features = ["hot-reload"] }
-```
-
-# Usage
-
-1. Execute:
-
-```
-dx serve --hot-reload
-```
-
-2. alterar algum código dentro de uma macro `rsx`
-3. abra seu `localhost` em um navegador
-4. salve e observe a mudança de estilo sem recompilar
-
-# Limitações
-
-1. O interpretador só pode usar expressões que existiam na última recompilação completa. Se você introduzir uma nova variável ou expressão na chamada `rsx`, ela acionará uma recompilação completa para capturar a expressão.
-2. Componentes e Iteradores podem conter código de Rust arbitrário e acionarão uma recompilação completa quando alterados.
diff --git a/docs/guide/src/pt-br/getting_started/index.md b/docs/guide/src/pt-br/getting_started/index.md
deleted file mode 100644
index 2ee8fe89f..000000000
--- a/docs/guide/src/pt-br/getting_started/index.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Introdução
-
-Esta seção irá ajudá-lo a configurar seu projeto Dioxus!
-
-## Pré-requisitos
-
-### Editor
-
-O Dioxus se integra muito bem com o [plugin Rust-Analyzer LSP](https://rust-analyzer.github.io) que fornecerá realce de sintaxe apropriado, navegação de código, _folding_ e muito mais.
-
-### Rust
-
-Vá para [https://rust-lang.org](http://rust-lang.org) e instale o compilador Rust.
-
-É altamente recomendável ler o [livro oficial do Rust](https://doc.rust-lang.org/book/ch01-00-getting-started.html) _completamente_. No entanto, nossa esperança é que um aplicativo Dioxus possa servir como um ótimo primeiro projeto Rust. Com Dioxus, você aprenderá sobre:
-
-- Manipulação de erros
-- Estruturas, Funções, Enums
-- Closures
-- Macros
-
-Nós empenhamos muito cuidado para tornar a sintaxe do Dioxus familiar e fácil de entender, para que você não precise de conhecimento profundo sobre _async_, _lifetime_ ou _smart pointers_ até que você realmente comece a criar aplicativos Dioxus complexos.
-
-### Dependências Específicas da Plataforma
-
-#### Windows
-
-Os aplicativos da área de trabalho do Windows dependem do WebView2 – uma biblioteca que deve ser instalada em todas as distribuições modernas do Windows. Se você tiver o Edge instalado, o Dioxus funcionará bem. Se você _não_ tiver o Webview2, [você poderá instalá-lo pela Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/webview2/). MS oferece 3 opções:
-
-1. Um pequeno _bootstrapper_ "evergreen" que buscará um instalador do CDN da Microsoft
-2. Um pequeno _instalador_ que buscará o Webview2 do CDN da Microsoft
-3. Uma versão vinculada estaticamente do Webview2 em seu binário final para usuários offline
-
-Para fins de desenvolvimento, use a Opção 1.
-
-#### Linux
-
-Os aplicativos Webview Linux requerem WebkitGtk. Ao distribuir, isso pode ser parte de sua árvore de dependência em seu `.rpm` ou `.deb`. No entanto, é muito provável que seus usuários já tenham o WebkitGtk.
-
-```bash
-sudo apt install libwebkit2gtk-4.0-dev libgtk-3-dev libappindicator3-dev
-```
-
-Ao usar o Debian/bullseye, o `libappindicator3-dev` não está mais disponível, pois foi substituído por `libayatana-appindicator3-dev`.
-
-```bash
-# on Debian/bullseye use:
-sudo apt install libwebkit2gtk-4.0-dev libgtk-3-dev libayatana-appindicator3-dev
-```
-
-Se você tiver problemas, certifique-se de ter todo o básico instalado, conforme descrito nos [documentos do Tauri](https://tauri.studio/v1/guides/getting-started/prerequisites#setting-up-linux).
-
-#### Mac OS
-
-Atualmente – tudo para macOS está integrado! No entanto, você pode encontrar um problema se estiver usando o Rust **nightly** devido a alguns problemas de permissão em nossa dependência do `Tao` (que foram resolvidos, mas não publicados).
-
-### Extensões do Cargo Sugeridas
-
-Se você quiser manter seu fluxo de trabalho tradicional como `npm install XXX` para adicionar pacotes, você pode querer instalar o `cargo-edit` e algumas outras extensões `cargo` interessantes:
-
-- [cargo-expand](https://github.com/dtolnay/cargo-expand) para expandir chamadas de macro
-- [árvore de carga](https://doc.rust-lang.org/cargo/commands/cargo-tree.html) – um comando de carga integrado que permite inspecionar sua árvore de dependência
-
-## Guias de configuração
-
-Dioxus suporta múltiplas plataformas. Dependendo do que você quer, a configuração é um pouco diferente.
-
-- [Web](web.md): rodando no navegador usando WASM
-- [Server Side Rendering](ssr.md): renderiza Dioxus HTML como texto
-- [Desktop](desktop.md): um aplicativo autônomo usando o webview
-- [Celular](mobile.md)
-- [Terminal UI](tui.md): interface gráfica baseada em texto do terminal
diff --git a/docs/guide/src/pt-br/getting_started/mobile.md b/docs/guide/src/pt-br/getting_started/mobile.md
deleted file mode 100644
index 66a17272b..000000000
--- a/docs/guide/src/pt-br/getting_started/mobile.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Aplicativo móvel
-
-Crie um aplicativo móvel com Dioxus!
-
-Exemplo: [Aplicativo Todo](https://github.com/DioxusLabs/example-projects/blob/master/ios_demo)
-
-## Suporte
-
-Atualmente, a plataforma móvel é o destino de renderizador menos suportado para o Dioxus. Os aplicativos móveis são renderizados com o WebView da plataforma, o que significa que animações, transparência e widgets nativos não estão disponíveis no momento.
-
-Além disso, o iOS é a única plataforma móvel compatível. É possível obter o Dioxus rodando no Android e renderizado com WebView, mas a biblioteca de janelas do Rust que o Dioxus usa – tao – atualmente não suporta Android.
-
-Atualmente, o suporte móvel é mais adequado para aplicativos no estilo CRUD, idealmente para equipes internas que precisam desenvolver rapidamente, mas não se importam muito com animações ou widgets nativos.
-
-## Configurando
-
-A configuração com dispositivos móveis pode ser bastante desafiadora. As ferramentas aqui não são ótimas (ainda) e podem precisar de alguns _hacks_ para fazer as coisas funcionarem. O macOS M1 é amplamente inexplorado e pode não funcionar para você.
-
-Vamos usar `cargo-mobile` para construir para dispositivos móveis. Primeiro, instale-o:
-
-```shell
-cargo install --git https://github.com/BrainiumLLC/cargo-mobile
-```
-
-E, em seguida, inicialize seu aplicativo para a plataforma certa. Use o modelo `winit` por enquanto. No momento, não há modelo "Dioxus" no cargo-mobile.
-
-```shell
-cargo mobile init
-```
-
-Nós vamos limpar completamente as `dependências` que ele gera para nós, trocando `winit` por `dioxus-mobile`.
-
-```toml
-
-[package]
-name = "dioxus-ios-demo"
-version = "0.1.0"
-authors = ["Jonathan Kelley