dioxus-core is a fast and featureful VirtualDom implementation written in and for Rust.
anyhow crateIf just starting out, check out the Guides first.
The dioxus-core VirtualDom object is built around the concept of a Template. Templates describe a layout tree known at compile time with dynamic parts filled at runtime.
Each component in the VirtualDom works as a dedicated render loop where re-renders are triggered by events external to the VirtualDom, or from the components themselves.
When each component re-renders, it must return an Element. In Dioxus, the Element type is an alias for Result<VNode>. Between two renders, Dioxus compares the inner VNode object, and calculates the differences of the dynamic portions of each internal Template. If any attributes or elements are different between the old layout and new layout, Dioxus will write modifications to the Mutations object.
Dioxus expects the target renderer to save its nodes in a list. Each element is given a numerical ID which can be used to directly index into that list for O(1) lookups.
All Dioxus apps start as just a function that takes the [Scope] object and returns an [Element].
The dioxus crate exports the rsx macro which transforms a helpful, simpler syntax of Rust into the logic required to build Templates.
First, start with your app:
rust, ignore
fn app(cx: Scope) -> Element {
cx.render(rsx!( div { "hello world" } ))
}
Then, we'll want to create a new VirtualDom using this app as the root component.
rust, ignore
let mut dom = VirtualDom::new(app);
To build the app into a stream of mutations, we'll use [VirtualDom::rebuild]:
```rust, ignore let mutations = dom.rebuild();
applyeditstorealdom(mutations); ```
We can then wait for any asynchronous components or pending futures using the wait_for_work() method. If we have a deadline, then we can use renderwithdeadline instead:
```rust, ignore // Wait for the dom to be marked dirty internally dom.waitforwork().await;
// Or wait for a deadline and then collect edits dom.renderwithdeadline(tokio::time::sleep(Duration::from_millis(16))); ```
If an event occurs from outside the virtualdom while waiting for work, then we can cancel the wait using a select! block and inject the event.
```rust, ignore loop { select! { evt = realdom.event() => dom.handleevent("click", evt.data, evt.element, evt.bubbles), _ = dom.waitforwork() => {} }
// Render any work without blocking the main thread for too long
let mutations = dom.render_with_deadline(tokio::time::sleep(Duration::from_millis(10)));
// And then apply the edits
real_dom.apply(mutations);
}
```
Dioxus-core builds off the many frameworks that came before it. Notably, Dioxus borrows these concepts:
Dioxus-core leverages some really cool techniques and hits a very high level of parity with mature frameworks. However, Dioxus also brings some new unique features:
There's certainly more to the story, but these optimizations make Dioxus memory use and allocation count extremely minimal. For an average application, it is possible that zero allocations will need to be performed once the app has been loaded. Only when new components are added to the dom will allocations occur. For a given component, the space of old VNodes is dynamically recycled as new nodes are added. Additionally, Dioxus tracks the average memory footprint of previous components to estimate how much memory allocate for future components.
All in all, Dioxus treats memory as a valuable resource. Combined with the memory-efficient footprint of Wasm compilation, Dioxus apps can scale to thousands of components and still stay snappy.
The final implementation of Dioxus must: