Update docs to reflect changes in master (#670)

* work on updating docs to master version

* more updates

* more polishing

* finish interactivity chapter

* finish updating core guide

* fix grammer mistakes and typos

* more grammer fixes

* add liveview guide

* remove doc build

* WIP custom renderer docs

* add axum as dev-dependancy to guide

* fix examples

* fix overview example

* use md book fork to fix compilation

docs/guide/src/en/interactivity/dynamic_rendering.md

@@ -12,10 +12,19 @@ To render different elements based on a condition, you could use an `if-else` st
 
 > You could also use `match` statements, or any Rust function to conditionally render different things.
 
+### Improving the `if-else` Example
+
+You may have noticed some repeated code in the `if-else` example above. Repeating code like this is both bad for maintainability and performance. Dioxus will skip diffing static elements like the button, but when switching between multiple `rsx` calls it cannot perform this optimization. For this example either approach is fine, but for components with large parts that are reused between conditionals, it can be more of an issue.
+
+We can improve this example by splitting up the dynamic parts and inserting them where they are needed.
+
+```rust
+{{#include ../../../examples/conditional_rendering.rs:if_else_improved}}
+```
 
 ### Inspecting `Element` props
 
-Since `Element` is a `Option<VNode>`, components accepting `Element` as a prop can actually inspect its contents, and render different things based on that. Example:
+Since `Element` is a `Option<VNode>`, components accepting `Element` as a prop can inspect its contents, and render different things based on that. Example:
 
 ```rust
 {{#include ../../../examples/component_children_inspect.rs:Clickable}}
@@ -43,9 +52,9 @@ Often, you'll want to render a collection of components. For example, you might
 For this, Dioxus accepts iterators that produce `Element`s. So we need to:
 
 - Get an iterator over all of our items (e.g., if you have a `Vec` of comments, iterate over it with `iter()`)
-- `.map` the iterator to convert each item into a rendered `Element` using `cx.render(rsx!(...))`
+- `.map` the iterator to convert each item into a `LazyNode` using `rsx!(...)`
   - Add a unique `key` attribute to each iterator item
-- Include this iterator in the final RSX
+- Include this iterator in the final RSX (or use it inline)
 
 Example: suppose you have a list of comments you want to render. Then, you can render them like this:
 
@@ -53,21 +62,26 @@ Example: suppose you have a list of comments you want to render. Then, you can r
 {{#include ../../../examples/rendering_lists.rs:render_list}}
 ```
 
+### Inline for loops
+
+Because of how common it is to render a list of items, Dioxus provides a shorthand for this. Instead of using `.iter, `.map`, and `rsx`, you can use a `for` loop with a body of rsx code:
+
+```rust
+{{#include ../../../examples/rendering_lists.rs:render_list_for_loop}}
+```
+
 ### The `key` Attribute
 
-Every time you re-render your list, Dioxus needs to keep track of which item went where, because the order of items in a list might change – items might be added, removed or swapped. Despite that, Dioxus needs to:
-
-- Keep track of component state
-- Efficiently figure out what updates need to be made to the UI
+Every time you re-render your list, Dioxus needs to keep track of which items go where to determine what updates need to be made to the UI.
 
 For example, suppose the `CommentComponent` had some state – e.g. a field where the user typed in a reply. If the order of comments suddenly changes, Dioxus needs to correctly associate that state with the same comment – otherwise, the user will end up replying to a different comment!
 
-To help Dioxus keep track of list items, we need to associate each item with a unique key. In the example above, we dynamically generated the unique key. In real applications, it's more likely that the key will come from e.g. a database ID. It doesn't really matter where you get the key from, as long as it meets the requirements
+To help Dioxus keep track of list items, we need to associate each item with a unique key. In the example above, we dynamically generated the unique key. In real applications, it's more likely that the key will come from e.g. a database ID. It doesn't matter where you get the key from, as long as it meets the requirements:
 
 - Keys must be unique in a list
 - The same item should always get associated with the same key
 - Keys should be relatively small (i.e. converting the entire Comment structure to a String would be a pretty bad key) so they can be compared efficiently
 
-You might be tempted to use an item's index in the list as its key. In fact, that’s what Dioxus will use if you don’t specify a key at all. This is only acceptable if you can guarantee that the list is constant – i.e., no re-ordering, additions or deletions.
+You might be tempted to use an item's index in the list as its key. That’s what Dioxus will use if you don’t specify a key at all. This is only acceptable if you can guarantee that the list is constant – i.e., no re-ordering, additions, or deletions.
 
 > Note that if you pass the key to a component you've made, it won't receive the key as a prop. It’s only used as a hint by Dioxus itself. If your component needs an ID, you have to pass it as a separate prop.