Various typos/grammar/rewording

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<NoKeysProps> = |(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<MisuedHooksProps> = |(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);

reference/basics.rs

@@ -29,7 +29,7 @@ static Greeting: FC<GreetingProps> = |(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()}
         }

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,

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<Item = impl IntoVnode>`. Options and Results both implement
+//! The rsx! and html! macros accepts anything that is `IntoIter<Item = impl IntoVnode>`. 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<MyProps1> = |(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!"}))
             }
         }

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<T, V> into an Option<T> 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<T, V> into an Option<T> 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}" } )),

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)| {

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::*;
 

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");
                 }
             }
         }

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::*;

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.