Proofread chapter 7

docs/guide/src/interactivity/hooks.md

@@ -80,7 +80,7 @@ This pattern might seem strange at first, but it can be a significant upgrade ov
 ## Rules of hooks
 
 Hooks are sensitive to how they are used. To use hooks, you must abide by the
-"rules of hooks" (borrowed from react)](https://reactjs.org/docs/hooks-rules.html):
+"rules of hooks" ([borrowed from react](https://reactjs.org/docs/hooks-rules.html)):
 
 - Functions with "use_" should not be called in callbacks
 - Functions with "use_" should not be called out of order
@@ -245,19 +245,10 @@ fn example(cx: Scope) -> Element {
 
 By default, we bundle a handful of hooks in the Dioxus-Hooks package. Feel free to click on each hook to view its definition and associated documentation.
 
-- [use_state](https://docs.rs/dioxus_hooks/use_state) - store state with ergonomic updates
+- [use_state](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_state.html) - store state with ergonomic updates
-- [use_ref](https://docs.rs/dioxus_hooks/use_ref) - store non-clone state with a refcell
+- [use_ref](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_ref.html) - store non-clone state with a refcell
-- [use_future](https://docs.rs/dioxus_hooks/use_future) - store a future to be polled after initialization
+- [use_future](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_future.html) - store a future to be polled after initialization
-- [use_coroutine](https://docs.rs/dioxus_hooks/use_coroutine) - store a future that can be stopped/started/communicated with
+- [use_coroutine](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_coroutine.html) - store a future that can be stopped/started/communicated with
-- [use_noderef](https://docs.rs/dioxus_hooks/use_noderef) - store a handle to the native element
+- [use_context_provider](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_context_provider.html) - expose state to descendent components
-- [use_callback](https://docs.rs/dioxus_hooks/use_callback) - store a callback that implements PartialEq for memoization
+- [use_context](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_context.html) - consume state provided by `use_provide_context`
-- [use_provide_context](https://docs.rs/dioxus_hooks/use_provide_context) - expose state to descendent components
+- [use_suspense](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_suspense.html)
-- [use_context](https://docs.rs/dioxus_hooks/use_context) - consume state provided by `use_provide_context`
-
-For a more in-depth guide to building new hooks, checkout out the advanced hook building guide in the reference.
-
-## Wrapping up
-
-In this chapter, we learned about the mechanics and intricacies of storing state inside a component.
-
-In the next chapter, we'll cover event listeners in similar depth, and how to combine the two to build interactive components.

docs/guide/src/interactivity/importanthooks.md

@@ -2,23 +2,13 @@
 
 Most components you will write in Dioxus will need to store state somehow. For local state, we provide two very convenient hooks:
 
-- `use_state`
+- [use_state](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_state.html)
-- `use_ref`
+- [use_ref](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_ref.html)
 
 Both of these hooks are extremely powerful and flexible, so we've dedicated this section to understanding them properly.
 
 > These two hooks are not the only way to store state. You can always build your own hooks!
 
-## Note on Hooks
-
-If you're struggling with errors due to usage in hooks, make sure you're following the rules of hooks:
-
-- Functions with "use_" should not be called in callbacks
-- Functions with "use_" should not be called out of order
-- Functions with "use_" should not be called in loops or conditionals
-
-A large majority of issues that seem to be "wrong with Dioxus" are actually just a misuse of hooks.
-
 ## `use_state`
 
 The `use_state` hook is very similar to its React counterpart. When we use it, we get two values: 
@@ -84,7 +74,7 @@ cx.spawn({
 
 You might've noticed a fundamental limitation to `use_state`: to modify the value in-place, it must be cheaply cloneable. But what if your type is not cheap to clone?
 
-In these cases, you should reach for `use_ref` which is essentially just a glorified `Rc<RefCell<T>>` (typical Rust UI shenanigans).
+In these cases, you should reach for `use_ref` which is essentially just a glorified `Rc<RefCell<T>>` (Rust [smart pointers](https://doc.rust-lang.org/book/ch15-04-rc.html)).
 
 This provides us some runtime locks around our data, trading reliability for performance. For most cases though, you will find it hard to make `use_ref` crash.
 
@@ -117,7 +107,7 @@ names.write().push("Tiger");
 If you don't want to re-render the component when names is updated, then we can use the `write_silent` method:
 
 ```rust
-names.write().push("Transmogrifier");
+names.write_silent().push("Transmogrifier");
 ```
 
 Again, like `UseState`, the `UseRef` handle is clonable into async contexts:
@@ -135,8 +125,3 @@ cx.spawn({
     }
 })
 ```
-
-
-## Wrapping up
-
-These two hooks are extremely powerful at storing state.

docs/guide/src/interactivity/index.md

@@ -44,9 +44,9 @@ fn App(cx: Scope<PostProps>) -> Element {
 }
 ```
 
-State in Dioxus follows a pattern called "one-way-data-flow." As your components create new components as their children, your app's structure will eventually grow into a tree where state gets passed down from the root component into "leaves" of the tree.
+State in Dioxus follows a pattern called "one-way data-flow." As your components create new components as their children, your app's structure will eventually grow into a tree where state gets passed down from the root component into "leaves" of the tree.
 
-You've probably seen the tree of UI components represented using an directed-acyclic-graph:
+You've probably seen the tree of UI components represented using a directed acyclic graph:
 
 ![image](../images/component_tree.png)
 
@@ -173,11 +173,13 @@ With these building blocks, we can craft new hooks similar to `use_state` that l
 
 In general, Dioxus should be plenty fast for most use cases. However, there are some rules you should consider following to ensure your apps are quick.
 
-- 1) **Don't call set—state _while rendering_**. This will cause Dioxus to unnecessarily re-check the component for updates or enter an infinite loop.
+- 1) **Don't call set_state _while rendering_**. This will cause Dioxus to unnecessarily re-check the component for updates or enter an infinite loop.
 - 2) **Break your state apart into smaller sections.** Hooks are explicitly designed to "unshackle" your state from the typical model-view-controller paradigm, making it easy to reuse useful bits of code with a single function.
 - 3) **Move local state down**. Dioxus will need to re-check child components of your app if the root component is constantly being updated. You'll get best results if rapidly-changing state does not cause major re-renders.
 
+<!-- todo: link when the section exists
 Don't worry - Dioxus is fast. But, if your app needs *extreme performance*, then take a look at the `Performance Tuning` in the `Advanced Guides` book.
+-->
 
 ## The `Scope` object