docs: fix the reference code
This commit is contained in:
Jonathan Kelley committed
1 parent
c34043f1c8
commit
3de776c42a
8 files changed
+300
-85
No files matched your search
+12
-10
@@ -53,18 +53,20 @@ impl WebsysDom {
|
||||
let listeners = FxHashMap::default();
|
||||
|
||||
// re-hydrate the page - only supports one virtualdom per page
|
||||
// hydration is the dubmest thing you've ever heard of
|
||||
// just blast away the page and replace it completely.
|
||||
if cfg.hydrate {
|
||||
// Load all the elements into the arena
|
||||
let node_list: NodeList = document.query_selector_all("dioxus-id").unwrap();
|
||||
let len = node_list.length() as usize;
|
||||
// // Load all the elements into the arena
|
||||
// let node_list: NodeList = document.query_selector_all("dioxus-id").unwrap();
|
||||
// let len = node_list.length() as usize;
|
||||
|
||||
for x in 0..len {
|
||||
let node: Node = node_list.get(x as u32).unwrap();
|
||||
let el: &Element = node.dyn_ref::<Element>().unwrap();
|
||||
let id: String = el.get_attribute("dioxus-id").unwrap();
|
||||
let id = id.parse::<usize>().unwrap();
|
||||
nodes[id] = Some(node);
|
||||
}
|
||||
// for x in 0..len {
|
||||
// let node: Node = node_list.get(x as u32).unwrap();
|
||||
// let el: &Element = node.dyn_ref::<Element>().unwrap();
|
||||
// let id: String = el.get_attribute("dioxus-id").unwrap();
|
||||
// let id = id.parse::<usize>().unwrap();
|
||||
// nodes[id] = Some(node);
|
||||
// }
|
||||
|
||||
// Load all the event listeners into our listener register
|
||||
// TODO
|
||||
|
||||
+35
-35
@@ -16,41 +16,41 @@
|
||||
//!
|
||||
//! To purview the examples, check of the root Dioxus crate - the examples in this crate are mostly meant to provide
|
||||
//! validation of websys-specific features and not the general use of Dioxus.
|
||||
//!
|
||||
//! ## RequestAnimationFrame and RequestIdleCallback
|
||||
//! ------------------------------------------------
|
||||
//! React implements "jank free rendering" by deliberately not blocking the browser's main thread. For large diffs, long
|
||||
//! running work, and integration with things like React-Three-Fiber, it's extremeley important to avoid blocking the
|
||||
//! main thread.
|
||||
//!
|
||||
//! React solves this problem by breaking up the rendering process into a "diff" phase and a "render" phase. In Dioxus,
|
||||
//! the diff phase is non-blocking, using "yield_now" to allow the browser to process other events. When the diff phase
|
||||
//! is finally complete, the VirtualDOM will return a set of "Mutations" for this crate to apply.
|
||||
//!
|
||||
//! Here, we schedule the "diff" phase during the browser's idle period, achieved by calling RequestIdleCallback and then
|
||||
//! setting a timeout from the that completes when the idleperiod is over. Then, we call requestAnimationFrame
|
||||
//!
|
||||
//! From Google's guide on rAF and rIC:
|
||||
//! -----------------------------------
|
||||
//!
|
||||
//! If the callback is fired at the end of the frame, it will be scheduled to go after the current frame has been committed,
|
||||
//! which means that style changes will have been applied, and, importantly, layout calculated. If we make DOM changes inside
|
||||
//! of the idle callback, those layout calculations will be invalidated. If there are any kind of layout reads in the next
|
||||
//! frame, e.g. getBoundingClientRect, clientWidth, etc, the browser will have to perform a Forced Synchronous Layout,
|
||||
//! which is a potential performance bottleneck.
|
||||
//!
|
||||
//! Another reason not trigger DOM changes in the idle callback is that the time impact of changing the DOM is unpredictable,
|
||||
//! and as such we could easily go past the deadline the browser provided.
|
||||
//!
|
||||
//! The best practice is to only make DOM changes inside of a requestAnimationFrame callback, since it is scheduled by the
|
||||
//! browser with that type of work in mind. That means that our code will need to use a document fragment, which can then
|
||||
//! be appended in the next requestAnimationFrame callback. If you are using a VDOM library, you would use requestIdleCallback
|
||||
//! to make changes, but you would apply the DOM patches in the next requestAnimationFrame callback, not the idle callback.
|
||||
//!
|
||||
//! Essentially:
|
||||
//! ------------
|
||||
//! - Do the VDOM work during the idlecallback
|
||||
//! - Do DOM work in the next requestAnimationFrame callback
|
||||
|
||||
// ## RequestAnimationFrame and RequestIdleCallback
|
||||
// ------------------------------------------------
|
||||
// React implements "jank free rendering" by deliberately not blocking the browser's main thread. For large diffs, long
|
||||
// running work, and integration with things like React-Three-Fiber, it's extremeley important to avoid blocking the
|
||||
// main thread.
|
||||
//
|
||||
// React solves this problem by breaking up the rendering process into a "diff" phase and a "render" phase. In Dioxus,
|
||||
// the diff phase is non-blocking, using "yield_now" to allow the browser to process other events. When the diff phase
|
||||
// is finally complete, the VirtualDOM will return a set of "Mutations" for this crate to apply.
|
||||
//
|
||||
// Here, we schedule the "diff" phase during the browser's idle period, achieved by calling RequestIdleCallback and then
|
||||
// setting a timeout from the that completes when the idleperiod is over. Then, we call requestAnimationFrame
|
||||
//
|
||||
// From Google's guide on rAF and rIC:
|
||||
// -----------------------------------
|
||||
//
|
||||
// If the callback is fired at the end of the frame, it will be scheduled to go after the current frame has been committed,
|
||||
// which means that style changes will have been applied, and, importantly, layout calculated. If we make DOM changes inside
|
||||
// of the idle callback, those layout calculations will be invalidated. If there are any kind of layout reads in the next
|
||||
// frame, e.g. getBoundingClientRect, clientWidth, etc, the browser will have to perform a Forced Synchronous Layout,
|
||||
// which is a potential performance bottleneck.
|
||||
//
|
||||
// Another reason not trigger DOM changes in the idle callback is that the time impact of changing the DOM is unpredictable,
|
||||
// and as such we could easily go past the deadline the browser provided.
|
||||
//
|
||||
// The best practice is to only make DOM changes inside of a requestAnimationFrame callback, since it is scheduled by the
|
||||
// browser with that type of work in mind. That means that our code will need to use a document fragment, which can then
|
||||
// be appended in the next requestAnimationFrame callback. If you are using a VDOM library, you would use requestIdleCallback
|
||||
// to make changes, but you would apply the DOM patches in the next requestAnimationFrame callback, not the idle callback.
|
||||
//
|
||||
// Essentially:
|
||||
// ------------
|
||||
// - Do the VDOM work during the idlecallback
|
||||
// - Do DOM work in the next requestAnimationFrame callback
|
||||
|
||||
use std::rc::Rc;
|
||||
|
||||
|
||||
Reference in new issue
Block a user