Fix various typos and grammar nits

I also removed all trailing whitespace from lines since I have Emacs
configured to highlight this.

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/13-subtrees.md

@@ -6,7 +6,7 @@ For a VirtualDom that has a root tree with two subtrees, the edits follow a patt
 
 Root
 -> Tree 1
--> Tree 2 
+-> Tree 2
 -> Original root tree
 
 - Root edits
@@ -39,7 +39,7 @@ fn Window() -> DomTree {
         onassign: move |e| {
             // create window
         }
-        children() 
+        children()
     }
 }
 

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