Merge pull request #145 from autarch/autarch/typo-and-doc-fixes

Fix various typos and grammar nits

README.md

@@ -84,7 +84,7 @@ If you know React, then you already know Dioxus.
 - Comprehensive inline documentation - hover and guides for all HTML elements, listeners, and events.
 - Extremely memory efficient - 0 global allocations for steady-state components.
 - Multi-channel asynchronous scheduler for first-class async support.
-- And more! Read the [full release post here](https://dioxuslabs.com/blog/introducing-dioxus/).
+- And more! Read the [full release post](https://dioxuslabs.com/blog/introducing-dioxus/).
 
 
 ### Examples
@@ -141,7 +141,7 @@ By using Rust, we gain:
 
 Specifically, Dioxus provides us many other assurances:
 
-- Proper use of immutable datastructures
+- Proper use of immutable data structures
 - Guaranteed error handling (so you can sleep easy at night not worrying about `cannot read property of undefined`)
 - Native performance on mobile
 - Direct access to system IO
@@ -154,13 +154,13 @@ You shouldn't use Dioxus if:
 - You don't like the React Hooks approach to frontend
 - You need a no-std renderer
 - You want to support browsers where Wasm or asm.js are not supported.
-- You need a Send+Sync UI solution (Dioxus is not currently ThreadSafe)
+- You need a Send+Sync UI solution (Dioxus is not currently thread-safe)
 
 ### Comparison with other Rust UI frameworks
 Dioxus primarily emphasizes **developer experience** and **familiarity with React principles**.
 
 - [Yew](https://github.com/yewstack/yew): prefers the elm pattern instead of React-hooks, no borrowed props, supports SSR (no hydration).
-- [Percy](https://github.com/chinedufn/percy): Supports SSR but less emphasis on state management and event handling.
+- [Percy](https://github.com/chinedufn/percy): Supports SSR but with less emphasis on state management and event handling.
 - [Sycamore](https://github.com/sycamore-rs/sycamore): VDOM-less using fine-grained reactivity, but lacking in ergonomics.
 - [Dominator](https://github.com/Pauan/rust-dominator): Signal-based zero-cost alternative, less emphasis on community and docs.
 

docs/guide/src/README.md

@@ -22,7 +22,7 @@ In general, Dioxus and React share many functional similarities. If this guide i
 
 ## Multiplatform
 
-Dioxus is a *portable* toolkit, meaning the Core implementation can run anywhere with no platform-dependent linking. Unlike many other Rust frontend toolkits, Dioxus is not intrinsically linked to Web-Sys. In fact, every element and event listener can be swapped out at compile time. By default, Dioxus ships with the `Html` feature enabled which can be disabled depending on your target renderer.
+Dioxus is a *portable* toolkit, meaning the Core implementation can run anywhere with no platform-dependent linking. Unlike many other Rust frontend toolkits, Dioxus is not intrinsically linked to Web-Sys. In fact, every element and event listener can be swapped out at compile time. By default, Dioxus ships with the `html` feature enabled, but this can be disabled depending on your target renderer.
 
 Right now, we have several 1st-party renderers:
 - WebSys (for WASM)
@@ -33,8 +33,7 @@ Right now, we have several 1st-party renderers:
 
 ### Web Support
 ---
-
-The Web is the most-supported target platform for Dioxus. To run on the Web, your app must be compiled to WebAssembly and depend on the `dioxus` crate with the `web` feature enabled. Because of the Wasm limitation, not every crate will work with your web-apps, so you'll need to make sure that your crates work without native system calls (timers, IO, etc).
+The Web is the best-supported target platform for Dioxus. To run on the Web, your app must be compiled to WebAssembly and depend on the `dioxus` crate with the `web` feature enabled. Because of the limitations of Wasm  not every crate will work with your web-apps, so you'll need to make sure that your crates work without native system calls (timers, IO, etc).
 
 Because the web is a fairly mature platform, we expect there to be very little API churn for web-based features.
 
@@ -45,6 +44,7 @@ Examples:
 - [ECommerce](https://github.com/DioxusLabs/example-projects/tree/master/ecommerce-site)
 
 [![TodoMVC example](https://github.com/DioxusLabs/example-projects/raw/master/todomvc/example.png)](https://github.com/DioxusLabs/example-projects/blob/master/todomvc)
+
 ### SSR Support
 ---
 Dioxus supports server-side rendering!

docs/guide/src/SUMMARY.md

@@ -1,7 +1,7 @@
 # Summary
 
 - [Introduction](README.md)
-- [Getting Setup](setup.md)
+- [Getting Set Up](setup.md)
 - [Hello, World!](hello_world.md)
 - [Describing the UI](elements/index.md)
   - [Intro to Elements](elements/vnodes.md)

docs/guide/src/advanced-guides/00-index.md

@@ -1,6 +1,6 @@
 # Core Topics
 
-In this chapter, we'll cover some core topics on how Dioxus works and how to best leverage the features to build a beautiful, reactive app.
+In this chapter, we'll cover some core topics about how Dioxus works and how to best leverage the features to build a beautiful, reactive app.
 
 At a very high level, Dioxus is simply a Rust framework for _declaring_ user interfaces and _reacting_ to changes.
 

docs/guide/src/advanced-guides/10-concurrent-mode.md

@@ -33,9 +33,9 @@ async fetch_name() -> String {
 
 This component will only schedule its render once the fetch is complete. However, we _don't_ recommend using async/await directly in your components.
 
-Async is a notoriously challenging yet rewarding tool for efficient tools. If not careful, locking and unlocking shared aspects of the component's context can lead to data races and panics. If a shared resource is locked while the component is awaiting, then other components can be locked or panic when trying to access the same resource. These rules are especially important when references to shared global state are accessed using the context object's lifetime. If mutable references to data captured immutably by the context are taken, then the component will panic, and cause confusion.
+Async is a notoriously challenging yet rewarding tool for efficient tools. If not careful, locking and unlocking shared aspects of the component's context can lead to data races and panics. If a shared resource is locked while the component is awaiting, then other components can be locked or panic when trying to access the same resource. These rules are especially important when references to shared global state are accessed using the context object's lifetime. If mutable references to data captured immutably by the context are taken, then the component will panic, causing confusion.
 
-Instead, we suggest using hooks and future combinators that can safely utilize the safe guards of the component's Context when interacting with async tasks.
+Instead, we suggest using hooks and future combinators that can safely utilize the safeguards of the component's Context when interacting with async tasks.
 
 As part of our Dioxus hooks crate, we provide a data loader hook which pauses a component until its async dependencies are ready. This caches requests, reruns the fetch if dependencies have changed, and provides the option to render something else while the component is loading.
 

docs/guide/src/advanced-guides/11-arena-memo.md

@@ -2,13 +2,13 @@
 
 Dioxus differs slightly from other UI virtual doms in some subtle ways due to its memory allocator.
 
-One important aspect to understand is how props are passed down from parent components to children. All "components" (custom user-made UI elements) are tightly allocated together in an arena. However, because props and hooks are generically typed, they are casted to any and allocated on the heap - not in the arena with the components.
+One important aspect to understand is how props are passed down from parent components to children. All "components" (custom user-made UI elements) are tightly allocated together in an arena. However, because props and hooks are generically typed, they are casted to `Any` and allocated on the heap - not in the arena with the components.
 
 With this system, we try to be more efficient when leaving the component arena and entering the heap. By default, props are memoized between renders using COW and context. This makes props comparisons fast - done via ptr comparisons on the cow pointer. Because memoization is done by default, parent re-renders will _not_ cascade to children if the child's props did not change.
 
 https://dmitripavlutin.com/use-react-memo-wisely/
 
-This behavior is defined as an implicit attribute to user components. When in React land you might wrap a component is `react.memo`, Dioxus components are automatically memoized via an implicit attribute. You can manually configure this behavior on any component with "nomemo" to disable memoization.
+This behavior is defined as an attribute implicit to user components. When in React land you might wrap a component with `react.memo`, Dioxus components are automatically memoized via an implicit attribute. You can manually configure this behavior on any component with "nomemo" to disable memoization.
 
 ```rust
 fn test() -> DomTree {
@@ -40,7 +40,7 @@ fn test_component(cx: Scope, name: String) -> Element {
 
 "This is different than React, why differ?".
 
-Take a component likes this:
+Take a component like this:
 
 ```rust
 fn test(cx: Scope) -> DomTree {
@@ -55,4 +55,4 @@ fn test(cx: Scope) -> DomTree {
 }
 ```
 
-While the contents of the destructured bundle might change, not every child component will need to be re-rendered.
+While the contents of the destructured bundle might change, not every child component will need to be re-rendered every time the context changes.

docs/guide/src/advanced-guides/12-signals.md

@@ -1,6 +1,6 @@
 # Signals: Skipping the Diff
 
-In most cases, the traditional VirtualDOM diffing pattern is plenty fast. Dioxus will compare trees of VNodes, find the differences, and then update the Renderer's DOM with the updates. However, this can generate a lot of overhead for certain types of components. In apps where reducing visual latency is a top priority, you can opt into the `Signals` api to entirely disable diffing of hot-path components. Dioxus will then automatically construct a state machine for your component, making updates nearly instant.
+In most cases, the traditional VirtualDOM diffing pattern is plenty fast. Dioxus will compare trees of VNodes, find the differences, and then update the Renderer's DOM with the diffs. However, this can generate a lot of overhead for certain types of components. In apps where reducing visual latency is a top priority, you can opt into the `Signals` api to entirely disable diffing of hot-path components. Dioxus will then automatically construct a state machine for your component, making updates nearly instant.
 
 Signals build on the same infrastructure that powers asynchronous rendering where in-tree values can be updated outside of the render phase. In async rendering, a future is used as the signal source. With the raw signal API, any value can be used as a signal source.
 
@@ -69,7 +69,7 @@ fn Calculator(cx: Scope) -> DomTree {
 }
 ```
 
-Do you notice how we can use built-in operations on signals? Under the hood, we actually create a new derived signal that depends on `a` and `b`. Whenever `a` or `b` update, then `c` will update. If we need to create a new derived signal that's more complex that a basic operation (`std::ops`) we can either chain signals together or combine them:
+Do you notice how we can use built-in operations on signals? Under the hood, we actually create a new derived signal that depends on `a` and `b`. Whenever `a` or `b` update, then `c` will update. If we need to create a new derived signal that's more complex than a basic operation (`std::ops`) we can either chain signals together or combine them:
 
 ```rust
 let mut a = use_signal(&cx, || 0);
@@ -88,7 +88,7 @@ let mut a = use_signal(&cx, || 0);
 let c = *a + *b;
 ```
 
-Calling `deref` or `derefmut` is actually more complex than it seems. When a value is derefed, you're essentially telling Dioxus that _this_ element _needs_ to be subscribed to the signal. If a signal is derefed outside of an element, the entire component will be subscribed and the advantage of skipping diffing will be lost. Dioxus will throw an error in the console when this happens to tell you that you're using signals wrong, but your component will continue to work.
+Calling `deref` or `deref_mut` is actually more complex than it seems. When a value is derefed, you're essentially telling Dioxus that _this_ element _needs_ to be subscribed to the signal. If a signal is derefed outside of an element, the entire component will be subscribed and the advantage of skipping diffing will be lost. Dioxus will throw an error in the console when this happens to tell you that you're using signals wrong, but your component will continue to work.
 
 ## Global Signals
 
@@ -128,7 +128,7 @@ Sometimes you want to use a collection of items. With Signals, you can bypass di
 
 By default, Dioxus is limited when you use iter/map. With the `For` component, you can provide an iterator and a function for the iterator to map to.
 
-Dioxus automatically understands how to use your signals when mixed with iterators through Deref/DerefMut. This lets you efficiently map collections while avoiding the re-rendering of lists. In essence, signals act as a hint to Dioxus on how to avoid un-necessary checks and renders, making your app faster.
+Dioxus automatically understands how to use your signals when mixed with iterators through `Deref`/`DerefMut`. This lets you efficiently map collections while avoiding the re-rendering of lists. In essence, signals act as a hint to Dioxus on how to avoid un-necessary checks and renders, making your app faster.
 
 ```rust
 const DICT: AtomFamily<String, String> = |_| {};

docs/guide/src/advanced-guides/custom-renderer.md

@@ -20,7 +20,7 @@ For reference, check out the WebSys renderer as a starting point for your custom
 
 ## Trait implementation and DomEdits
 
-The current `RealDom` trait lives in `dioxus_core/diff`. A version of it is provided here (but might not be up-to-date):
+The current `RealDom` trait lives in `dioxus-core/diff`. A version of it is provided here (but might not be up-to-date):
 
 ```rust
 pub trait RealDom<'a> {

docs/guide/src/elements/component_children.md

@@ -9,7 +9,7 @@ In this chapter, you'll learn about:
 
 ## The use case
 
-Let's say you're building a user interface and want to make some part of it clickable to another website. You would normally start with the HTML `<a>` tag, like so:
+Let's say you're building a user interface and want to make some part of it a clickable link to another website. You would normally start with the HTML `<a>` tag, like so:
 
 ```rust
 rsx!(
@@ -98,7 +98,7 @@ struct ClickableProps<'a> {
     children: Element<'a>
 }
 
-fn clickable(cx: Scope<ClickableProps>) -> Element {
+fn Clickable(cx: Scope<ClickableProps>) -> Element {
     cx.render(rsx!(
         a {
             href: "{cx.props.href}",

docs/guide/src/elements/components.md

@@ -39,7 +39,7 @@ struct PostData {
 }
 ```
 
-If we look at the layout of the component, we notice quite a few buttons and functionality:
+If we look at the layout of the component, we notice quite a few buttons and pieces of functionality:
 
 - Upvote/Downvote
 - View comments
@@ -53,7 +53,7 @@ If we look at the layout of the component, we notice quite a few buttons and fun
 - View article
 - Visit user
 
-If we included all this functionality in one `rsx!` call, it would be huge! Instead, let's break the post down into some core pieces:
+If we included all this functionality in one `rsx!` call it would be huge! Instead, let's break the post down into some core pieces:
 
 ![Post as Component](../images/reddit_post_components.png)
 
@@ -133,7 +133,7 @@ fn VoteButton(cx: Scope<VoteButtonProps>) -> Element {
 
 ## Borrowing
 
-You can avoid clones using borrowed component syntax. For example, let's say we passed the `TitleCard` title as an `&str` instead of `String`. In JavaScript, the string would be copied by reference - none of the contents would be copied, but rather the reference to the string's contents are copied. In Rust, this would be similar to calling `clone` on `Rc<str>`.
+You can avoid clones by using borrowed component syntax. For example, let's say we passed the `TitleCard` title as an `&str` instead of `String`. In JavaScript, the string would be copied by reference - none of the contents would be copied, but rather the reference to the string's contents are copied. In Rust, this would be similar to calling `clone` on `Rc<str>`.
 
 Because we're working in Rust, we can choose to either use `Rc<str>`, clone `Title` on every re-render of `Post`, or simply borrow it. In most cases, you'll just want to let `Title` be cloned.
 

docs/guide/src/elements/conditional_rendering.md

@@ -27,7 +27,7 @@ Now that we have a "logged_in" flag accessible in our props, we can render two d
 
 ```rust
 fn App(cx: Scope<AppProps>) -> Element {
-    if props.logged_in {
+    if cx.props.logged_in {
         cx.render(rsx!{
             DashboardScreen {}
         })
@@ -39,7 +39,7 @@ fn App(cx: Scope<AppProps>) -> Element {
 }
 ```
 
-When the user is logged in, then this component will return the DashboardScreen. Else, the component will render the LoginScreen.
+When the user is logged in, then this component will return the DashboardScreen. If they're not logged in, the component will render the LoginScreen.
 
 ## Using match statements
 

docs/guide/src/elements/exporting_components.md

@@ -107,7 +107,7 @@ fn App(Scope) -> Element {
 }
 ```
 
-If you tried to build this app right now, you'll get an error message saying that `Post is private, trying changing it to public`. This is because we haven't properly exported our component! To fix this, we need to make sure both the Props and Component are declared as "public":
+If you tried to build this app right now, you'll get an error message saying that `Post is private, try changing it to public`. This is because we haven't properly exported our component! To fix this, we need to make sure both the Props and Component are declared as "public":
 
 ```rust
 // src/post/mod.rs

docs/guide/src/elements/index.md

@@ -1,6 +1,6 @@
 # Core Topics
 
-In this chapter, we'll cover some core topics on how Dioxus works and how to best leverage the features to build a beautiful, reactive app.
+In this chapter, we'll cover some core topics about how Dioxus works and how to best leverage the features to build a beautiful, reactive app.
 
 At a very high level, Dioxus is simply a Rust framework for _declaring_ user interfaces and _reacting_ to changes.
 

docs/guide/src/hello_world.md

@@ -31,7 +31,7 @@ $ tree
 
 We are greeted with a pre-initialized git repository, our code folder (`src`) and our project file (`Cargo.toml`).
 
-Our `src` folder holds our code. Our `main.rs` file holds our `fn main` which will be executed when our app is ran.
+Our `src` folder holds our code. Our `main.rs` file holds our `fn main` which will be executed when our app is run.
 
 ```shell
 $ more src/main.rs

docs/guide/src/interactivity/hooks.md

@@ -21,7 +21,7 @@ Typically, immediate-mode GUIs are simpler to write but can slow down as more fe
 
 Many GUIs today are written in *Retained mode* - your code changes the data of the user interface but the renderer is responsible for actually drawing to the screen. In these cases, our GUI's state sticks around as the UI is rendered. To help accommodate retained mode GUIs, like the web browser, Dioxus provides a mechanism to keep state around.
 
-> Note: Even though hooks are accessible, you should still prefer to one-way data flow and encapsulation. Your UI code should be as predictable as possible. Dioxus is plenty fast, even for the largest apps.
+> Note: Even though hooks are accessible, you should still prefer one-way data flow and encapsulation. Your UI code should be as predictable as possible. Dioxus is plenty fast, even for the largest apps.
 
 ## Mechanics of Hooks
 In order to have state stick around between renders, Dioxus provides the `hook` through the `use_hook` API. This gives us a mutable reference to data returned from the initialization function.

docs/guide/src/interactivity/index.md

@@ -32,7 +32,7 @@ fn main() {
 }
 ```
 
-When Dioxus renders your app, it will pass an immutable reference of `PostProps` to your `Post` component. Here, you can pass the state down into children.
+When Dioxus renders your app, it will pass an immutable reference to `PostProps` into your `Post` component. Here, you can pass the state down into children.
 
 ```rust
 fn App(cx: Scope<PostProps>) -> Element {

docs/guide/src/setup.md

@@ -1,6 +1,6 @@
 # Overview
 
-In this chapter, we're going to get "set up" with a small desktop application.
+In this chapter, we're going to get set up with a small desktop application.
 
 We'll learn about:
 - Installing the Rust programming language
@@ -15,7 +15,6 @@ For platform-specific guides, check out the [Platform Specific Guides](../platfo
 Dioxus requires a few main things to get up and running:
 
 - The [Rust compiler](https://www.rust-lang.org) and associated build tooling
-
 - An editor of your choice, ideally configured with the [Rust-Analyzer LSP plugin](https://rust-analyzer.github.io)
 
 Dioxus integrates very well with the Rust-Analyzer IDE plugin which will provide appropriate syntax highlighting, code navigation, folding, and more.
@@ -24,7 +23,7 @@ Dioxus integrates very well with the Rust-Analyzer IDE plugin which will provide
 
 Head over to [https://rust-lang.org](http://rust-lang.org) and install the Rust compiler.
 
-Once installed, make sure to  install wasm32-unknown-unknown as a target if you're planning on deploying your app to the web.
+Once installed, make sure to install wasm32-unknown-unknown as a target if you're planning on deploying your app to the web.
 
 ```
 rustup target add wasm32-unknown-unknown
@@ -32,7 +31,7 @@ rustup target add wasm32-unknown-unknown
 
 ### Platform-Specific Dependencies
 
-If you are running a modern, mainstream operating system, you should need no additional setup to build WebView-based Desktop apps. However, if you are running an older version of Windows or a flavor of linux with no default web rendering engine, you might need to install some additional dependencies.
+If you are running a modern, mainstream operating system, you should need no additional setup to build WebView-based Desktop apps. However, if you are running an older version of Windows or a flavor of Linux with no default web rendering engine, you might need to install some additional dependencies.
 
 For windows users: download the [bootstrapper for Webview2 from Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/webview2/)
 
@@ -49,13 +48,13 @@ When distributing onto older Windows platforms or less-mainstream
 
 ### Dioxus-CLI for dev server, bundling, etc.
 
-We also recommend installing the Dioxus CLI. The Dioxus CLI automates building and packaging for various targets and integrates with simulators, development servers, and app deployment. To install the CLI, you'll need cargo (should be automatically installed with Rust):
+We also recommend installing the Dioxus CLI. The Dioxus CLI automates building and packaging for various targets and integrates with simulators, development servers, and app deployment. To install the CLI, you'll need cargo (which should be automatically installed with Rust):
 
 ```
 $ cargo install dioxus-cli
 ```
 
-You can update the dioxus-cli at any time with:
+You can update dioxus-cli at any time with:
 
 ```
 $ cargo install --force dioxus-cli

packages/core/README.md

@@ -94,5 +94,5 @@ Dioxus deals with arenas, lifetimes, asynchronous tasks, custom allocators, pinn
 
 If you don't want to use a crate that uses unsafe, then this crate is not for you.
 
-However, we are always interested in decreasing the scope of the core VirtualDom to make it easier to review. We'd be happy to welcome PRs that can eliminate unsafe code while still upholding the numerous variants required to execute certain features.
+However, we are always interested in decreasing the scope of the core VirtualDom to make it easier to review. We'd be happy to welcome PRs that can eliminate unsafe code while still upholding the numerous invariants required to execute certain features.
 

packages/core/src/events.rs

@@ -18,7 +18,7 @@ impl BubbleState {
     }
 }
 
-/// User Events are events that are shuttled from the renderer into the VirtualDom trhough the scheduler channel.
+/// User Events are events that are shuttled from the renderer into the VirtualDom through the scheduler channel.
 ///
 /// These events will be passed to the appropriate Element given by `mounted_dom_id` and then bubbled up through the tree
 /// where each listener is checked and fired if the event name matches.

packages/core/src/nodes.rs

@@ -21,7 +21,7 @@ use std::{
 /// - the `rsx!` macro
 /// - the [`NodeFactory`] API
 pub enum VNode<'src> {
-    /// Text VNodes simply bump-allocated (or static) string slices
+    /// Text VNodes are simply bump-allocated (or static) string slices
     ///
     /// # Example
     ///
@@ -399,7 +399,7 @@ impl<P> AnyProps for VComponentProps<P> {
     }
 
     // Safety:
-    // this will downcat the other ptr as our swallowed type!
+    // this will downcast the other ptr as our swallowed type!
     // you *must* make this check *before* calling this method
     // if your functions are not the same, then you will downcast a pointer into a different type (UB)
     unsafe fn memoize(&self, other: &dyn AnyProps) -> bool {

packages/core/src/scopes.rs

@@ -70,7 +70,7 @@ impl ScopeArena {
     }
 
     /// Safety:
-    /// - Obtaining a mutable refernece to any Scope is unsafe
+    /// - Obtaining a mutable reference to any Scope is unsafe
     /// - Scopes use interior mutability when sharing data into components
     pub(crate) fn get_scope(&self, id: ScopeId) -> Option<&ScopeState> {
         unsafe { self.scopes.borrow().get(&id).map(|f| &**f) }
@@ -101,7 +101,7 @@ impl ScopeArena {
         let parent_scope = parent_scope.map(|f| self.get_scope_raw(f)).flatten();
 
         /*
-        This scopearena aggressively reuse old scopes when possible.
+        This scopearena aggressively reuses old scopes when possible.
         We try to minimize the new allocations for props/arenas.
 
         However, this will probably lead to some sort of fragmentation.

packages/core/src/util.rs

@@ -3,7 +3,7 @@ use crate::innerlude::*;
 pub struct ElementIdIterator<'a> {
     vdom: &'a VirtualDom,
 
-    // Heuristcally we should never bleed into 5 completely nested fragments/components
+    // Heuristically we should never bleed into 5 completely nested fragments/components
     // Smallvec lets us stack allocate our little stack machine so the vast majority of cases are sane
     stack: smallvec::SmallVec<[(u16, &'a VNode<'a>); 5]>,
 }

packages/core/src/virtual_dom.rs

@@ -9,7 +9,7 @@ use fxhash::FxHashSet;
 use indexmap::IndexSet;
 use std::{collections::VecDeque, iter::FromIterator, task::Poll};
 
-/// A virtual node s ystem that progresses user events and diffs UI trees.
+/// A virtual node system that progresses user events and diffs UI trees.
 ///
 ///
 /// ## Guide
@@ -233,7 +233,7 @@ impl VirtualDom {
 
     /// Get the [`Scope`] for the root component.
     ///
-    /// This is useful for traversing the tree from the root for heuristics or alternsative renderers that use Dioxus
+    /// This is useful for traversing the tree from the root for heuristics or alternative renderers that use Dioxus
     /// directly.
     ///
     /// This method is equivalent to calling `get_scope(ScopeId(0))`

packages/hooks/src/usestate/handle.rs

@@ -66,7 +66,7 @@ impl<'a, T: 'static> UseState<'a, T> {
         })
     }
 
-    pub fn wtih(&self, f: impl FnOnce(&mut T)) {
+    pub fn with(&self, f: impl FnOnce(&mut T)) {
         let mut val = self.0.wip.borrow_mut();
 
         if let Some(inner) = val.as_mut() {

packages/router/README.md

@@ -16,7 +16,7 @@ fn app() {
 
 Then, in your route, you can choose to parse the Route any way you want through `use_route`.
 ```rust
-let id: usize = use_route(&cx).path("id")?;
+let id: usize = use_route(&cx).segment("id")?;
 
 let state: CustomState = use_route(&cx).parse()?;
 ```

packages/router/src/components/link.rs

@@ -11,7 +11,7 @@ pub struct LinkProps<'a> {
 
     /// The url that gets pushed to the history stack
     ///
-    /// You can either put it your own inline method or just autoderive the route using `derive(Routable)`
+    /// You can either put in your own inline method or just autoderive the route using `derive(Routable)`
     ///
     /// ```rust, ignore
     ///

src/lib.rs

@@ -7,7 +7,7 @@
 //!
 //! # Resources
 //!
-//! This overview is provides a brief introduction to Dioxus. For a more in-depth guide, make sure to check out:
+//! This overview provides a brief introduction to Dioxus. For a more in-depth guide, make sure to check out:
 //! - [Getting Started](https://dioxuslabs.com/getting-started)
 //! - [Book](https://dioxuslabs.com/book)
 //! - [Reference](https://dioxuslabs.com/reference)
@@ -53,7 +53,7 @@
 //!
 //! ## Elements & your first component
 //!
-//! To assemble UI trees with Diouxs, you need to use the `render` function on
+//! To assemble UI trees with Dioxus, you need to use the `render` function on
 //! something called `LazyNodes`. To produce `LazyNodes`, you can use the `rsx!`
 //! macro or the NodeFactory API. For the most part, you want to use the `rsx!`
 //! macro.
@@ -74,7 +74,7 @@
 //! )
 //! ```
 //!
-//! The rsx macro accepts attributes in "struct form" and then will parse the rest
+//! The `rsx!` macro accepts attributes in "struct form" and will parse the rest
 //! of the body as child elements and rust expressions. Any rust expression that
 //! implements `IntoIterator<Item = impl IntoVNode>` will be parsed as a child.
 //!
@@ -87,7 +87,7 @@
 //!
 //! ```
 //!
-//! Used within components, the rsx! macro must be rendered into an `Element` with
+//! Used within components, the `rsx!` macro must be rendered into an `Element` with
 //! the `render` function on Scope.
 //!
 //! If we want to omit the boilerplate of `cx.render`, we can simply pass in
@@ -104,7 +104,7 @@
 //! }
 //! ```
 //!
-//! Putting everything together, we can write a simple component that a list of
+//! Putting everything together, we can write a simple component that renders a list of
 //! elements:
 //!
 //! ```rust, ignore
@@ -146,8 +146,8 @@
 //! }
 //! ```
 //!
-//! Our `Header` component takes in a `title` and a `color` property, which we
-//! delcare on an explicit `HeaderProps` struct.
+//! Our `Header` component takes a `title` and a `color` property, which we
+//! declare on an explicit `HeaderProps` struct.
 //!
 //! ```rust, ignore
 //! // The `Props` derive macro lets us add additional functionality to how props are interpreted.
@@ -203,8 +203,8 @@
 //! }
 //! ```
 //!
-//! Components that beging with an uppercase letter may be called through
-//! traditional curly-brace syntax like so:
+//! Components that begin with an uppercase letter may be called with
+//! the traditional (for React) curly-brace syntax like so:
 //!
 //! ```rust, ignore
 //! rsx!(
@@ -224,7 +224,7 @@
 //! ## Hooks
 //!
 //! While components are reusable forms of UI elements, hooks are reusable forms
-//! of logic. Hooks provide us a way of retrieving state from `Scope` and using
+//! of logic. Hooks provide us a way of retrieving state from the `Scope` and using
 //! it to render UI elements.
 //!
 //! By convention, all hooks are functions that should start with `use_`. We can
@@ -245,7 +245,7 @@
 //! - Functions with "use_" should not be called in loops or conditionals
 //!
 //! In a sense, hooks let us add a field of state to our component without declaring
-//! an explicit struct. However, this means we need to "load" the struct in the right
+//! an explicit state struct. However, this means we need to "load" the struct in the right
 //! order. If that order is wrong, then the hook will pick the wrong state and panic.
 //!
 //! Most hooks you'll write are simply composition of other hooks:
@@ -257,7 +257,7 @@
 //! }
 //! ```
 //!
-//! To create entirely new foundational hooks, we can use the `use_hook` method on ScopeState.
+//! To create entirely new foundational hooks, we can use the `use_hook` method on `ScopeState`.
 //!
 //! ```rust, ignore
 //! fn use_mut_string(cx: &ScopeState) -> &mut String {
@@ -316,9 +316,9 @@
 //!
 //! Alternatives to Dioxus include:
 //! - Yew: supports function components and web, but no SSR, borrowed data, or bump allocation. Rather slow at times.
-//! - Percy: supports function components, web, ssr, but lacks in state management
+//! - Percy: supports function components, web, ssr, but lacks state management
 //! - Sycamore: supports function components, web, ssr, but closer to SolidJS than React
-//! - MoonZoom/Seed: opionated in the Elm model (message, update) - no hooks
+//! - MoonZoom/Seed: opinionated frameworks based on the Elm model (message, update) - no hooks
 //!
 //! We've put a lot of work into making Dioxus ergonomic and *familiar*.
 //! Our target audience is TypeSrcipt developers looking to switch to Rust for the web - so we need to be comparabale to React.