Reinis Mazeiks
6c323e9fc5
* Move getting started to Guide * Clean up summary and getting started * Shorten intro by moving stuff to individual platform docs * Make intro even shorter, summarize features * Further cleanup; move development-related docs to separate section * Make `guide` a crate. Turn code samples into examples so that we can check if they compile * Rewrite "Describing the UI": * Focus on RSX syntax (interactivity covered in later chapters); make sure samples are tested; concise language * Move some "special attribute" samples to the `examples` directory * Simplify introduction to components * Simplify introduction to component props * Document Prop features; add code samples * Simplify component children docs * Interactivity: better introduction to events * Hooks: better introduction * Remove outdated doc * Introducs use_ref * Simplify User Input chapter * Document event handler props * Meme editor example * Meme editor walkthrough * Add dark mode example * Guide for context; dark mode example * Guide: custom hooks * Guide: conditional rendering * Guide: rendering lists * Guide: rendering lists + keys * Move remaining infor from Reference to guide * Delete reference book
1.8 KiB
Subtrees
One way of extending the Dioxus VirtualDom is through the use of "Subtrees." Subtrees are chunks of the VirtualDom tree distinct from the rest of the tree. They still participate in event bubbling, diffing, etc, but will have a separate set of edits generated during the diff phase.
For a VirtualDom that has a root tree with two subtrees, the edits follow a pattern of:
Root -> Tree 1 -> Tree 2 -> Original root tree
- Root edits
- Tree 1 Edits
- Tree 2 Edits
- Root Edits
The goal of this functionality is to enable things like Portals, Windows, and inline alternative renderers without needing to spin up a new VirtualDom.
With the right renderer plugins, a subtree could be rendered as anything – a 3D scene, SVG, or even as the contents of a new window or modal. This functionality is similar to "Portals" in React, but much more "renderer agnostic." Portals, by nature, are not necessarily cross-platform and rely on renderer functionality, so it makes sense to abstract their purpose into the subtree concept.
The desktop renderer comes pre-loaded with the window and notification subtree plugins, making it possible to render subtrees into entirely different windows.
Subtrees also solve the "bridging" issues in React where two different renderers need two different VirtualDoms to work properly. In Dioxus, you only ever need one VirtualDom and the right renderer plugins.
API
Due to their importance in the hierarchy, Components – not nodes – are treated as subtree roots.
fn Subtree<P>(cx: Scope<P>) -> DomTree {
}
fn Window() -> DomTree {
Subtree {
onassign: move |e| {
// create window
}
children()
}
}
fn 3dRenderer -> DomTree {
Subtree {
onassign: move |e| {
// initialize bevy
}
}
}