(
root: FC,
root_props: P,
@@ -173,7 +173,7 @@ impl VirtualDom {
/// Get the [`Scope`] for the root component.
///
- /// This is useful for traversing the tree from the root for heuristics or altnerative renderers that use Dioxus
+ /// This is useful for traversing the tree from the root for heuristics or alternsative renderers that use Dioxus
/// directly.
pub fn base_scope(&self) -> &Scope {
self.scheduler.pool.get_scope(self.base_scope).unwrap()
@@ -186,7 +186,7 @@ impl VirtualDom {
/// Update the root props of this VirtualDOM.
///
- /// This method retuns None if the old props could not be removed. The entire VirtualDOM will be rebuilt immediately,
+ /// This method returns None if the old props could not be removed. The entire VirtualDOM will be rebuilt immediately,
/// so calling this method will block the main thread until computation is done.
///
/// ## Example
@@ -258,7 +258,7 @@ impl VirtualDom {
/// Compute a manual diff of the VirtualDOM between states.
///
- /// This can be useful when state inside the DOM is remotely changed from the outside, but not propogated as an event.
+ /// This can be useful when state inside the DOM is remotely changed from the outside, but not propagated as an event.
///
/// In this case, every component will be diffed, even if their props are memoized. This method is intended to be used
/// to force an update of the DOM when the state of the app is changed outside of the app.
diff --git a/reference/antipatterns.rs b/reference/antipatterns.rs
index ced8671c5..522f99a76 100644
--- a/reference/antipatterns.rs
+++ b/reference/antipatterns.rs
@@ -2,14 +2,14 @@
//! ---------------------
//!
//! This example shows what *not* to do and provides a reason why a given pattern is considered an "AntiPattern". Most
-//! anti-patterns are considered wrong to due performance reasons or violate the "rules" of Dioxus. These rules are
+//! anti-patterns are considered wrong due performance reasons or violate the "rules" of Dioxus. These rules are
//! borrowed from other successful UI frameworks, and Dioxus is more focused on providing a familiar, ergonomic interface
//! rather than building new harder-to-misuse patterns.
//!
//! In this list we showcase:
//! - Not adding keys for iterators
//! - Heavily nested fragments
-//! - Understadning ordering of set_state
+//! - Understanding ordering of set_state
//! - Naming conventions
//! - Rules of hooks
//!
@@ -21,7 +21,7 @@ use dioxus::prelude::*;
///
/// This is considered an anti-pattern for performance reasons. Dioxus will diff your current and old layout and must
/// take a slower path if it can't correlate old elements with new elements. Lists are particularly susceptible to the
-/// "slow" path, so you're strongly encouraged to provide a unique ID stable between renders. Additionally, providing
+/// "slow" path, so you're strongly encouraged to provide a unique, stable ID between renders. Additionally, providing
/// the *wrong* keys is even worse - props might be assigned to the wrong components! Keys should be:
/// - Unique
/// - Stable
@@ -47,10 +47,10 @@ static AntipatternNoKeys: FC = |(cx, props)| {
/// ------------------------------------
///
/// This particular antipattern is not necessarily an antipattern in other frameworks but does has a performance impact
-/// in Dioxus apps. Fragments don't mount a physical element to the dom immediately, so Dioxus must recurse into its
-/// children to find a physical dom node. This process is called "normalization". Other frameworks perform an agressive
-/// mutative normalization while Dioxus keeps your VNodes immutable. This means that deepely nested fragments make Dioxus
-/// perform unnecessary work. Prefer one or two levels of fragments / nested components until presenting a true dom element.
+/// in Dioxus apps. Fragments don't mount a physical element to the DOM immediately, so Dioxus must recurse into its
+/// children to find a physical DOM node. This process is called "normalization". Other frameworks perform an agressive
+/// mutative normalization while Dioxus keeps your VNodes immutable. This means that deeply nested fragments make Dioxus
+/// perform unnecessary work. Prefer one or two levels of fragments / nested components until presenting a true DOM element.
///
/// 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 ContextProvider pattern.
@@ -71,7 +71,7 @@ static AntipatternNestedFragments: FC<()> = |(cx, props)| {
)
};
-/// Antipattern: Using state after its been updated
+/// Antipattern: Using state after it's been updated
/// -----------------------------------------------
///
/// This is an antipattern in other frameworks, but less so in Dioxus. However, it's important to highlight that use_state
@@ -82,7 +82,7 @@ static AntipatternNestedFragments: FC<()> = |(cx, props)| {
/// However, calling set_state will *not* update the current version of state in the component. This should be easy to
/// recognize from the function signature, but Dioxus will not update the "live" version of state. Calling `set_state`
/// merely places a new value in the queue and schedules the component for a future update.
-static AntipaternRelyingOnSetState: FC<()> = |(cx, props)| {
+static AntipatternRelyingOnSetState: FC<()> = |(cx, props)| {
let (state, set_state) = use_state(cx, || "Hello world").classic();
set_state("New state");
// This will return false! `state` will *still* be "Hello world"
@@ -94,28 +94,28 @@ static AntipaternRelyingOnSetState: FC<()> = |(cx, props)| {
/// ---------------------------
///
/// This antipattern is enforced to retain parity with other frameworks and provide useful IDE feedback, but is less
-/// critical than other potential misues. In short:
+/// critical than other potential misuses. In short:
/// - Only raw elements may start with a lowercase character
/// - All components must start with an uppercase character
///
-/// IE: the following component will be rejected when attempted to be used in the rsx! macro
+/// i.e.: the following component will be rejected when attempted to be used in the rsx! macro
static antipattern_component: FC<()> = |(cx, props)| todo!();
/// Antipattern: Misusing hooks
/// ---------------------------
///
-/// This pattern is an unfortunate one where Dioxus supports the same behavior as in other frameworks. Dioxus supports
-/// "hooks" - IE "memory cells" that allow a value to be stored between renders. This allows other hooks to tap into
-/// a components "memory" without explicitly adding all of its data to a struct definition. In Dioxus, hooks are allocated
+/// This pattern is an unfortunate one where Dioxus replicates the same behavior as other frameworks. Dioxus supports
+/// "hooks" - i.e. "memory cells" that allow a value to be stored between renders. This allows other hooks to tap into
+/// a component's "memory" without explicitly adding all of its data to a struct definition. In Dioxus, hooks are allocated
/// with a bump arena and then immediately sealed.
///
-/// This means that hooks may not be misued:
+/// This means that hooks may not be misused:
/// - Called out of order
/// - Called in a conditional
/// - Called in loops or callbacks
///
/// For the most part, Rust helps with rule #3 but does not save you from misusing rule #1 or #2. Dioxus will panic
-/// if hooks do not downcast the same data between renders. This is validated by TypeId - and eventually - a custom key.
+/// if hooks do not downcast to the same data between renders. This is validated by TypeId and, eventually, a custom key.
#[derive(PartialEq, Props)]
struct MisuedHooksProps {
should_render_state: bool,
@@ -131,15 +131,15 @@ static AntipatternMisusedHooks: FC = |(cx, props)| {
}
};
-/// Antipattern: Downcasting refs and panicing
+/// Antipattern: Downcasting refs and panicking
/// ------------------------------------------
///
-/// Occassionally it's useful to get the ref of an element to handle it directly. Elements support downcasting to
-/// Dioxus's virtual element types as well as their true native counterparts. Downcasting to Dioxus' virtual elements
+/// Occasionally it's useful to get the ref of an element to handle it directly. Elements support downcasting to
+/// Dioxus' virtual element types as well as their true native counterparts. Downcasting to Dioxus' virtual elements
/// will never panic, but downcasting to native elements will fail if on an unsupported platform. We recommend avoiding
-/// publishing hooks and components that deply rely on control over elements using their native `ref`, preferring to
+/// publishing hooks and components that deeply rely on controlling elements using their native `ref`, preferring to
/// use their Dioxus Virtual Element counterpart instead.
-// This particular code *will panic* due to the unwrap. Try to avoid these types of patterns.
+/// This particular code *will panic* due to the unwrap. Try to avoid these types of patterns.
/// ---------------------------------
/// TODO: Get this to compile properly
/// let div_ref = use_node_ref(&cx);
diff --git a/reference/basics.rs b/reference/basics.rs
index ccd3bbdec..81a252cb7 100644
--- a/reference/basics.rs
+++ b/reference/basics.rs
@@ -29,7 +29,7 @@ static Greeting: FC = |(cx, props)| {
cx.render(rsx! {
div {
h1 { "Hello, {props.name}!" }
- p { "Welcome to the Diouxs framework" }
+ p { "Welcome to the Dioxus framework" }
br {}
{cx.children()}
}
diff --git a/reference/children.rs b/reference/children.rs
index a41d74ad6..0340e2dcb 100644
--- a/reference/children.rs
+++ b/reference/children.rs
@@ -1,14 +1,14 @@
//! Example: Children
//! -----------------
//!
-//! Dioxus supports passing children in from the parent. These children are allocated in the parent and just forced
-//! into the child. Components that pass in children may not be safely memoized, though in practice its rare for a
+//! Dioxus supports passing children in from the parent. These children are allocated in the parent and just passed
+//! into the child. Components that pass in children may not be safely memoized, though in practice it's rare for a
//! change in a parent to not result in a different set of children.
//!
//! In Dioxus, children can *only be a list*. Unlike React, you cannot pass in functions or arbitrary data. This is
-//! partially a limitaiton in having static types, but is rather intentional to encourage the use of attributes where
+//! partially a limitation of having static types, but is rather intentional to encourage the use of attributes where
//! arbitrary child data might normally be used. Check out the `function driven children` example for how to adopt your
-//! React pattern for Dioxus' semantics.
+//! React pattern to Dioxus' semantics.
//!
//! Dioxus will let you use the `children` method more than once - and it's semantically *okay* - but you'll likely
//! ruin your page if you try to clone elements in this way. Under the hood, Dioxus shares a "mounted ID" for each node,
diff --git a/reference/conditional_rendering.rs b/reference/conditional_rendering.rs
index 501fbb18f..b30869265 100644
--- a/reference/conditional_rendering.rs
+++ b/reference/conditional_rendering.rs
@@ -3,10 +3,10 @@
//!
//! This example shows how to hide or show elements using conditional rendering.
//!
-//! Often times you might want to display a different UI given some sort of condition. This is called "conditonal rendering".
+//! Oftentimes you might want to display a different UI given some sort of condition. This is called "conditional rendering".
//! In Dioxus, you can perform conditional rendering with optionals or matching.
//!
-//! The rsx! and html! macro accepts anything that is `IntoIter- `. Options and Results both implement
+//! The rsx! and html! macros accepts anything that is `IntoIter
- `. Options and Results both implement
//! IntoIter for impl VNode, so you can use option/result for conditional rendering.
use dioxus::prelude::*;
@@ -58,7 +58,7 @@ pub static Example1: FC = |(cx, props)| {
// or with optional chaining
{
props.should_show
- .then(|| rsx!(cx, div {"it is false!"}))
+ .then(|| rsx!(cx, div {"it is true!"}))
.unwrap_or_else(|| rsx!(cx, div {"it is false!"}))
}
}
diff --git a/reference/errorhandling.rs b/reference/errorhandling.rs
index e44c03bd3..dd34a5f3f 100644
--- a/reference/errorhandling.rs
+++ b/reference/errorhandling.rs
@@ -1,21 +1,21 @@
-//! Example: Errror Handling
+//! Example: Error Handling
//! ------------------------
//!
//! Error handling in Dioxus comes in a few flavors. Because Dioxus is a Rust project, Options and Results are obviously
-//! the go-to way of wrapping possibly-errored data. However, if a component fails to "unwrapping," everything will crash,
+//! the go-to way of wrapping possibly-errored data. However, if a component fails when "unwrapping," everything will crash,
//! the page will deadlock, and your users will be sad.
//!
//! So, obviously, you need to handle your errors.
//!
//! Fortunately, it's easy to avoid panics, even during quick prototyping.
//!
-//! Here's a few strategies:
-//! - Leverage the ability to return "None" and propogate None directly
-//! - Instead of propogating "None" manually, use the "?" syntax sugar
-//! - Covert Results into Options with .ok()
+//! Here are a few strategies:
+//! - Leverage the ability to return "None" and propagate None directly
+//! - Instead of propagating "None" manually, use the "?" syntax sugar
+//! - Convert Results into Options with .ok()
//! - Manually display a separate screen by matching on Options/Results
//!
-//! There *are* plans to add helpful screens for when apps completely panic in WASM. However, you should really try to
+//! There *are* plans to add helpful screens for when apps completely panic in Wasm. However, you should really try to
//! avoid panicking.
use dioxus::prelude::*;
fn main() {}
@@ -42,7 +42,7 @@ static App1: FC<()> = |(cx, props)| {
/// However, it _does_ make the component go blank, which might not be desirable.
///
/// This type of error handling is good when you have "selectors" that produce Some/None based on some state that's
-/// already controlled for higher in the tree. IE displaying a "Username" in a component that should only be shown if
+/// already controlled higher in the tree. i.e. displaying a "Username" in a component that should only be shown if
/// a user is logged in.
///
/// Dioxus will throw an error in the console if the None-path is ever taken.
@@ -59,8 +59,8 @@ static App3: FC<()> = |(cx, props)| match get_data() {
None => cx.render(rsx!( div { "Failed to load data :(" } )),
};
-/// For errors that return results, it's possible short-circuit the match-based error handling with `.ok()` which converts
-/// a Result into an Option and lets you
+/// For errors that return results, it's possible to short-circuit the match-based error handling with `.ok()` which converts
+/// a Result into an Option and lets you abort rendering by early-returning `None`
static App4: FC<()> = |(cx, props)| {
let data = get_data_err().ok()?;
cx.render(rsx!( div { "{data}" } ))
@@ -68,7 +68,7 @@ static App4: FC<()> = |(cx, props)| {
/// This is great error handling since it displays a failure state... with context!
///
-/// Hopefully you never need to disply a screen like this. It's rather bad taste
+/// Hopefully you'll never need to display a screen like this. It's rather bad taste
static App5: FC<()> = |(cx, props)| match get_data_err() {
Ok(data) => cx.render(rsx!( div { "{data}" } )),
Err(c) => cx.render(rsx!( div { "Failed to load data: {c}" } )),
diff --git a/reference/inline_styles.rs b/reference/inline_styles.rs
index 76aa8c267..2161812ff 100644
--- a/reference/inline_styles.rs
+++ b/reference/inline_styles.rs
@@ -3,7 +3,7 @@
//!
//! This example shows how to use inline styles in Dioxus components.
//!
-//! Inline styles function very similar to regular attributes, just grouped together in "style".
+//! Inline styles function very similarly to regular attributes, just grouped together in "style".
//!
//! Inline styles in Dioxus are more performant than React since we're able to cache attributes and compare by pointers.
//! However, it's still not as performant as cascaded styles. Use with care.
@@ -26,7 +26,7 @@ pub static Example: FC<()> = |(cx, props)| {
})
};
-// .... technically the rsx! macro is slightly broken at the moment and alows styles not wrapped in style {}
+// .... technically the rsx! macro is slightly broken at the moment and allows styles not wrapped in style {}
// I haven't noticed any name collisions yet, and am tentatively leaving this behavior in..
// Don't rely on it.
static Example2: FC<()> = |(cx, props)| {
diff --git a/reference/iterators.rs b/reference/iterators.rs
index f31a7bbc8..cd216401e 100644
--- a/reference/iterators.rs
+++ b/reference/iterators.rs
@@ -8,7 +8,7 @@
//!
//! This also makes it easy to write "pull"-style iterators that don't have a known size.
//!
-//! However, when the size of an iterator needs to be know for display purposes, collecting is fine.
+//! However, when the size of an iterator needs to be known for display purposes, collecting is fine.
use dioxus::prelude::*;
diff --git a/reference/listener.rs b/reference/listener.rs
index b12a14885..3cd13edfb 100644
--- a/reference/listener.rs
+++ b/reference/listener.rs
@@ -11,7 +11,7 @@ pub static Example: FC<()> = |(cx, props)| {
cx.render(rsx! {
ButtonList {}
NonUpdatingEvents {}
- DisablePropogation {}
+ DisablePropagation {}
})
};
@@ -42,13 +42,13 @@ static NonUpdatingEvents: FC<()> = |(cx, props)| {
})
};
-static DisablePropogation: FC<()> = |(cx, props)| {
+static DisablePropagation: FC<()> = |(cx, props)| {
rsx!(cx,
div {
- onclick: move |_| log::info!("event propogated to the div!")
+ onclick: move |_| log::info!("event propagated to the div!")
button {
onclick: move |evt| {
- log::info!("Button will allow propogation");
+ log::info!("Button will allow propagation");
}
}
}
diff --git a/reference/spreadpattern.rs b/reference/spreadpattern.rs
index b6fbb380f..56bde5aed 100644
--- a/reference/spreadpattern.rs
+++ b/reference/spreadpattern.rs
@@ -1,10 +1,10 @@
//! Example: Spread pattern for Components
//! --------------------------------------
//!
-//! Dioxus supports the "spread" pattern for manually building a components properties. This is useful when props
+//! Dioxus supports the "spread" pattern for manually building a component's properties. This is useful when props
//! are passed down from a parent, or it's more ergonomic to construct props from outside the rsx! macro.
//!
-//! To use the spread pattern, simply pass ".." followed by a Rust epxression. This pattern also supports overriding
+//! To use the spread pattern, simply pass ".." followed by a Rust expression. This pattern also supports overriding
//! values, using the manual props as the base and then modifying fields specified with non-spread attributes.
use dioxus::prelude::*;
diff --git a/reference/suspense.rs b/reference/suspense.rs
index 847092dc7..2a89e97ee 100644
--- a/reference/suspense.rs
+++ b/reference/suspense.rs
@@ -2,7 +2,7 @@
//! -----------------
//! This example demonstrates how the use_suspense hook can be used to load and render asynchronous data. Suspense enables
//! components to wait on futures to complete before rendering the result into VNodes. These VNodes are immediately
-//! available in a suspended" fashion and will automatically propogate to the UI when the future completes.
+//! available in a suspended" fashion and will automatically propagate to the UI when the future completes.
//!
//! Currently, suspense futures are non-restartable. In the future, we'll provide more granular control of how to start,
//! stop, and reset these futures.
diff --git a/src/lib.rs b/src/lib.rs
index c2871b5ec..1bdba09b6 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -109,7 +109,7 @@
//! cx.use_hook(
//! // Initializer stores a value
//! |hook_idx| String::new("stored_data"),
-//!
+//!
//! // Runner returns the hook value every time the component is rendered
//! |hook| &*hook,
//!
@@ -153,7 +153,7 @@
//! ```
//! use dioxus::prelude::*;
//! fn main() {
-//! diouxs::web::launch(Example);
+//! dioxus::web::launch(Example);
//! }
//!
//! pub pub static Example: FC<()> = |(cx, props)|{