Merge branch 'master' into jk/partialexpansion

.docker/Dockerfile_base_test_image

@@ -0,0 +1,14 @@
+FROM rust:1.58-buster
+
+RUN apt update
+RUN apt install -y \
+    libglib2.0-dev \
+    libgtk-3-dev \
+    libsoup2.4-dev \
+    libappindicator3-dev \
+    libwebkit2gtk-4.0-dev \
+    firefox-esr \
+    # for Tarpaulin code coverage
+    liblzma-dev binutils-dev libcurl4-openssl-dev libdw-dev libelf-dev
+
+CMD ["exit"]

.docker/Dockerfile_code_coverage

@@ -0,0 +1,7 @@
+FROM dioxus-test-image
+
+WORKDIR /run_test
+RUN cargo install cargo-tarpaulin
+RUN cargo cache -a
+
+ENTRYPOINT [ "bash" ]

.docker/Dockerfile_pre_test

@@ -0,0 +1,8 @@
+FROM dioxus-base-test-image
+
+RUN cargo install cargo-binstall
+RUN cargo install cargo-make
+RUN cargo install wasm-pack
+RUN cargo install cargo-cache && cargo cache -a
+
+CMD ["exit"]

.docker/Dockerfile_test

@@ -0,0 +1,9 @@
+FROM dioxus-pre-test
+
+RUN mkdir run_test
+COPY tmp /run_test
+WORKDIR /run_test
+RUN cargo make tests
+RUN cargo cache -a
+
+CMD ["exit"]

.docker/README.md

@@ -0,0 +1,27 @@
+# Why this?
+
+This part is used to test whole package before pushing it
+
+# How to use it?
+
+Just run in the folder:
+`bash run_local_tests.sh`. If nothing fails, then you can push your code to the repo.
+or run:
+`bash run_local_tests.sh --with-full-docker-cleanup`
+for cleaning up images as well
+
+# How is it composed of?
+
+  1. `Dockerfile_pre_test` will build the base image for the tests to be run into
+  2. `Dockerfile_test` will run the actual tests based on 1.
+  3. `run_local_tests.sh` to wrap this up
+
+# Warning
+
+The task requires some amount of CPU work and disk space (5GB per tests). Some clean up is included in the script.
+
+# Requirements
+
+ * [docker](https://docs.docker.com/engine/install/)
+ * bash
+ * rsync

.docker/run_local_tests.sh

@@ -0,0 +1,44 @@
+set -eux
+
+echo "Test script started"
+
+function run_script {
+    if [[ -d tmp ]]
+    then
+        rm -rf tmp
+    fi
+    mkdir tmp
+    # copy files first
+    rsync -a --progress ../ tmp --exclude target --exclude docker
+
+    # build base image
+    docker build -f Dockerfile_base_test_image -t dioxus-base-test-image .
+    docker build -f Dockerfile_pre_test -t dioxus-pre-test .
+    # run test
+    docker build -f Dockerfile_test -t dioxus-test-image .
+    # code coverage
+    docker build -f Dockerfile_code_coverage -t dioxus-code-coverage .
+
+    # exec test coverage
+    cd .. && \
+    echo "rustup default nightly && cargo +nightly tarpaulin --verbose --all-features --tests --workspace --exclude core-macro --timeout 120 --out Html" | docker run -i --rm --security-opt seccomp=unconfined -v "/home/elios/project/prs/dioxus/:/run_test" dioxus-code-coverage
+
+    # clean up
+    rm -rf tmp
+    if [ $# -ge 1 ]
+    then
+        echo "Got some parameter"
+        if [ $1 = "--with-full-docker-cleanup" ]
+        then
+        docker image rm dioxus-base-test-image
+        docker image rm dioxus-test-image
+        fi
+    fi
+}
+
+run_script || echo "Error occured.. cleaning a bit." && \
+    docker system prune -f;
+
+docker system prune -f
+
+echo "Script finished to execute"

.github/FUNDING.yml

@@ -0,0 +1,4 @@
+# These are supported funding model platforms
+
+github: jkelleyrtp # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
+open_collective: dioxus-labs # Replace with a single Open Collective username

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,36 @@
+---
+name: Bug report
+about: Create a report to help us improve Dioxus
+---
+
+**Problem**
+
+<!-- A clear and concise description of what the bug is. -->
+
+**Steps To Reproduce**
+
+Steps to reproduce the behavior:
+
+- 
+- 
+- 
+
+**Expected behavior**
+
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+
+If applicable, add screenshots to help explain your problem.
+
+**Environment:**
+ - Dioxus version: [e.g. v0.17, `master`]
+ - Rust version: [e.g. 1.43.0, `nightly`]
+ - OS info: [e.g. MacOS]
+ - App platform: [e.g. `web`, `desktop`]
+
+**Questionnaire**
+<!-- If you feel up to the challenge, please check one of the boxes below: -->
+- [ ] I'm interested in fixing this myself but don't know where to start
+- [ ] I would like to fix and I have a solution
+- [ ] I don't have time to fix this right now, but maybe later

.github/ISSUE_TEMPLATE/feature_requst.md

@@ -0,0 +1,16 @@
+---
+name: Feature Request
+about: If you have any interesting advice, you can tell us.
+---
+
+## Specific Demand
+
+<!--
+What feature do you need, please describe it in detail.
+-->
+
+## Implement Suggestion
+
+<!--
+If you have any suggestion for complete this feature, you can tell us.
+-->

.github/workflows/docs.yml

@@ -0,0 +1,38 @@
+name: github pages
+
+on:
+  push:
+    paths:
+      - docs/**
+      - .github/workflows/docs.yml
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  build-deploy:
+    runs-on: ubuntu-latest
+    environment: docs
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Setup mdBook
+        uses: peaceiris/actions-mdbook@v1
+        with:
+          mdbook-version: "0.4.10"
+
+      - name: Build
+        run: cd docs &&
+          cd guide && mdbook build -d ../nightly/guide && cd .. &&
+          cd reference && mdbook build -d ../nightly/reference && cd .. &&
+          cd router && mdbook build -d ../nightly/router  && cd ..
+
+      - name: Deploy 🚀
+        uses: JamesIves/github-pages-deploy-action@v4.2.3
+        with:
+          branch: gh-pages # The branch the action should deploy to.
+          folder: docs/nightly # The folder the action should deploy.
+          target-folder: docs/nightly
+          repository-name: dioxuslabs/docsite
+          clean: false
+          token: ${{ secrets.DEPLOY_KEY }} # let's pretend I don't need it for now

.github/workflows/macos.yml

@@ -1,7 +1,18 @@
-on: [push, pull_request]
-
 name: macOS tests
 
+on:
+  push:
+    paths:
+      - packages/**
+      - examples/**
+      - src/**
+      - .github/**
+      - lib.rs
+      - Cargo.toml
+  pull_request:
+    branches:
+      - master
+
 jobs:
   test:
     name: Test Suite

.github/workflows/main.yml

@@ -1,7 +1,18 @@
-on: [push, pull_request]
-
 name: Rust CI
 
+on:
+  push:
+    paths:
+      - packages/**
+      - examples/**
+      - src/**
+      - .github/**
+      - lib.rs
+      - Cargo.toml
+  pull_request:
+    branches:
+      - master
+
 jobs:
   check:
     name: Check
@@ -33,10 +44,13 @@ jobs:
       - uses: Swatinem/rust-cache@v1
       - run: sudo apt-get update
       - run: sudo apt install libwebkit2gtk-4.0-dev libappindicator3-dev libgtk-3-dev
+      - uses: davidB/rust-cargo-make@v1
+      - uses: browser-actions/setup-firefox@latest
+      - uses: jetli/wasm-pack-action@v0.3.0
       - uses: actions-rs/cargo@v1
         with:
-          command: test
-          args: --features "desktop, ssr, router"
+          command: make
+          args: tests
 
   fmt:
     name: Rustfmt
@@ -73,3 +87,22 @@ jobs:
         with:
           command: clippy
           args: -- -D warnings
+
+  coverage:
+    name: Coverage
+    runs-on: ubuntu-latest
+    container:
+      image: xd009642/tarpaulin:develop-nightly
+      options: --security-opt seccomp=unconfined
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+      - name: Generate code coverage
+        run: |
+          apt-get update &&\
+          apt install libwebkit2gtk-4.0-dev libappindicator3-dev libgtk-3-dev -y &&\
+          cargo +nightly tarpaulin --verbose --tests --all-features --workspace --timeout 120 --out Xml
+      - name: Upload to codecov.io
+        uses: codecov/codecov-action@v2
+        with:
+          fail_ci_if_error: false

.github/workflows/windows.yml

@@ -1,9 +1,17 @@
 name: windows
+
 on:
   push:
+    paths:
+      - packages/**
+      - examples/**
+      - src/**
+      - .github/**
+      - lib.rs
+      - Cargo.toml
+  pull_request:
     branches:
       - master
-  pull_request:
 
 jobs:
   test:
@@ -19,13 +27,7 @@ jobs:
       max-parallel: 2
       fail-fast: false
       matrix:
-        target:
-          [
-            i686-pc-windows-gnu,
-            i686-pc-windows-msvc,
-            x86_64-pc-windows-gnu,
-            x86_64-pc-windows-msvc,
-          ]
+        target: [x86_64-pc-windows-gnu, x86_64-pc-windows-msvc]
         cfg_release_channel: [stable]
 
     steps:
@@ -47,12 +49,6 @@ jobs:
           rustup target add ${{ matrix.target }}
         shell: powershell
 
-      - name: Add mingw32 to path for i686-gnu
-        run: |
-          echo "C:\msys64\mingw32\bin" >> $GITHUB_PATH
-        if: matrix.target == 'i686-pc-windows-gnu' && matrix.channel == 'nightly'
-        shell: bash
-
       - name: Add mingw64 to path for x86_64-gnu
         run: echo "C:\msys64\mingw64\bin" >> $GITHUB_PATH
         if: matrix.target == 'x86_64-pc-windows-gnu' && matrix.channel == 'nightly'
@@ -62,7 +58,7 @@ jobs:
         run: |
           rustc -Vv
           cargo -V
-          set RUST_BACKTRACE=1 
+          set RUST_BACKTRACE=1
           cargo build --features "desktop, ssr, router"
           cargo test --features "desktop, ssr, router"
         shell: cmd

.gitignore

@@ -1,4 +1,5 @@
 /target
+/dist
 Cargo.lock
 .DS_Store
 
@@ -7,3 +8,4 @@ Cargo.lock
 !.vscode/tasks.json
 !.vscode/launch.json
 !.vscode/extensions.json
+tarpaulin-report.html

.vscode/settings.json

@@ -4,4 +4,8 @@
     "desktop",
     "router"
   ],
+  "editor.formatOnSave": true,
+  "[toml]": {
+    "editor.formatOnSave": false
+  }
 }

.vscode/spellright.dict

@@ -69,3 +69,13 @@ Jank
 noderef
 reborrow
 VirtualDoms
+bootstrapper
+WebkitGtk
+laymans
+iter
+cloneable
+fudamental
+clonable
+oninput
+Webview
+idanarye

CHANGELOG.md

@@ -5,6 +5,26 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## Unreleased
+
+### Commit Statistics
+
+<csr-read-only-do-not-edit/>
+
+ - 1 commit contributed to the release over the course of 7 calendar days.
+ - 0 commits where understood as [conventional](https://www.conventionalcommits.org).
+ - 0 issues like '(#ID)' where seen in commit messages
+
+### Commit Details
+
+<csr-read-only-do-not-edit/>
+
+<details><summary>view details</summary>
+
+ * **Uncategorized**
+    - Fix various typos and grammar nits ([`9e4ec43`](https://github.comgit//DioxusLabs/dioxus/commit/9e4ec43b1e78d355c56a38e4c092170b2b01b20d))
+</details>
+
 ## v0.1.7 (2022-01-08)
 
 ### Bug Fixes

Cargo.toml

@@ -1,28 +1,29 @@
 [package]
 name = "dioxus"
-version = "0.1.7"
+version = "0.1.8"
 authors = ["Jonathan Kelley"]
 edition = "2018"
 description = "Core functionality for Dioxus - a concurrent renderer-agnostic Virtual DOM for interactive user experiences"
-license = "MIT/Apache-2.0"
+license = "MIT OR Apache-2.0"
 repository = "https://github.com/DioxusLabs/dioxus/"
 homepage = "https://dioxuslabs.com"
 documentation = "https://dioxuslabs.com"
 keywords = ["dom", "ui", "gui", "react", "wasm"]
 
 [dependencies]
-dioxus-core = { path = "./packages/core", version = "^0.1.7" }
-dioxus-html = { path = "./packages/html", version = "^0.1.4", optional = true }
-dioxus-core-macro = { path = "./packages/core-macro", version = "^0.1.6", optional = true }
+dioxus-core = { path = "./packages/core", version = "^0.1.9" }
+dioxus-html = { path = "./packages/html", version = "^0.1.6", optional = true }
+dioxus-core-macro = { path = "./packages/core-macro", version = "^0.1.7", optional = true }
+dioxus-hooks = { path = "./packages/hooks", version = "^0.1.7", optional = true }
 dioxus-macro-inner = { path = "./packages/rsx", optional = true }
-dioxus-hooks = { path = "./packages/hooks", version = "^0.1.6", optional = true }
 
-dioxus-web = { path = "./packages/web", version = "^0.0.4", optional = true }
-dioxus-desktop = { path = "./packages/desktop", version = "^0.1.5", optional = true }
-dioxus-ssr = { path = "./packages/ssr", version = "^0.1.2", optional = true }
+dioxus-web = { path = "./packages/web", version = "^0.0.5", optional = true }
+dioxus-desktop = { path = "./packages/desktop", version = "^0.1.6", optional = true }
+dioxus-ssr = { path = "./packages/ssr", version = "^0.1.3", optional = true }
 
-dioxus-router = { path = "./packages/router", version = "^0.1.0", optional = true }
+dioxus-router = { path = "./packages/router", version = "^0.1.1", optional = true }
 dioxus-mobile = { path = "./packages/mobile", version = "^0.0.3", optional = true }
+dioxus-interpreter-js = { path = "./packages/interpreter", version = "^0.0.0", optional = true }
 # dioxus-liveview = { path = "./packages/liveview", optional = true }
 
 [features]
@@ -55,6 +56,7 @@ members = [
     "packages/ssr",
     "packages/desktop",
     "packages/mobile",
+    "packages/interpreter",
 ]
 
 [dev-dependencies]

LICENSE

@@ -1 +0,0 @@
-MIT/Apache-2 

LICENSE-APACHE

@@ -0,0 +1,176 @@
+                              Apache License
+                        Version 2.0, January 2004
+                     http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+   "License" shall mean the terms and conditions for use, reproduction,
+   and distribution as defined by Sections 1 through 9 of this document.
+
+   "Licensor" shall mean the copyright owner or entity authorized by
+   the copyright owner that is granting the License.
+
+   "Legal Entity" shall mean the union of the acting entity and all
+   other entities that control, are controlled by, or are under common
+   control with that entity. For the purposes of this definition,
+   "control" means (i) the power, direct or indirect, to cause the
+   direction or management of such entity, whether by contract or
+   otherwise, or (ii) ownership of fifty percent (50%) or more of the
+   outstanding shares, or (iii) beneficial ownership of such entity.
+
+   "You" (or "Your") shall mean an individual or Legal Entity
+   exercising permissions granted by this License.
+
+   "Source" form shall mean the preferred form for making modifications,
+   including but not limited to software source code, documentation
+   source, and configuration files.
+
+   "Object" form shall mean any form resulting from mechanical
+   transformation or translation of a Source form, including but
+   not limited to compiled object code, generated documentation,
+   and conversions to other media types.
+
+   "Work" shall mean the work of authorship, whether in Source or
+   Object form, made available under the License, as indicated by a
+   copyright notice that is included in or attached to the work
+   (an example is provided in the Appendix below).
+
+   "Derivative Works" shall mean any work, whether in Source or Object
+   form, that is based on (or derived from) the Work and for which the
+   editorial revisions, annotations, elaborations, or other modifications
+   represent, as a whole, an original work of authorship. For the purposes
+   of this License, Derivative Works shall not include works that remain
+   separable from, or merely link (or bind by name) to the interfaces of,
+   the Work and Derivative Works thereof.
+
+   "Contribution" shall mean any work of authorship, including
+   the original version of the Work and any modifications or additions
+   to that Work or Derivative Works thereof, that is intentionally
+   submitted to Licensor for inclusion in the Work by the copyright owner
+   or by an individual or Legal Entity authorized to submit on behalf of
+   the copyright owner. For the purposes of this definition, "submitted"
+   means any form of electronic, verbal, or written communication sent
+   to the Licensor or its representatives, including but not limited to
+   communication on electronic mailing lists, source code control systems,
+   and issue tracking systems that are managed by, or on behalf of, the
+   Licensor for the purpose of discussing and improving the Work, but
+   excluding communication that is conspicuously marked or otherwise
+   designated in writing by the copyright owner as "Not a Contribution."
+
+   "Contributor" shall mean Licensor and any individual or Legal Entity
+   on behalf of whom a Contribution has been received by Licensor and
+   subsequently incorporated within the Work.
+
+2. Grant of Copyright License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   copyright license to reproduce, prepare Derivative Works of,
+   publicly display, publicly perform, sublicense, and distribute the
+   Work and such Derivative Works in Source or Object form.
+
+3. Grant of Patent License. Subject to the terms and conditions of
+   this License, each Contributor hereby grants to You a perpetual,
+   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+   (except as stated in this section) patent license to make, have made,
+   use, offer to sell, sell, import, and otherwise transfer the Work,
+   where such license applies only to those patent claims licensable
+   by such Contributor that are necessarily infringed by their
+   Contribution(s) alone or by combination of their Contribution(s)
+   with the Work to which such Contribution(s) was submitted. If You
+   institute patent litigation against any entity (including a
+   cross-claim or counterclaim in a lawsuit) alleging that the Work
+   or a Contribution incorporated within the Work constitutes direct
+   or contributory patent infringement, then any patent licenses
+   granted to You under this License for that Work shall terminate
+   as of the date such litigation is filed.
+
+4. Redistribution. You may reproduce and distribute copies of the
+   Work or Derivative Works thereof in any medium, with or without
+   modifications, and in Source or Object form, provided that You
+   meet the following conditions:
+
+   (a) You must give any other recipients of the Work or
+       Derivative Works a copy of this License; and
+
+   (b) You must cause any modified files to carry prominent notices
+       stating that You changed the files; and
+
+   (c) You must retain, in the Source form of any Derivative Works
+       that You distribute, all copyright, patent, trademark, and
+       attribution notices from the Source form of the Work,
+       excluding those notices that do not pertain to any part of
+       the Derivative Works; and
+
+   (d) If the Work includes a "NOTICE" text file as part of its
+       distribution, then any Derivative Works that You distribute must
+       include a readable copy of the attribution notices contained
+       within such NOTICE file, excluding those notices that do not
+       pertain to any part of the Derivative Works, in at least one
+       of the following places: within a NOTICE text file distributed
+       as part of the Derivative Works; within the Source form or
+       documentation, if provided along with the Derivative Works; or,
+       within a display generated by the Derivative Works, if and
+       wherever such third-party notices normally appear. The contents
+       of the NOTICE file are for informational purposes only and
+       do not modify the License. You may add Your own attribution
+       notices within Derivative Works that You distribute, alongside
+       or as an addendum to the NOTICE text from the Work, provided
+       that such additional attribution notices cannot be construed
+       as modifying the License.
+
+   You may add Your own copyright statement to Your modifications and
+   may provide additional or different license terms and conditions
+   for use, reproduction, or distribution of Your modifications, or
+   for any such Derivative Works as a whole, provided Your use,
+   reproduction, and distribution of the Work otherwise complies with
+   the conditions stated in this License.
+
+5. Submission of Contributions. Unless You explicitly state otherwise,
+   any Contribution intentionally submitted for inclusion in the Work
+   by You to the Licensor shall be under the terms and conditions of
+   this License, without any additional terms or conditions.
+   Notwithstanding the above, nothing herein shall supersede or modify
+   the terms of any separate license agreement you may have executed
+   with Licensor regarding such Contributions.
+
+6. Trademarks. This License does not grant permission to use the trade
+   names, trademarks, service marks, or product names of the Licensor,
+   except as required for reasonable and customary use in describing the
+   origin of the Work and reproducing the content of the NOTICE file.
+
+7. Disclaimer of Warranty. Unless required by applicable law or
+   agreed to in writing, Licensor provides the Work (and each
+   Contributor provides its Contributions) on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied, including, without limitation, any warranties or conditions
+   of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+   PARTICULAR PURPOSE. You are solely responsible for determining the
+   appropriateness of using or redistributing the Work and assume any
+   risks associated with Your exercise of permissions under this License.
+
+8. Limitation of Liability. In no event and under no legal theory,
+   whether in tort (including negligence), contract, or otherwise,
+   unless required by applicable law (such as deliberate and grossly
+   negligent acts) or agreed to in writing, shall any Contributor be
+   liable to You for damages, including any direct, indirect, special,
+   incidental, or consequential damages of any character arising as a
+   result of this License or out of the use or inability to use the
+   Work (including but not limited to damages for loss of goodwill,
+   work stoppage, computer failure or malfunction, or any and all
+   other commercial damages or losses), even if such Contributor
+   has been advised of the possibility of such damages.
+
+9. Accepting Warranty or Additional Liability. While redistributing
+   the Work or Derivative Works thereof, You may choose to offer,
+   and charge a fee for, acceptance of support, warranty, indemnity,
+   or other liability obligations and/or rights consistent with this
+   License. However, in accepting such obligations, You may act only
+   on Your own behalf and on Your sole responsibility, not on behalf
+   of any other Contributor, and only if You agree to indemnify,
+   defend, and hold each Contributor harmless for any liability
+   incurred by, or claims asserted against, such Contributor by reason
+   of your accepting any such warranty or additional liability.
+
+END OF TERMS AND CONDITIONS

LICENSE-MIT

@@ -0,0 +1,23 @@
+Permission is hereby granted, free of charge, to any
+person obtaining a copy of this software and associated
+documentation files (the "Software"), to deal in the
+Software without restriction, including without
+limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software
+is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice
+shall be included in all copies or substantial portions
+of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
+ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
+TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
+PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
+SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
+IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.

Makefile.toml

@@ -0,0 +1,51 @@
+[config]
+default_to_workspace = false
+min_version = "0.32.4"
+
+[env]
+CARGO_MAKE_CLIPPY_ARGS = "-- --deny=warnings"
+CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILE = true
+
+[config.modify_core_tasks]
+namespace = "core"
+private = true
+
+[tasks.tests-setup]
+private = true
+script = [
+  """
+    test_flags = array --headless --firefox
+    dioxus_test_features = set wasm_test
+    dioxus_test_flags = array_join ${test_flags} " "
+    echo "running tests with flags: ${dioxus_test_flags} and features: ${dioxus_test_features}"
+    set_env DIOXUS_TEST_FLAGS ${dioxus_test_flags}
+    set_env DIOXUS_TEST_FEATURES ${dioxus_test_features}
+    """,
+]
+script_runner = "@duckscript"
+
+[tasks.tests]
+category = "Testing"
+dependencies = ["tests-setup"]
+description = "Run all tests"
+env = {CARGO_MAKE_WORKSPACE_SKIP_MEMBERS = ["**/examples/*"]}
+run_task = {name = ["test-flow", "test-with-browser"], fork = true}
+
+[tasks.build]
+command = "cargo"
+args = ["build"]
+
+[tasks.test-flow]
+dependencies = ["test"]
+private = true
+
+[tasks.test]
+dependencies = ["build"]
+command = "cargo"
+args = ["test", "--all-targets", "--workspace", "--exclude", "dioxus-router"]
+private = true
+
+[tasks.test-with-browser]
+env = { CARGO_MAKE_WORKSPACE_INCLUDE_MEMBERS = ["**/packages/router"] }
+private = true
+workspace = true

README.md

@@ -1,5 +1,5 @@
 <div align="center">
-  <h1>🌗🚀 Dioxus</h1>
+  <h1>Dioxus</h1>
   <p>
     <strong>Frontend that scales.</strong>
   </p>
@@ -26,27 +26,28 @@
     <img src="https://github.com/dioxuslabs/dioxus/actions/workflows/main.yml/badge.svg"
       alt="CI status" />
   </a>
-</div>
 
-<div align="center">
   <!--Awesome -->
   <a href="https://github.com/dioxuslabs/awesome-dioxus">
     <img src="https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg" alt="Awesome Page" />
   </a>
   <!-- Discord -->
   <a href="https://discord.gg/XgGxMSkvUM">
-    <img src="https://badgen.net/discord/members/XgGxMSkvUM" alt="Awesome Page" />
+    <img src="https://img.shields.io/discord/899851952891002890.svg?logo=discord&style=flat-square" alt="Discord Link" />
   </a>
 </div>
 
 
+
 <div align="center">
   <h3>
     <a href="https://dioxuslabs.com"> Website </a>
     <span> | </span>
-    <a href="https://dioxuslabs.com/guide"> Guide </a>
-    <span> | </span>
     <a href="https://github.com/DioxusLabs/example-projects"> Examples </a>
+    <span> | </span>
+    <a href="https://dioxuslabs.com/guide"> Guide (0.1.8) </a>
+    <span> | </span>
+    <a href="https://dioxuslabs.com/nightly/guide"> Guide (Master) </a>
   </h3>
 </div>
 
@@ -64,12 +65,12 @@ Dioxus is a portable, performant, and ergonomic framework for building cross-pla
 
 ```rust
 fn app(cx: Scope) -> Element {
-    let mut count = use_state(&cx, || 0);
+    let (count, set_count) = use_state(&cx, || 0);
 
     cx.render(rsx!(
         h1 { "High-Five counter: {count}" }
-        button { onclick: move |_| count += 1, "Up high!" }
-        button { onclick: move |_| count -= 1, "Down low!" }
+        button { onclick: move |_| set_count(count + 1), "Up high!" }
+        button { onclick: move |_| set_count(count - 1), "Down low!" }
     ))
 }
 ```
@@ -84,7 +85,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
@@ -121,9 +122,9 @@ See the [awesome-dioxus](https://github.com/DioxusLabs/awesome-dioxus) page for
 
 ## Why Dioxus and why Rust?
 
-TypeScript is a fantastic addition to JavaScript, but it's still fundamentally JavaScript. TS code runs slightly slower, has tons of configuration options, and not every package is properly typed. 
+TypeScript is a fantastic addition to JavaScript, but it's still fundamentally JavaScript. TS code runs slightly slower, has tons of configuration options, and not every package is properly typed.
 
-In contrast, Dioxus is written in Rust - which is almost like "TypeScript on steroids". 
+In contrast, Dioxus is written in Rust - which is almost like "TypeScript on steroids".
 
 By using Rust, we gain:
 
@@ -141,76 +142,56 @@ By using Rust, we gain:
 
 Specifically, Dioxus provides us many other assurances:
 
-- Proper use of immutable datastructures
-- Guaranteed error handling (so you can sleep easy at night not worrying about `cannot read property of undefined`) 
+- 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
 
-And much more. Dioxus makes Rust apps just as fast to write as React apps, but affords more robustness, giving your frontend team greater confidence in making big changes in shorter time. 
+And much more. Dioxus makes Rust apps just as fast to write as React apps, but affords more robustness, giving your frontend team greater confidence in making big changes in shorter time.
 
-### Why NOT Dioxus?
+## Why NOT Dioxus?
 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**. 
+## 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.
+- [Azul](https://azul.rs): Fully native HTML/CSS renderer for desktop applications, no support for web/ssr
 
 
-# Parity with React
+## Parity with React & Roadmap
 
-Dioxus is heavily inspired by React, but we want your transition to feel like an upgrade. Dioxus is _most_ of the way there, but missing a few key features. This parity table does not necessarily include important ecosystem crates like code blocks, markdown, resizing hooks, etc.
+Dioxus is heavily inspired by React, but we want your transition to feel like an upgrade. Dioxus is _most_ of the way there, but missing a few key features. These include:
 
+- Portals
+- Suspense integration with SSR
+- Server Components / Bundle Splitting / Lazy
 
-| Feature                   | Dioxus | React | Notes for Dioxus                                                     |
-| ------------------------- | ------ | ----- | -------------------------------------------------------------------- |
-| Conditional Rendering     | ✅      | ✅     | if/then to hide/show component                                       |
-| Map, Iterator             | ✅      | ✅     | map/filter/reduce to produce rsx!                                    |
-| Keyed Components          | ✅      | ✅     | advanced diffing with keys                                           |
-| Web                       | ✅      | ✅     | renderer for web browser                                             |
-| Desktop (webview)         | ✅      | ✅     | renderer for desktop                                                 |
-| Shared State (Context)    | ✅      | ✅     | share state through the tree                                         |
-| Hooks                     | ✅      | ✅     | memory cells in components                                           |
-| SSR                       | ✅      | ✅     | render directly to string                                            |
-| Component Children        | ✅      | ✅     | cx.children() as a list of nodes                                     |
-| Headless components       | ✅      | ✅     | components that don't return real elements                           |
-| Fragments                 | ✅      | ✅     | multiple elements without a real root                                |
-| Manual Props              | ✅      | ✅     | Manually pass in props with spread syntax                            |
-| Controlled Inputs         | ✅      | ✅     | stateful wrappers around inputs                                      |
-| CSS/Inline Styles         | ✅      | ✅     | syntax for inline styles/attribute groups                            |
-| Custom elements           | ✅      | ✅     | Define new element primitives                                        |
-| Suspense                  | ✅      | ✅     | schedule future render from future/promise                           |
-| Integrated error handling | ✅      | ✅     | Gracefully handle errors with ? syntax                               |
-| NodeRef                   | ✅      | ✅     | gain direct access to nodes                                          |
-| Re-hydration              | ✅      | ✅     | Pre-render to HTML to speed up first contentful paint                |
-| Jank-Free Rendering       | ✅      | ✅     | Large diffs are segmented across frames for silky-smooth transitions |
-| Effects                   | ✅      | ✅     | Run effects after a component has been committed to render           |
-| Portals                   | 🛠      | ✅     | Render nodes outside of the traditional tree structure               |
-| Cooperative Scheduling    | 🛠      | ✅     | Prioritize important events over non-important events                |
-| Server Components         | 🛠      | ✅     | Hybrid components for SPA and Server                                 |
-| Bundle Splitting          | 👀      | ✅     | Efficiently and asynchronously load the app                          |
-| Lazy Components           | 👀      | ✅     | Dynamically load the new components as the page is loaded            |
-| 1st class global state    | ✅      | ✅     | redux/recoil/mobx on top of context                                  |
-| Runs natively             | ✅      | ❓     | runs as a portable binary w/o a runtime (Node)                       |
-| Subtree Memoization       | ✅      | ❓     | skip diffing static element subtrees                                 |
-| High-efficiency templates | 🛠      | ❓     | rsx! calls are translated to templates on the DOM's side             |
-| Compile-time correct      | ✅      | ❓     | Throw errors on invalid template layouts                             |
-| Heuristic Engine          | ✅      | ❓     | track component memory usage to minimize future allocations          |
-| Fine-grained reactivity   | 👀      | ❓     | Skip diffing for fine-grain updates                                  |
+Dioxus is unique in the Rust ecosystem in that it supports:
 
-- ✅ = implemented and working
-- 🛠 = actively being worked on
-- 👀 = not yet implemented or being worked on
-- ❓ = not sure if will or can implement
+- Components with props that borrow from their parent
+- Server-side-rendering with client-side hydration
+- Support for desktop applications
 
+For more information on what features are currently available and the roadmap for the future, be sure to check out [the guide](https://dioxuslabs.com/guide/).
+
+## Projects in the ecosystem
+
+Want to jump in and help build the future of Rust frontend? There's plenty of places where your contributions can make a huge difference:
+
+- [TUI renderer](https://github.com/dioxusLabs/rink)
+- [CLI Tooling](https://github.com/dioxusLabs/cli)
+- [Documentation and Example Projects](https://github.com/dioxusLabs/docsite)
+- LiveView and Web Server
+- Asset System
 
 ## License
 

codecov.yml

@@ -0,0 +1 @@
+comment: false

docs/guide/src/README.md

@@ -5,13 +5,13 @@
 **Dioxus** is a framework and ecosystem for building fast, scalable, and robust user interfaces with the Rust programming language. This guide will help you get started with Dioxus running on the Web, Desktop, Mobile, and more.
 
 ```rust
-fn App(cx: Scope) -> Element {
-    let mut count = use_state(&cx, || 0);
+fn app(cx: Scope) -> Element {
+    let (count, set_count) = use_state(&cx, || 0);
 
     cx.render(rsx!(
         h1 { "High-Five counter: {count}" }
-        button { onclick: move |_| count += 1, "Up high!" }
-        button { onclick: move |_| count -= 1, "Down low!" }
+        button { onclick: move |_| set_count(count + 1), "Up high!" }
+        button { onclick: move |_| set_count(count - 1), "Down low!" }
     ))
 };
 ```
@@ -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 WebSys. 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,9 +44,10 @@ 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! 
+Dioxus supports server-side rendering!
 
 For rendering statically to an `.html` file or from a WebServer, then you'll want to make sure the `ssr` feature is enabled in the `dioxus` crate and use the `dioxus::ssr` API. We don't expect the SSR API to change drastically in the future.
 
@@ -90,13 +90,13 @@ Examples:
 ### LiveView / Server Component Support
 ---
 
-The internal architecture of Dioxus was designed from day one to support the `LiveView` use-case, where a web server hosts a running app for each connected user. As of today, there is no first-class LiveView support - you'll need to wire this up yourself. 
+The internal architecture of Dioxus was designed from day one to support the `LiveView` use-case, where a web server hosts a running app for each connected user. As of today, there is no first-class LiveView support - you'll need to wire this up yourself.
 
 While not currently fully implemented, the expectation is that LiveView apps can be a hybrid between Wasm and server-rendered where only portions of a page are "live" and the rest of the page is either server-rendered, statically generated, or handled by the host SPA.
 
 ### Multithreaded Support
 ---
-The Dioxus VirtualDom, sadly, is not currently `Send`. Internally, we use quite a bit of interior mutability which is not thread-safe. This means you can't easily use Dioxus with most web frameworks like Tide, Rocket, Axum, etc. 
+The Dioxus VirtualDom, sadly, is not currently `Send`. Internally, we use quite a bit of interior mutability which is not thread-safe. This means you can't easily use Dioxus with most web frameworks like Tide, Rocket, Axum, etc.
 
 To solve this, you'll want to spawn a VirtualDom on its own thread and communicate with it via channels.
 

docs/guide/src/ROADMAP.md

@@ -0,0 +1,114 @@
+# Roadmap & Feature-set
+
+Before we dive into Dioxus, feel free to take a look at our feature set and roadmap to see if what Dioxus can do today works for you.
+
+If a feature that you need doesn't exist or you want to contribute to projects on the roadmap, feel free to get involved by [joining the discord](https://discord.gg/XgGxMSkvUM).
+
+Generally, here's the status of each platform:
+
+- **Web**: Dioxus is a great choice for pure web-apps - especially for CRUD/complex apps. However, it does lack the ecosystem of React, so you might be missing a component library or some useful hook.
+
+- **SSR**: Dioxus is a great choice for pre-rendering, hydration, and rendering HTML on a web endpoint. Be warned - the VirtualDom is not (currently) `Send + Sync`.
+
+- **Desktop**: You can build very competent single-window desktop apps right now. However, multi-window apps require support from Dioxus core and are not ready.
+
+- **Mobile**: Mobile support is very young. You'll be figuring things out as you go and there are not many support crates for peripherals.
+
+- **LiveView**: LiveView support is very young. You'll be figuring things out as you go. Thankfully, none of it is too hard and any work can be upstreamed into Dioxus.
+
+## Features
+---
+
+| Feature                   | Status | Description                                                          |
+| ------------------------- | ------ | -------------------------------------------------------------------- |
+| Conditional Rendering     | ✅      | if/then to hide/show component                                       |
+| Map, Iterator             | ✅      | map/filter/reduce to produce rsx!                                    |
+| Keyed Components          | ✅      | advanced diffing with keys                                           |
+| Web                       | ✅      | renderer for web browser                                             |
+| Desktop (webview)         | ✅      | renderer for desktop                                                 |
+| Shared State (Context)    | ✅      | share state through the tree                                         |
+| Hooks                     | ✅      | memory cells in components                                           |
+| SSR                       | ✅      | render directly to string                                            |
+| Component Children        | ✅      | cx.children() as a list of nodes                                     |
+| Headless components       | ✅      | components that don't return real elements                           |
+| Fragments                 | ✅      | multiple elements without a real root                                |
+| Manual Props              | ✅      | Manually pass in props with spread syntax                            |
+| Controlled Inputs         | ✅      | stateful wrappers around inputs                                      |
+| CSS/Inline Styles         | ✅      | syntax for inline styles/attribute groups                            |
+| Custom elements           | ✅      | Define new element primitives                                        |
+| Suspense                  | ✅      | schedule future render from future/promise                           |
+| Integrated error handling | ✅      | Gracefully handle errors with ? syntax                               |
+| NodeRef                   | ✅      | gain direct access to nodes                                          |
+| Re-hydration              | ✅      | Pre-render to HTML to speed up first contentful paint                |
+| Jank-Free Rendering       | ✅      | Large diffs are segmented across frames for silky-smooth transitions |
+| Effects                   | ✅      | Run effects after a component has been committed to render           |
+| Portals                   | 🛠      | Render nodes outside of the traditional tree structure               |
+| Cooperative Scheduling    | 🛠      | Prioritize important events over non-important events                |
+| Server Components         | 🛠      | Hybrid components for SPA and Server                                 |
+| Bundle Splitting          | 👀      | Efficiently and asynchronously load the app                          |
+| Lazy Components           | 👀      | Dynamically load the new components as the page is loaded            |
+| 1st class global state    | ✅      | redux/recoil/mobx on top of context                                  |
+| Runs natively             | ✅      | runs as a portable binary w/o a runtime (Node)                       |
+| Subtree Memoization       | ✅      | skip diffing static element subtrees                                 |
+| High-efficiency templates | 🛠      | rsx! calls are translated to templates on the DOM's side             |
+| Compile-time correct      | ✅      | Throw errors on invalid template layouts                             |
+| Heuristic Engine          | ✅      | track component memory usage to minimize future allocations          |
+| Fine-grained reactivity   | 👀      | Skip diffing for fine-grain updates                                  |
+
+- ✅ = implemented and working
+- 🛠 = actively being worked on
+- 👀 = not yet implemented or being worked on
+- ❓ = not sure if will or can implement
+
+
+## Roadmap
+---
+
+
+Core:
+- [x] Release of Dioxus Core
+- [x] Upgrade documentation to include more theory and be more comprehensive
+- [ ] Support for HTML-side templates for lightning-fast dom manipulation
+- [ ] Support for multiple renderers for same virtualdom (subtrees)
+- [ ] Support for ThreadSafe (Send + Sync)
+- [ ] Support for Portals
+
+SSR
+- [x] SSR Support + Hydration
+- [ ] Integrated suspense support for SSR
+
+Desktop
+- [ ] Declarative window management
+- [ ] Templates for building/bundling
+- [ ] Fully native renderer
+- [ ] Access to Canvas/WebGL context natively
+
+Mobile
+- [ ] Mobile standard library 
+  - [ ] GPS
+  - [ ] Camera
+  - [ ] filesystem
+  - [ ] Biometrics
+  - [ ] WiFi
+  - [ ] Bluetooth
+  - [ ] Notifications
+  - [ ] Clipboard
+  - [ ] 
+
+Bundling (CLI)
+- [x] translation from HTML into RSX
+- [ ] dev server
+- [ ] live reload
+- [ ] translation from JSX into RSX
+- [ ] hot module replacement
+- [ ] code splitting
+- [ ] asset macros
+- [ ] css pipeline
+- [ ] image pipeline
+
+Essential hooks
+- [ ] Router
+- [ ] Global state management
+- [ ] Resize observer
+
+

docs/guide/src/SUMMARY.md

@@ -1,24 +1,28 @@
 # Summary
 
 - [Introduction](README.md)
-- [Getting Setup](setup.md)
+- [Roadmap](ROADMAP.md)
+- [Getting Set Up](setup.md)
 - [Hello, World!](hello_world.md)
 - [Describing the UI](elements/index.md)
   - [Intro to Elements](elements/vnodes.md)
-  - [Intro to Components](elements/components.md)
-  - [The Props Macro](elements/propsmacro.md)
-  - [Reusing, Importing, and Exporting Components](elements/exporting_components.md)
-  - [Passing children and attributes](elements/component_children.md)
   - [Conditional Rendering](elements/conditional_rendering.md)
   - [Lists](elements/lists.md)
+  - [Special Attributes](elements/special_attributes.md)
+- [Components](components/index.md)
+  - [Properties](components/propsmacro.md)
+  - [Reusing, Importing, and Exporting](components/exporting_components.md)
+  - [Children and Attributes](components/component_children.md)
+  - [How Data Flows](components/composing.md)
 - [Adding Interactivity](interactivity/index.md)
   - [Hooks and Internal State](interactivity/hooks.md)
-  - [Event handlers](interactivity/event_handlers.md)
+  - [UseState and UseRef](interactivity/importanthooks.md) 
+  - [Event Listeners](interactivity/event_handlers.md)
   - [User Input and Controlled Components](interactivity/user_input.md)
   - [Lifecycle, updates, and effects](interactivity/lifecycles.md)
 - [Managing State](state/index.md)
-  - [Local State](state/localstate.md) 
-  - [Lifting State](state/liftingstate.md) 
+  - [Local State](state/localstate.md)
+  - [Lifting State](state/liftingstate.md)
   - [Global State](state/sharedstate.md)
   - [Error handling](state/errorhandling.md)
 - [Working with Async](async/index.md)
@@ -41,3 +45,4 @@
 
   <!-- - [Suspense](concepts/suspense.md) -->
   <!-- - [Async Callbacks](concepts/asynccallbacks.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/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> {

docs/guide/src/async/fetching.md

@@ -1 +1,4 @@
 # Fetching
+
+
+This section is currently under construction! 🏗

docs/guide/src/async/index.md

@@ -1,13 +1,13 @@
 # Working with Async
 
-Not all apps you'll build can be self-contained with synchronous code. You'll often need to interact with file systems, network interfaces, hardware, or timers. 
+Not all apps you'll build can be self-contained with synchronous code. You'll often need to interact with file systems, network interfaces, hardware, or timers.
 
 So far, we've only talked about building apps with synchronous code, so this chapter will focus integrating asynchronous code into your app.
 
 
 ## The Runtime
 
-By default, Dioxus-Desktop ships with the `Tokio` runtime and automatically sets everything up for you. 
+By default, Dioxus-Desktop ships with the `Tokio` runtime and automatically sets everything up for you.
 
 
 
@@ -17,3 +17,6 @@ Writing apps that deal with Send/Sync can be frustrating at times. Under the hoo
 
 
 All async code in your app is polled on a `LocalSet`, so any async code we w
+
+
+> This section is currently under construction! 🏗

docs/guide/src/components/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!(
@@ -30,7 +30,7 @@ struct ClickableProps<'a> {
     title: &'a str
 }
 
-fn Clickable(cx: Scope<ClickableProps>) -> Element {
+fn Clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
     cx.render(rsx!(
         a {
             href: "{cx.props.href}"
@@ -64,7 +64,7 @@ struct ClickableProps<'a> {
     body: Element<'a>
 }
 
-fn Clickable(cx: Scope<ClickableProps>) -> Element {
+fn Clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
     cx.render(rsx!(
         a {
             href: "{cx.props.href}",
@@ -98,7 +98,7 @@ struct ClickableProps<'a> {
     children: Element<'a>
 }
 
-fn clickable(cx: Scope<ClickableProps>) -> Element {
+fn Clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
     cx.render(rsx!(
         a {
             href: "{cx.props.href}",
@@ -125,7 +125,7 @@ While technically allowed, it's an antipattern to pass children more than once i
 However, because the `Element` is transparently a `VNode`, we can actually match on it to extract the nodes themselves, in case we are expecting a specific format:
 
 ```rust
-fn clickable(cx: Scope<ClickableProps>) -> Element {
+fn clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
     match cx.props.children {
         Some(VNode::Text(text)) => {
             // ...
@@ -137,7 +137,7 @@ fn clickable(cx: Scope<ClickableProps>) -> Element {
 }
 ```
 
-## Passing attributes
+<!-- ## Passing attributes
 
 In the cases where you need to pass arbitrary element properties into a component - say to add more functionality to the `<a>` tag, Dioxus will accept any quoted fields. This is similar to adding arbitrary fields to regular elements using quotes.
 
@@ -160,9 +160,9 @@ struct ClickableProps<'a> {
     attributes: Attributes<'a>
 }
 
-fn clickable(cx: Scope<ClickableProps>) -> Element {
+fn clickable(cx: Scope<ClickableProps<'a>>) -> Element {
     cx.render(rsx!(
-        a { 
+        a {
             ..cx.props.attributes,
             "Any link, anywhere"
         }
@@ -171,7 +171,7 @@ fn clickable(cx: Scope<ClickableProps>) -> Element {
 ```
 
 The quoted escapes are a great way to make your components more flexible.
-
+ -->
 
 ## Passing handlers
 
@@ -184,9 +184,9 @@ struct ClickableProps<'a> {
     onclick: EventHandler<'a, MouseEvent>
 }
 
-fn clickable(cx: Scope<ClickableProps>) -> Element {
+fn clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
     cx.render(rsx!(
-        a { 
+        a {
             onclick: move |evt| cx.props.onclick.call(evt)
         }
     ))
@@ -215,5 +215,3 @@ In this chapter, we learned:
 - How to convert `listeners` into `EventHandlers` for components
 - How to extend any node with custom attributes and children
 
-Next chapter, we'll talk about conditionally rendering parts of your user interface.
-

docs/guide/src/components/composing.md

@@ -0,0 +1,243 @@
+# Thinking in React
+
+We've finally reached the point in our tutorial where we can talk about the theory of Reactive interfaces. We've talked about defining a declarative view, but not about the aspects that make our code *reactive*.
+
+Understanding the theory of reactive programming is essential to making sense of Dioxus and writing effective, performant UIs.
+
+In this section, we'll talk about:
+
+- One-way data flow
+- Modifying data
+- Forcing renders
+- How renders propagate
+
+This section is a bit long, but worth the read. We recommend coffee, tea, and/or snacks.
+
+## Reactive Programming
+
+Dioxus is one the very few Rust libraries that provide a "Reactive Programming Model". The term "Reactive programming" is a classification of programming paradigm - much like functional or imperative programming. This is a very important distinction since it affects how we *think* about our code.
+
+Reactive programming is a programming model concerned with deriving computations from asynchronous data flow. Most reactive programs are comprised of datasources, intermediate computations, and a final result.
+
+We consider the rendered GUI to be the final result of our Dioxus apps. The datasources for our apps include local and global state.
+
+For example, the model presented in the figure below is comprised of two data sources: time and a constant. These values are passed through our computation graph to achieve a final result: `g`.
+
+![Reactive Model](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Reactive_programming_glitches.svg/440px-Reactive_programming_glitches.svg.png)
+
+Whenever our `seconds` variable changes, we will then reevaluate the computation for `t`. Because `g` relies on `t`, we will also reevaluate its computation too. Notice that we would've reevaluated the computation for `g` even if `t` didn't change because `seconds` is used to calculate `g`.
+
+However, if we somehow changed our constant from `1` to `2`, then we need to reevaluate `t`. If, for whatever reason, this change did not affect the result of `t`, then we wouldn't try to reevaluate `g`.
+
+In Reactive Programming, we don't think about whether or not we should reevaluate `t` or `g`; instead, we simply provide functions of computation and let the framework figure out the rest for us.
+
+In Rust, our reactive app would look something like:
+
+```rust
+fn compute_g(t: i32, seconds: i32) -> bool {
+    t > seconds
+}
+
+fn compute_t(constant: i32, seconds: i32) -> i32 {
+    constant + seconds
+}
+
+fn compute_graph(constant: i32, seconds: i32) -> bool {
+    let t = compute_t(constant, seconds);
+    let g = compute_g(t, seconds);
+    g
+}
+```
+
+## How is Dioxus Reactive?
+
+The Dioxus VirtualDom provides us a framework for reactive programming. When we build apps with dioxus, we need to provide our own datasources. This can be either initial props or some values fetched from the network. We then pass this data through our app into components through properties. 
+
+If we represented the reactive graph presented above in Dioxus, it would look very similar:
+
+```rust
+// Declare a component that holds our datasources and calculates `g`
+fn RenderGraph(cx: Scope) -> Element {
+    let seconds = use_datasource(SECONDS);
+    let constant = use_state(&cx, || 1);
+
+    cx.render(rsx!( 
+        RenderG { seconds: seconds } 
+        RenderT { seconds: seconds, constant: constant }
+    ))
+}
+
+// "calculate" g by rendering `t` and `seconds`
+#[inline_props]
+fn RenderG(cx: Scope, seconds: i32) -> Element {
+    cx.render(rsx!{ "There are {seconds} seconds remaining..." })
+}
+
+// calculate and render `t` in its own component
+#[inline_props]
+fn RenderT(cx: Scope, seconds: i32, constant: i32) -> Element {
+    let res = seconds + constant;
+    cx.render(rsx!{ "{res}" })
+}
+```
+
+With this app, we've defined three components. Our top-level component provides our datasources (the hooks), computation nodes (child components), and a final value (what's "rendered").
+
+Now, whenever the `constant` changes, our `RenderT` component will be re-rendered. However, if `seconds` doesn't change, then we don't need to re-render `RenderG` because the input is the same. If `seconds` *does* change, then both RenderG and RenderT will be reevaluated.
+
+Dioxus is "Reactive" because it provides this framework for us. All we need to do is write our own tiny units of computation and Dioxus figures out which components need to be reevaluated automatically.
+
+These extra checks and algorithms add some overhead, which is why you see projects like [Sycamore](http://sycamore-rs.netlify.app) and [SolidJS](http://solidjs.com) eliminating them altogether. Dioxus is *really* fast, so we're willing to exchange the added overhead for improved developer experience.
+
+## How do we update values in our dataflow graph?
+
+Dioxus will automatically figure out how to regenerate parts of our app when datasources change. But how exactly can we update our data sources?
+
+In Dioxus there are two datasources:
+
+1. Local state in `use_hook` and all other hooks
+2. Global state through `provide_context`.
+
+Technically, the root props of the VirtualDom are a third datasource, but since we cannot modify them, they are not worth talking about.
+
+### Local State
+
+For local state in hooks, Dioxus gives us the `use_hook` method which returns an `&mut T` without any requirements. This means raw hook values are not tracked by Dioxus. In fact, we could write a component that modifies a hook value directly:
+
+```rust
+fn app(cx: Scope) -> Element {
+    let mut count = cx.use_hook(|_| 0);
+    cx.render(rsx!{
+        button { 
+            onclick: move |_| *count += 1, 
+            "Count: {count}"
+        }
+    })
+}
+```
+
+However, when this value is written to, the component does not know to be reevaluated. We must explicitly tell Dioxus that this component is "dirty" and needs to be re-rendered. This is done through the `cx.needs_update` method:
+
+```rust
+button { 
+    onclick: move |_| {
+        *count += 1;
+        cx.needs_update();
+    }, 
+    "Count: {count}"
+}
+```
+
+Now, whenever we click the button, the value will change and the component will be re-rendered.
+
+> Re-rendering is when Dioxus calls your function component *again*. Component functions will be called over and over throughout their lifetime, so they should be mostly side-effect free.
+
+### Understand this!
+
+Your component functions will be called ("rendered" in our lingo) for as long as the component is present in the tree.
+
+A single component will be called multiple times, modifying its own internal state or rendering new nodes with new values from its properties.
+
+### App-Global State
+
+With the `provide_context` and `consume_context` methods on `Scope`, we can share values to descendants without having to pass values through component props. This has the side-effect of making our datasources less obvious from a high-level perspective, but it makes our components more modular within the same codebase.
+
+To make app-global state easier to reason about, Dioxus makes all values provided through `provide_context` immutable. This means any library built on top of `provide_context` needs to use interior mutability to modify shared global state.
+
+In these cases, App-Global state needs to manually track which components need to be re-generated. 
+
+To regenerate *any* component in your app, you can get a handle to the Dioxus' internal scheduler through `schedule_update_any`:
+
+```rust
+let force_render = cx.schedule_update_any();
+
+// force a render of the root component
+force_render(ScopeId(0));
+```
+
+## What does it mean for a component to "re-render"?
+
+In our guides, we frequently use the phrase "re-render" to describe updates to our app. You'll often hear this paired with "preventing unnecessary re-renders." But what exactly does this mean?
+
+When we call `dioxus::desktop::launch`, Dioxus will create a new `Scope` object and call the component we gave it. Our `rsx!` calls will create new nodes which we return back to the VirtualDom. Dioxus will then look through these nodes for child components, call their functions, and so on until every component has been "rendered." We consider these nodes "rendered" because they were created because of our explicit actions.
+
+The tree of UI that dioxus creates will roughly look like the tree of components presented earlier:
+
+![Tree of UI](../images/component_tree.png)
+
+But what happens when we call `needs_update` after modifying some important state? Well, if Dioxus called our component's function again, then we would produce new, different nodes. In fact, this is exactly what Dioxus does! 
+
+At this point, we have some old nodes and some new nodes. Again, we call this "rendering" because Dioxus had to create new nodes because of our explicit actions. Any time new nodes get created, our VirtualDom is being "rendered."
+
+These nodes are stored in an extremely efficient memory allocator called a "bump arena." For example, a div with a handler and attribute would be stored in memory in two locations: the "old" tree and the "new" tree.
+
+![Bump Arenas](../images/oldnew.png)
+
+From here, Dioxus computes the difference between these trees and updates the Real DOM to make it look like the new version of what we've declared.
+
+![Diffing](../images/diffing.png)
+
+## Suppressing Renders
+
+So, we know how to make Dioxus render, but how do we *stop* it? What if we *know* that our state didn't change and we shouldn't render and diff new nodes because they'll be exactly the same as the last time?
+
+In these cases, you want to reach for *memoization*. In Dioxus, memoization involves preventing a component from rendering again if its props didn't change since the last time it attempted to render.
+
+Visually, you can tell that a component will only re-render if the new value is sufficiently different than the old one.
+
+| props.val | re-render |
+| --------- | --------- |
+| 10        | true      |
+| 20        | true      |
+| 20        | false     |
+| 20        | false     |
+| 10        | true      |
+| 30        | false     |
+
+This is why when you `derive(Props)`, you must also implement the `PartialEq` trait. To override the memoization strategy for a component, you can simply implement your own PartialEq.
+
+```rust
+struct CustomProps {
+    val: i32,
+}
+
+impl PartialEq for CustomProps {
+    fn partial_eq(&self, other: &Self) -> bool {
+        // we don't render components that have a val less than 5
+        if other.val > 5 && self.val > 5{
+            self.val == other.val
+        }
+    }
+}
+```
+
+However, for components that borrow data, it doesn't make sense to implement PartialEq since the actual references in memory might be different.
+
+You can technically override this behavior by implementing the `Props` trait manually, though it's unsafe and easy to mess up:
+
+```rust
+impl Properties for CustomProps {
+    fn memoize(&self, other &Self) -> bool {
+        self != other
+    }
+}
+```
+
+TLDR:
+- Dioxus checks if props changed between renders
+- If props changed according to PartialEq, Dioxus re-renders the component
+- Props that have a lifetime (ie `<'a>`) will always be re-rendered
+
+## Wrapping Up
+
+Wow, that was a lot of material!
+
+Let's see if we can recap what was presented:
+
+- Reactive programming calculates a final value from datasources and computation
+- Dioxus is "reactive" since it figures out which computations to check
+- `schedule_update` must be called to mark a component as dirty
+- dirty components will be re-rendered (called multiple times) to produce a new UI
+- Renders can be suppressed with memoization
+
+This theory is crucial to understand how to compose components and how to control renders in your app.

docs/guide/src/components/exporting_components.md

@@ -1,4 +1,3 @@
-
 # Reusing, Importing, and Exporting Components
 
 As your application grows in size, you'll want to start breaking your UI into components and, eventually, different files. This is a great idea to encapsulate functionality of your UI and scale your team.
@@ -25,27 +24,27 @@ fn main() {
     dioxus::desktop::launch(App);
 }
 
-fn App(Scope) -> Element {} 
+fn App(Scope) -> Element {}
 
 #[derive(PartialEq, Props)]
 struct PostProps{}
-fn Post(Scope<PostProps>) -> Element {} 
+fn Post(Scope<PostProps>) -> Element {}
 
 #[derive(PartialEq, Props)]
 struct VoteButtonsProps {}
-fn VoteButtons(Scope<VoteButtonsProps>) -> Element {} 
+fn VoteButtons(Scope<VoteButtonsProps>) -> Element {}
 
 #[derive(PartialEq, Props)]
 struct TitleCardProps {}
-fn TitleCard(Scope<TitleCardProps>) -> Element {} 
+fn TitleCard(Scope<TitleCardProps>) -> Element {}
 
 #[derive(PartialEq, Props)]
 struct MetaCardProps {}
-fn MetaCard(Scope<MetaCardProps>) -> Element {} 
+fn MetaCard(Scope<MetaCardProps>) -> Element {}
 
 #[derive(PartialEq, Props)]
 struct ActionCardProps {}
-fn ActionCard(Scope<ActionCardProps>) -> Element {} 
+fn ActionCard(Scope<ActionCardProps>) -> Element {}
 ```
 
 That's a lot of components for one file! We've successfully refactored our app into components, but we should probably start breaking it up into a file for each component.
@@ -61,11 +60,21 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 struct ActionCardProps {}
-fn ActionCard(Scope<ActionCardProps>) -> Element {} 
+fn ActionCard(Scope<ActionCardProps>) -> Element {}
 ```
 
 We should also create a `mod.rs` file in the `post` folder so we can use it from our `main.rs`. Our `Post` component and its props will go into this file.
 
+```rust
+// src/post/mod.rs
+
+use dioxus::prelude::*;
+
+#[derive(PartialEq, Props)]
+struct PostProps {}
+fn Post(Scope<PostProps>) -> Element {}
+```
+
 ```shell
 ├── Cargo.toml
 └── src
@@ -78,8 +87,6 @@ We should also create a `mod.rs` file in the `post` folder so we can use it from
         └── mod.rs
 ```
 
-
-
 In our `main.rs`, we'll want to declare the `post` module so we can access our `Post` component.
 
 ```rust
@@ -104,10 +111,10 @@ fn App(Scope) -> Element {
             original_poster: "me".to_string()
         }
     })
-} 
+}
 ```
 
-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
@@ -116,7 +123,7 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 pub struct PostProps {}
-pub fn Post(Scope<PostProps>) -> Element {} 
+pub fn Post(Scope<PostProps>) -> Element {}
 ```
 
 While we're here, we also need to make sure each of our subcomponents are included as modules and exported.
@@ -164,7 +171,6 @@ pub fn Post(Scope<PostProps>) -> Element {
 }
 ```
 
-
 Ultimately, including and exporting components is governed by Rust's module system. [The Rust book is a great resource to learn about these concepts in greater detail.](https://doc.rust-lang.org/book/ch07-00-managing-growing-projects-with-packages-crates-and-modules.html)
 
 ## Final structure:
@@ -203,7 +209,7 @@ fn App(Scope) -> Element {
             original_poster: "me".to_string()
         }
     })
-} 
+}
 ```
 
 
@@ -255,7 +261,7 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 pub struct VoteButtonsProps {}
-pub fn VoteButtons(Scope<VoteButtonsProps>) -> Element {} 
+pub fn VoteButtons(Scope<VoteButtonsProps>) -> Element {}
 ```
 
 ```rust
@@ -264,7 +270,7 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 pub struct TitleCardProps {}
-pub fn TitleCard(Scope<TitleCardProps>) -> Element {} 
+pub fn TitleCard(Scope<TitleCardProps>) -> Element {}
 ```
 
 ```rust
@@ -273,7 +279,7 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 pub struct MetaCardProps {}
-pub fn MetaCard(Scope<MetaCardProps>) -> Element {} 
+pub fn MetaCard(Scope<MetaCardProps>) -> Element {}
 ```
 
 ```rust
@@ -282,16 +288,5 @@ use dioxus::prelude::*;
 
 #[derive(PartialEq, Props)]
 pub struct ActionCardProps {}
-pub fn ActionCard(Scope<ActionCardProps>) -> Element {} 
+pub fn ActionCard(Scope<ActionCardProps>) -> Element {}
 ```
-
-## Moving forward
-
-Next chapter, we'll start to add use code to hide and show Elements with conditional rendering.
-
-For more reading on components:
-
-- [Components in depth]()
-- [Lifecycles]()
-- [The Context object]()
-- [Optional Prop fields]()

docs/guide/src/components/index.md

@@ -0,0 +1,42 @@
+# Introduction to Components
+
+In the previous chapter, we learned about Elements and how they can be composed to create a basic user interface. Now, we'll learn how to group Elements together to form Components. We'll cover:
+
+- What makes a Component
+- How to model a component and its properties in Dioxus
+- How to "think declaratively"
+
+## What is a component?
+
+In short, a component is a special function that takes input properties and outputs an Element. Much like a function encapsulates some specific computation task, a Component encapsulates some specific rendering task – typically, rendering an isolated part of the user interface.
+
+### Real-world example
+
+Let's use a Reddit post as an example:
+
+![Reddit Post](../images/reddit_post.png)
+
+If we look at the layout of the component, we notice quite a few buttons and pieces of functionality:
+
+- Upvote/Downvote
+- View comments
+- Share
+- Save
+- Hide
+- Give award
+- Report
+- Crosspost
+- Filter by site
+- 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 Components:
+
+![Post as Component](../images/reddit_post_components.png)
+
+- **VoteButton**: Upvote/Downvote
+- **TitleCard**: Title, Filter-By-Url
+- **MetaCard**: Original Poster, Time Submitted
+- **ActionCard**: View comments, Share, Save, Hide, Give award, Report, Crosspost
+
+In this chapter, we'll learn how to define these components.

docs/guide/src/components/propsmacro.md

@@ -0,0 +1,200 @@
+# Component Properties
+Dioxus components are functions that accept Props as input and output an Element. In fact, the `App` function you saw in the previous chapter was a component with no Props! Most components, however, will need to take some Props to render something useful – so, in this section, we'll learn about props:
+
+- Deriving the Props trait
+- Memoization through PartialEq
+- Optional fields on props
+- The inline_props macro    
+
+## Props
+The input of your Component must be passed in a single struct, which must implement the `Props` trait. We can derive this trait automatically with `#[derive(Props)]`.
+
+> Dioxus `Props` is very similar to [@idanarye](https://github.com/idanarye)'s [TypedBuilder crate](https://github.com/idanarye/rust-typed-builder) and supports many of the same parameters.
+
+There are 2 flavors of Props: owned and borrowed.
+
+- All Owned Props must implement `PartialEq`
+- Borrowed props [borrow](https://doc.rust-lang.org/beta/rust-by-example/scope/borrow.html) values from the parent Component
+
+### Owned Props
+
+Owned Props are very simple – they don't borrow anything. Example:
+```rust
+// Remember: owned props must implement PartialEq!
+#[derive(PartialEq, Props)]
+struct VoteButtonProps {
+    score: i32
+}
+
+fn VoteButton(cx: Scope<VoteButtonProps>) -> Element {
+    cx.render(rsx!{
+        div {
+            div { "+" }
+            div { "{cx.props.score}"}
+            div { "-" }
+        }
+    })
+}
+```
+
+Now, we can use the VoteButton Component like we would use a regular HTML element:
+
+```rust
+fn main() {
+    dioxus::desktop::launch(App);
+}
+
+fn App(cx: Scope) -> Element {
+    cx.render(rsx! (
+        VoteButton { score: 42 }
+    ))
+}
+```
+
+And we can see that the Component indeed gets rendered:
+
+![Screenshot of running app. Text: "+ \ 42 \ -"](component_example_votes.png)
+
+> The simplest Owned Props you can have is `()` - or no value at all. This is what the `App` Component takes as props. `Scope` accepts a generic for the Props which defaults to `()`.
+> 
+> ```rust
+>// this scope
+>Scope<()> 
+>
+>// is the same as this scope
+>Scope
+>```
+
+### Borrowed Props
+
+Owning props works well if your props are easy to copy around - like a single number. But what if we need to pass a larger data type, like a String from an `App` Component to a `TitleCard` subcomponent? A naive solution might be to [`.clone()`](https://doc.rust-lang.org/std/clone/trait.Clone.html) the String, creating a copy of it for the subcomponent – but this would be inefficient, especially for larger Strings.
+
+Rust allows for something more efficient – borrowing the String as a `&str`. Instead of creating a copy, this will give us a reference to the original String – this is what Borrowed Props are for!
+
+However, if we create a reference a String, Rust will require us to show that the String will not go away while we're using the reference. Otherwise, if we referenced something that doesn't exist, Bad Things could happen. To prevent this, Rust asks us to define a lifetime for the reference:
+
+```rust
+#[derive(Props)]
+struct TitleCardProps<'a> {
+    title: &'a str,
+}
+
+fn TitleCard<'a>(cx: Scope<'a, TitleCardProps<'a>>) -> Element {
+    cx.render(rsx!{
+        h1 { "{cx.props.title}" }
+    })
+}
+```
+
+This lifetime `'a` tells the compiler that as long as `title` exists, the String it was created from must also exist. Dioxus will happily accept such a component – we can now render it alongside our VoteButton!
+
+```rust
+fn App(cx: Scope) -> Element {
+    // For the sake of an example, we create the &str here.
+    // But you might as well borrow it from an owned String type.
+    let hello = "Hello Dioxus!";
+
+    cx.render(rsx! (
+        VoteButton { score: 42 },
+        TitleCard { title: hello }
+    ))
+}
+```
+![New screenshot of running app, now including a "Hello Dioxus!" heading.](component_example_title.png)
+
+## Memoization
+
+Dioxus uses Memoization for a more efficient user interface. Memoization is the process in which we check if a component actually needs to be re-rendered when its props change. If a component's properties change but they wouldn't affect the output, then we don't need to re-render the component, saving time!
+
+For example, let's say we have a component that has two children:
+
+```rust
+fn Demo(cx: Scope) -> Element {
+    // don't worry about these 2, we'll cover them later
+    let name = use_state(&cx, || String::from("bob"));
+    let age = use_state(&cx, || 21);
+
+    cx.render(rsx!{
+        Name { name: name }
+        Age { age: age }
+    })
+}
+```
+
+If `name` changes but `age` does not, then there is no reason to re-render our `Age` component since the contents of its props did not meaningfully change.
+
+Dioxus memoizes owned components. It uses `PartialEq` to determine if a component needs rerendering, or if it has stayed the same. This is why you must derive PartialEq!
+
+> This means you can always rely on props with `PartialEq` or no props at all to act as barriers in your app. This can be extremely useful when building larger apps where properties frequently change. By moving our state into a global state management solution, we can achieve precise, surgical re-renders, improving the performance of our app.
+
+Borrowed Props cannot be safely memoized. However, this is not a problem – Dioxus relies on the memoization of their parents to determine if they need to be rerendered.
+
+## Optional Props
+
+You can easily create optional fields by attaching the `optional` modifier to a field:
+
+```rust
+#[derive(Props, PartialEq)]
+struct MyProps {
+    name: String,
+
+    #[props(optional)]
+    description: Option<String>
+}
+
+fn Demo(cx: MyProps) -> Element {
+    todo!()
+}
+```
+
+Then, we can completely omit the description field when calling the component:
+
+```rust
+rsx!{
+    Demo {
+        name: "Thing".to_string(),
+        // description is omitted
+    }
+}
+```
+
+The `optional` modifier is a combination of two separate modifiers: `default` and `strip_option`. The full list of modifiers includes:
+
+- `default` - automatically add the field using its `Default` implementation
+- `strip_option` - automatically wrap values at the call site in `Some`
+- `optional` - alias for `default` and `strip_option`
+- `into` - automatically call `into` on the value at the callsite
+
+For more information on how tags work, check out the [TypedBuilder](https://github.com/idanarye/rust-typed-builder) crate. However, all attributes for props in Dioxus are flattened (no need for `setter` syntax) and the `optional` field is new.
+
+## The `inline_props` macro
+
+So far, every Component function we've seen had a corresponding ComponentProps struct to pass in props. This was quite verbose... Wouldn't it be nice to have props as simple function arguments? Then we wouldn't need to define a Props struct, and instead of typing `cx.props.whatever`, we could just use `whatever` directly!
+
+`inline_props` allows you to do just that. Instead of typing the "full" version:
+
+```rust
+#[derive(Props, PartialEq)]
+struct TitleCardProps {
+    title: String,
+}
+
+fn TitleCard(cx: Scope<TitleCardProps>) -> Element {
+    cx.render(rsx!{
+        h1 { "{cx.props.title}" }
+    })
+}
+```
+
+...you can define a function that accepts props as arguments. Then, just annotate it with `#[inline_props]`, and the macro will turn it into a regular Component for you:
+
+```rust
+#[inline_props]
+fn TitleCard(cx: Scope, title: String) -> Element {
+    cx.render(rsx!{
+        h1 { "{title}" }
+    })
+}
+```
+
+> While the new Component is shorter and easier to read, this macro should not be used by library authors since you have less control over Prop documentation.

docs/guide/src/elements/components.md

@@ -1,227 +0,0 @@
-# Introduction to Components
-
-In the previous chapter, we learned about Elements and how they can be composed to create a basic User Interface. In this chapter, we'll learn how to group Elements together to form Components.
-
-In this chapter, we'll learn:
-- What makes a Component 
-- How to model a component and its properties in Dioxus 
-- How to "think declaratively"
-
-## What is a component?
-
-In short, a component is a special function that takes input properties and outputs an Element. Typically, Components serve a single purpose: group functionality of a User Interface. Much like a function encapsulates some specific computation task, a Component encapsulates some specific rendering task.
-
-### Learning through prior art
-
-Let's take a look at a post on r/rust and see if we can sketch out a component representation.
-
-![Reddit Post](../images/reddit_post.png)
-
-This component has a bunch of important information:
-
-- The score
-- The number of comments
-- How long ago it was posted
-- The url short address
-- The title
-- The username of the original poster
-
-If we wanted to sketch out these requirements in Rust, we would start with a struct:
-
-```rust
-struct PostData {
-    score: i32,
-    comment_count: u32,
-    post_time: Instant,
-    url: String,
-    title: String,
-    original_poster_name: String
-}
-```
-
-If we look at the layout of the component, we notice quite a few buttons and functionality:
-
-- Upvote/Downvote
-- View comments
-- Share
-- Save
-- Hide
-- Give award
-- Report
-- Crosspost
-- Filter by site
-- 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:
-
-![Post as Component](../images/reddit_post_components.png)
-
-- **VoteButton**: Upvote/Downvote
-- **TitleCard**: Title, Filter-By-Url
-- **MetaCard**: Original Poster, Time Submitted
-- **ActionCard**: View comments, Share, Save, Hide, Give award, Report, Crosspost
-
-### Modeling with Dioxus
-
-We can start by sketching out the Element hierarchy using Dioxus. In general, our "Post" component will be comprised of the four sub-components listed above. First, let's define our `Post` component.
-
-Unlike normal functions, Dioxus components must explicitly define a single struct to contain all the inputs. These are commonly called "Properties" (props). Our component will be a combination of these properties and a function to render them.
-
-Our props must implement the `Props` trait and - if the component does not borrow any data - `PartialEq`. Both of these can be done automatically through derive macros:
-```rust
-#[derive(Props, PartialEq)]
-struct PostProps {
-    id: Uuid,
-    score: i32,
-    comment_count: u32,
-    post_time: Instant,
-    url: String,
-    title: String,
-    original_poster: String
-}
-```
-
-And our render function:
-```rust
-fn Post(cx: Scope<PostProps>) -> Element {
-    cx.render(rsx!{
-        div { class: "post-container"
-            VoteButton {
-                score: cx.props.score,
-            }
-            TitleCard {
-                title: cx.props.title,
-                url: cx.props.url,
-            }
-            MetaCard {
-                original_poster: cx.props.original_poster,
-                post_time: cx.props.post_time,
-            }
-            ActionCard {
-                post_id: cx.props.id
-            }
-        }
-    })
-}
-```
-
-When declaring a component in `rsx!`, we can pass in properties using the traditional Rust struct syntax. Dioxus will automatically call "into" on the property fields, cloning when necessary. Our `Post` component is simply a collection of smaller components wrapped together in a single container.
-
-Let's take a look at the `VoteButton` component. For now, we won't include any interactivity - just the rendering the score and buttons to the screen.
-
-Most of your Components will look exactly like this: a Props struct and a render function. Every component must take a `Scope` generic over some `Props` and return an `Element`.
-
-As covered before, we'll build our User Interface with the `rsx!` macro and HTML tags. However, with components, we must actually "render" our HTML markup. Calling `cx.render` converts our "lazy" `rsx!` structure into an `Element`. 
-
-```rust
-#[derive(PartialEq, Props)]
-struct VoteButtonProps {
-    score: i32
-}
-
-fn VoteButton(cx: Scope<VoteButtonProps>) -> Element {
-    cx.render(rsx!{
-        div { class: "votebutton"
-            div { class: "arrow up" }
-            div { class: "score", "{cx.props.score}"}
-            div { class: "arrow down" }
-        }
-    })
-}
-```
-
-## 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>`.
-
-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. 
-
-To enable borrowed values for your component, we need to add a lifetime to let the Rust compiler know that the output `Element` borrows from the component's props.
-
-```rust
-#[derive(Props)]
-struct TitleCardProps<'a> {
-    title: &'a str,
-}
-
-fn TitleCard<'a>(cx: Scope<'a, TitleCardProps<'a>>) -> Element {
-    cx.render(rsx!{
-        h1 { "{cx.props.title}" }
-    })
-}   
-```
-
-For users of React: Dioxus knows *not* to memoize components that borrow property fields. By default, every component in Dioxus is memoized. This can be disabled by the presence of a non-`'static` borrow.
-
-This means that during the render process, a newer version of `TitleCardProps` will never be compared with a previous version, saving some clock cycles.
-
-## The inline_props macro
-
-Yes - *another* macro! However, this one is entirely optional.
-
-For internal components, we provide the `inline_props` macro, which will let you embed your `Props` definition right into the function arguments of your component.
-
-Our title card above would be transformed from:
-
-```rust
-#[derive(Props, PartialEq)]
-struct TitleCardProps {
-    title: String,
-}
-
-fn TitleCard(cx: Scope<TitleCardProps>) -> Element {
-    cx.render(rsx!{
-        h1 { "{cx.props.title}" }
-    })
-}   
-```
-
-to:
-
-```rust
-#[inline_props]
-fn TitleCard(cx: Scope, title: String) -> Element {
-    cx.render(rsx!{
-        h1 { "{title}" }
-    })
-}   
-```
-
-Again, this macro is optional and should not be used by library authors since you have less fine-grained control over documentation and optionality.
-
-However, it's great for quickly throwing together an app without dealing with *any* extra boilerplate.
-
-## The `Scope` object
-
-Though very similar to React, Dioxus is different in a few ways. Most notably, React components will not have a `Scope` parameter in the component declaration. 
-
-Have you ever wondered how the `useState()` call works in React without a `this` object to actually store the state? 
-
-React uses global variables to store this information. Global mutable variables must be carefully managed and are broadly discouraged in Rust programs.
-
-```javascript
-function Component(props) {
-    let [state, set_state] = useState(10);
-}
-```
-
-
-Because Dioxus needs to work with the rules of Rust it uses the `Scope` object to maintain some internal bookkeeping. That's what the `Scope` object is: a place for the component to store state, manage listeners, and allocate elements. Advanced users of Dioxus will want to learn how to properly leverage the `Scope` object to build robust and performant extensions for Dioxus.
-
-```rust
-fn Post(cx: Scope<PostProps>) -> Element {
-    cx.render(rsx!("hello"))
-}
-```
-## Moving forward
-
-Next chapter, we'll talk about composing Elements and Components across files to build a larger Dioxus App.
-
-For more references on components, make sure to check out:
-
-- [Components in depth]()
-- [Lifecycles]()
-- [The Scope object]()
-- [Optional Prop fields]()
-

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
 
@@ -67,7 +67,7 @@ fn App(cx: Scope)-> Element {
 }
 ```
 
-Do note: the `rsx!` macro returns a `Closure`, an anonymous function that has a unique type. To turn our `rsx!` into Elements, we need to call `cx.render`.
+Do note: the `rsx!` macro does not return an Element, but rather a wrapper struct for a `Closure` (an anonymous function). To turn our `rsx!` into an Element, we need to call `cx.render`.
 
 To make patterns like these less verbose, the `rsx!` macro accepts an optional first argument on which it will call `render`. Our previous component can be shortened with this alternative syntax:
 
@@ -136,34 +136,6 @@ cx.render(rsx!{
 })
 ```
 
-
-## Boolean Mapping
-
-In the spirit of highly-functional apps, we suggest using the "boolean mapping" pattern when trying to conditionally hide/show an Element.
-
-By default, Rust lets you convert any `boolean` into any other type by calling `and_then()`. We can exploit this functionality in components by mapping to some Element.
-
-```rust
-let show_title = true;
-rsx!(
-    div {
-        show_title.and_then(|| rsx!{
-            "This is the title"
-        })
-    }
-)
-```
-
-We can use this pattern for many things, including options:
-```rust
-let user_name = Some("bob");
-rsx!(
-    div {
-        user_name.map(|name| rsx!("Hello {name}"))
-    }
-)
-```
-
 ## Rendering Nothing
 
 Sometimes, you don't want your component to return anything at all. Under the hood, the `Element` type is just an alias for `Option<VNode>`, so you can simply return `None`.
@@ -176,11 +148,37 @@ fn demo(cx: Scope) -> Element {
 }
 ```
 
+## Boolean Mapping
+
+In the spirit of highly-functional apps, we suggest using the "boolean mapping" pattern when trying to conditionally hide/show an Element.
+
+By default, Rust lets you convert any `boolean` into an Option of any other type with [`then()`](https://doc.rust-lang.org/std/primitive.bool.html#method.then). We can use this in Components by mapping to some Element.
+
+```rust
+let show_title = true;
+rsx!(
+    div {
+        // Renders nothing by returning None when show_title is false
+        show_title.then(|| rsx!{
+            "This is the title"
+        })
+    }
+)
+```
+
+We can use this pattern for many things, including options:
+```rust
+let user_name = Some("bob");
+rsx!(
+    div {
+        // Renders nothing if user_name is None
+        user_name.map(|name| rsx!("Hello {name}"))
+    }
+)
+```
+
 ## Moving Forward:
 
-In this chapter, we learned how to render different Elements from a Component depending on a condition. This is a very powerful building block to assemble complex User Interfaces!
+In this chapter, we learned how to render different Elements from a Component depending on a condition. This is a very powerful building block to assemble complex user interfaces!
 
 In the next chapter, we'll cover how to renderer lists inside your `rsx!`.
-
-Related Reading:
-- [RSX in Depth]()

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.
 
@@ -68,6 +68,6 @@ Remember: this concept is not new! Many frameworks are declarative - with React
 
 Here's some reading about declaring UI in React:
 
-- [https://stackoverflow.com/questions/33655534/difference-between-declarative-and-imperative-in-react-js](https://stackoverflow.com/questions/33655534/difference-between-declarative-and-imperative-in-react-js)
+- [Difference between declarative and imperative in React.js](https://stackoverflow.com/questions/33655534/difference-between-declarative-and-imperative-in-react-js), a StackOverflow thread
 
-- [https://medium.com/@myung.kim287/declarative-vs-imperative-251ce99c6c44](https://medium.com/@myung.kim287/declarative-vs-imperative-251ce99c6c44)
+- [Declarative vs Imperative](https://medium.com/@myung.kim287/declarative-vs-imperative-251ce99c6c44), a blog post by Myung Kim

docs/guide/src/elements/lists.md

@@ -1,6 +1,6 @@
 # Conditional Lists and Keys
 
-You will often want to display multiple similar components from a collection of data. 
+You will often want to display multiple similar components from a collection of data.
 
 In this chapter, you will learn:
 
@@ -10,21 +10,31 @@ In this chapter, you will learn:
 
 ## Rendering data from lists
 
-Thinking back to our analysis of the `r/reddit` page, we notice a list of data that needs to be rendered: the list of posts. This list of posts is always changing, so we cannot just hardcode the lists into our app like:
+If we wanted to build the Reddit app, then we need to implement a list of data that needs to be rendered: the list of posts. This list of posts is always changing, so we cannot just hardcode the lists into our app directly, like so:
 
 ```rust
+// we shouldn't ship our app with posts that don't update!
 rsx!(
     div {
-        Post {/* some properties */}
-        Post {/* some properties */}
-        Post {/* some properties */}
+        Post {
+            title: "Post A",
+            votes: 120,
+        }
+        Post {
+            title: "Post B",
+            votes: 14,
+        }
+        Post {
+            title: "Post C",
+            votes: 999,
+        }
     }
 )
 ```
 
-Instead, we need to transform the list of data into a list of Elements. 
+Instead, we need to transform the list of data into a list of Elements.
 
-For convenience, `rsx!` supports any type in curly braces that implements the `IntoVnodeList` trait. Conveniently, every iterator that returns something that can be rendered as an Element also implements `IntoVnodeList`. 
+For convenience, `rsx!` supports any type in curly braces that implements the `IntoVnodeList` trait. Conveniently, every iterator that returns something that can be rendered as an Element also implements `IntoVnodeList`.
 
 As a simple example, let's render a list of names. First, start with our input data:
 
@@ -32,7 +42,7 @@ As a simple example, let's render a list of names. First, start with our input d
 let names = ["jim", "bob", "jane", "doe"];
 ```
 
-Then, we create a new iterator by calling `iter` and then `map`. In our `map` function, we'll place render our template.
+Then, we create a new iterator by calling `iter` and then [`map`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.map). In our `map` function, we'll render our template.
 
 ```rust
 let name_list = names.iter().map(|name| rsx!(
@@ -40,16 +50,28 @@ let name_list = names.iter().map(|name| rsx!(
 ));
 ```
 
-Finally, we can include this list in the final structure:
+We can include this list in the final Element:
 
 ```rust
 rsx!(
     ul {
-        {name_list}
+        name_list
     }
 )
 ```
-The HTML-rendered version of this list would follow what you would expect:
+
+Rather than storing `name_list` in a temporary variable, we could also include the iterator inline:
+```rust
+rsx!(
+    ul {
+        names.iter().map(|name| rsx!(
+            li { "{name}" } 
+        ))
+    }
+)
+```
+
+The rendered HTML list is what you would expect:
 ```html
 <ul>
     <li> jim </li>
@@ -59,54 +81,13 @@ The HTML-rendered version of this list would follow what you would expect:
 </ul>
 ```
 
-### Rendering our posts with a PostList component
-
-Let's start by modeling this problem with a component and some properties. 
-
-For this example, we're going to use the borrowed component syntax since we probably have a large list of posts that we don't want to clone every time we render the Post List.
-
-```rust
-#[derive(Props, PartialEq)]
-struct PostListProps<'a> {
-    posts: &'a [PostData]
-}
-```
-Next, we're going to define our component:
-
-```rust
-fn App(cx: Scope<PostList>) -> Element {
-    // First, we create a new iterator by mapping the post array
-    let posts = cx.props.posts.iter().map(|post| rsx!{
-        Post {
-            title: post.title,
-            age: post.age,
-            original_poster: post.original_poster
-        }
-    });
-
-    // Finally, we render the post list inside of a container
-    cx.render(rsx!{
-        ul { class: "post-list"
-            {posts}
-        }
-    })
-}
-```
-
-
 ## Filtering Iterators
 
 Rust's iterators are extremely powerful, especially when used for filtering tasks. When building user interfaces, you might want to display a list of items filtered by some arbitrary check.
 
-As a very simple example, let's set up a filter where we only list names that begin with the letter "J". 
+As a very simple example, let's set up a filter where we only list names that begin with the letter "j".
 
-Let's make our list of names:
-
-```rust
-let names = ["jim", "bob", "jane", "doe"];
-```
-
-Then, we create a new iterator by calling `iter`, then `filter`, then `map`. In our `filter` function, we'll only allow "j" names, and in our `map` function, we'll  render our template.
+Using the list from above, let's create a new iterator. Before we render the list with `map` as in the previous example, we'll [`filter`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter) the names to only allow those that start with "j".
 
 ```rust
 let name_list = names
@@ -115,53 +96,43 @@ let name_list = names
     .map(|name| rsx!( li { "{name}" }));
 ```
 
-Rust's iterators provide us tons of functionality and are significantly easier to work with than JavaScript's map/filter/reduce.
+Rust's Iterators are very versatile – check out [their documentation](https://doc.rust-lang.org/std/iter/trait.Iterator.html) for more things you can do with them!
 
-For keen Rustaceans: notice how we don't actually call `collect` on the name list. If we `collected` our filtered list into new Vec, then we would need to make an allocation to store these new elements. Instead, we create an entirely new _lazy_ iterator which will then be consumed by Dioxus in the `render` call. 
+For keen Rustaceans: notice how we don't actually call `collect` on the name list. If we `collect`ed our filtered list into new Vec, we would need to make an allocation to store these new elements, which slows down rendering. Instead, we create an entirely new _lazy_ iterator which Dioxus will consume in the `render` call. The `render` method is extraordinarily efficient, so it's best practice to let it do most of the allocations for us.
 
-The `render` method is extraordinarily efficient, so it's best practice to let it do most of the allocations for us.
+## Keeping list items in order with `key`
 
-## Keeping list items in order with key
+The examples above demonstrate the power of iterators in `rsx!` but all share the same issue: if your array items move (e.g. due to sorting), get inserted, or get deleted, Dioxus has no way of knowing what happened. This can cause Elements to be unnecessarily removed, changed and rebuilt when all that was needed was to change their position – this is inneficient.
 
-
-The examples above demonstrate the power of iterators in `rsx!` but all share the same issue: a lack of "keys". Whenever you render a list of elements, each item in the list must be **uniquely identifiable**. To make each item unique, you need to give it a "key".
-
-In Dioxus, keys are strings that uniquely identifies it among other items in that array:
+To solve this problem, each item in the list must be **uniquely identifiable**. You can achieve this by giving it a unique, fixed "key". In Dioxus, a key is a string that identifies an item among others in the list.
 
 ```rust
 rsx!( li { key: "a" } )
 ```
 
-Keys tell Dioxus which array item each component corresponds to, so that it can match them up later. This becomes important if your array items can move (e.g. due to sorting), get inserted, or get deleted. A well-chosen key helps Dioxus infer what exactly has happened, and make the correct updates to the screen
-
+Now, if an item has already been rendered once, Dioxus can use the key to match it up later to make the correct updates – and avoid unnecessary work.
 
 NB: the language from this section is strongly borrowed from [React's guide on keys](https://reactjs.org/docs/lists-and-keys.html).
+
 ### Where to get your key
 
 Different sources of data provide different sources of keys:
 
 - _Data from a database_: If your data is coming from a database, you can use the database keys/IDs, which are unique by nature.
-- _Locally generated data_: If your data is generated and persisted locally (e.g. notes in a note-taking app), use an incrementing counter or a package like `uuid` when creating items.
+- _Locally generated data_: If your data is generated and persisted locally (e.g. notes in a note-taking app), keep track of keys along with your data. You can use an incrementing counter or a package like `uuid` to generate keys for new items – but make sure they stay the same for the item's lifetime.
+
+Remember: keys let Dioxus uniquely identify an item among its siblings. A well-chosen key provides more information than the position within the array. Even if the position changes due to reordering, the key lets Dioxus identify the item throughout its lifetime.
 
 ### Rules of keys
 
 - Keys must be unique among siblings. However, it’s okay to use the same keys for Elements in different arrays.
-- Keys must not change or that defeats their purpose! Don’t generate them while rendering.
+- An item's key must not change – **don’t generate them on the fly** while rendering. Otherwise, Dioxus will be unable to keep track of which item is which, and we're back to square one.
 
-### Why does Dioxus need keys?
+You might be tempted to use an item's index in the array 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. In all other cases, do not use the index for the key – it will lead to the performance problems described above.
 
-Imagine that files on your desktop didn’t have names. Instead, you’d refer to them by their order — the first file, the second file, and so on. You could get used to it, but once you delete a file, it would get confusing. The second file would become the first file, the third file would be the second file, and so on.
-
-File names in a folder and Element keys in an array serve a similar purpose. They let us uniquely identify an item between its siblings. A well-chosen key provides more information than the position within the array. Even if the position changes due to reordering, the key lets Dioxus identify the item throughout its lifetime.
-
-### Gotcha
-You might be tempted to use an item’s index in the array as its key. In fact, that’s what Dioxus will use if you don’t specify a key at all. But the order in which you render items will change over time if an item is inserted, deleted, or if the array gets reordered. Index as a key often leads to subtle and confusing bugs.
-
-Similarly, do not generate keys on the fly, `gen_random`. This will cause keys to never match up between renders, leading to all your components and DOM being recreated every time. Not only is this slow, but it will also lose any user input inside the list items. Instead, use a stable ID based on the data.
-
-Note that your components won’t receive 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:
+Note that if you pass the key to a [custom component](../components/index.md) 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:
 ```rust
-Post { key: "{key}", id: "{id}" }
+Post { key: "{key}", id: "{key}" }
 ```
 
 ## Moving on
@@ -171,4 +142,4 @@ In this section, we learned:
 - How to use iterator tools to filter and transform data
 - How to use keys to render lists efficiently
 
-Moving forward, we'll finally cover user input and interactivity.
+Moving forward, we'll learn more about attributes.

docs/guide/src/elements/propsmacro.md

@@ -1 +0,0 @@
-# The Props Macro

docs/guide/src/elements/special_attributes.md

@@ -0,0 +1,192 @@
+# Special Attributes
+
+Dioxus tries its hardest to stay close to React, but there are some divergences and "special behavior" that you should review before moving on.
+
+In this section, we'll cover special attributes built into Dioxus:
+
+- `dangerous_inner_html`
+- Boolean attributes
+- `prevent_default`
+<!-- - `..Attributes` -->
+- event handlers as string attributes
+- `value`, `checked`, and `selected`
+
+## The HTML escape hatch: `dangerous_inner_html`
+
+One thing you might've missed from React is the ability to render raw HTML directly to the DOM. If you're working with pre-rendered assets, output from templates, or output from a JS library, then you might want to pass HTML directly instead of going through Dioxus. In these instances, reach for `dangerous_inner_html`.
+
+For example, shipping a markdown-to-Dioxus converter might significantly bloat your final application size. Instead, you'll want to pre-render your markdown to HTML and then include the HTML directly in your output. We use this approach for the [Dioxus homepage](https://dioxuslabs.com):
+
+
+```rust
+fn BlogPost(cx: Scope) -> Element {
+    let contents = include_str!("../post.html");
+    cx.render(rsx!{
+        div {
+            class: "markdown",
+            dangerous_inner_html: "{contents}",
+        }
+    })
+}
+```
+
+> Note! This attribute is called "dangerous_inner_html" because it is **dangerous** to pass it data you don't trust. If you're not careful, you can easily expose cross-site-scripting (XSS) attacks to your users.
+> 
+> If you're handling untrusted input, make sure to sanitize your HTML before passing it into `dangerous_inner_html` – or just pass it to a Text Element to escape any HTML tags.
+
+
+## Boolean Attributes
+
+Most attributes, when rendered, will be rendered exactly as the input you provided. However, some attributes are considered "boolean" attributes and just their presence determines whether or not they affect the output. For these attributes, a provided value of `"false"` will cause them to be removed from the target element.
+
+So this RSX:
+
+```rust
+rsx!{
+    div {
+        hidden: "false",
+        "hello"
+    }
+}
+```
+wouldn't actually render the `hidden` attribute: 
+```html
+<div>hello</div> 
+```
+
+Not all attributes work like this however. *Only the following attributes* have this behavior:
+
+- `allowfullscreen`
+- `allowpaymentrequest`
+- `async`
+- `autofocus`
+- `autoplay`
+- `checked`
+- `controls`
+- `default`
+- `defer`
+- `disabled`
+- `formnovalidate`
+- `hidden`
+- `ismap`
+- `itemscope`
+- `loop`
+- `multiple`
+- `muted`
+- `nomodule`
+- `novalidate`
+- `open`
+- `playsinline`
+- `readonly`
+- `required`
+- `reversed`
+- `selected`
+- `truespeed`
+
+For any other attributes, a value of `"false"` will be sent directly to the DOM.
+
+## Stopping form input and navigation with `prevent_default`
+
+Currently, calling `prevent_default` on events in EventHandlers is not possible from Desktop/Mobile. Until this is supported, it's possible to prevent default using the `prevent_default` attribute. 
+
+> Note: you cannot conditionally prevent default with this approach. This is a limitation until synchronous event handling is available across the Webview boundary 
+
+To use `prevent_default`, simply attach the `prevent_default` attribute to a given element and set it to the name of the event handler you want to prevent default on. We can attach this attribute multiple times for multiple attributes.
+
+```rust
+rsx!{
+    input {
+        oninput: move |_| {},
+        prevent_default: "oninput",
+
+        onclick: move |_| {},
+        prevent_default: "onclick",
+    }
+}
+```
+<!-- 
+## Passing attributes into children: `..Attributes`
+
+> Note: this is an experimental, unstable feature not available in released versions of Dioxus. Feel free to skip this section.
+
+Just like Dioxus supports spreading component props into components, we also support spreading attributes into elements. This lets you pass any arbitrary attributes through components into elements.
+
+
+```rust
+#[derive(Props)]
+pub struct InputProps<'a> {
+    pub children: Element<'a>,
+    pub attributes: Attribute<'a>
+}
+
+pub fn StateInput<'a>(cx: Scope<'a, InputProps<'a>>) -> Element {
+    cx.render(rsx! (
+        input {
+            ..cx.props.attributes,
+            &cx.props.children,
+        }
+    ))
+}
+``` -->
+
+## Controlled inputs and `value`, `checked`, and `selected`
+
+In Dioxus, there is a distinction between controlled and uncontrolled inputs. Most inputs you'll use are controlled, meaning we both drive the `value` of the input and react to the `oninput`.
+
+Controlled components:
+```rust
+let value = use_state(&cx, || String::from("hello world"));
+
+rsx! {
+    input {
+        oninput: move |evt| value.set(evt.value.clone()),
+        value: "{value}",
+    }
+}
+```
+
+With uncontrolled inputs, we won't actually drive the value from the component. This has its advantages when we don't want to re-render the component when the user inputs a value. We could either select the element directly - something Dioxus doesn't support across platforms - or we could handle `oninput` and modify a value without causing an update:
+
+```rust
+let value = use_ref(&cx, || String::from("hello world"));
+
+rsx! {
+    input {
+        oninput: move |evt| *value.write_silent() = evt.value.clone(),
+        // no "value" is driven here – the input keeps track of its own value, and you can't change it
+    }
+}
+```
+
+## Strings for handlers like `onclick`
+
+For element fields that take a handler like `onclick` or `oninput`, Dioxus will let you attach a closure. Alternatively, you can also pass a string using normal attribute syntax and assign this attribute on the DOM.
+
+This lets you use JavaScript (only if your renderer can execute JavaScript).
+
+```rust
+rsx!{
+    div {
+        // handle oninput with rust
+        oninput: move |_| {},
+
+        // or handle oninput with javascript
+        oninput: "alert('hello world')",
+    }
+}
+
+```
+
+## Wrapping up
+
+In this chapter, we learned:
+- How to declare elements
+- How to conditionally render parts of your UI
+- How to render lists
+- Which attributes are "special"
+
+<!-- todo
+There's more to elements! For further reading, check out:
+
+- [Custom Elements]() 
+-->

docs/guide/src/elements/vnodes.md

@@ -56,7 +56,7 @@ With the default configuration, any Element defined within the `dioxus-html` cra
 
 ## Text Elements
 
-Dioxus also supports a special type of Element: Text. Text Elements do not accept children, but rather just string literals denoted with double quotes.
+Dioxus also supports a special type of Element: Text. Text Elements do not accept children, just a string literal denoted by double quotes.
 
 ```rust
 rsx! (
@@ -74,26 +74,26 @@ rsx! (
 )
 ```
 
-Text can also be formatted with any value that implements `Display`. We use [f-string formatting](https://docs.rs/fstrings/0.2.3/fstrings/) - a "coming soon" feature for stable Rust that is familiar for Python and JavaScript users:
+Text can also be formatted with any value that implements `Display`. We use the same syntax as Rust [format strings](https://www.rustnote.com/blog/format_strings.html) – which will already be familiar for Python and JavaScript users:
 
 ```rust
 let name = "Bob";
 rsx! ( "hello {name}" )
 ```
 
-Unfortunately, you cannot drop in arbitrary expressions directly into the string literal. In the cases where we need to compute a complex value, we'll want to use `format_args!` directly. Due to specifics of how the `rsx!` macro (we'll cover later), our call to `format_args` must be contained within curly braces *and* square braces.
+Unfortunately, you cannot drop in arbitrary expressions directly into the string literal. In the cases where we need to compute a complex value, we'll want to use `format_args!` directly. Due to specifics of the `rsx!` macro (which we'll cover later), our call to `format_args` must be contained within square braces.
 
 ```rust
-rsx!( {[format_args!("Hello {}", if enabled { "Jack" } else { "Bob" } )]} )
+rsx!( [format_args!("Hello {}", if enabled { "Jack" } else { "Bob" } )] )
 ```
 
-Alternatively, `&str` can be included directly, though it must be inside of an array:
+Alternatively, `&str` can be included directly, though it must also be inside square braces:
 
 ```rust
 rsx!( "Hello ",  [if enabled { "Jack" } else { "Bob" }] )
 ```
 
-This is different from React's way of generating arbitrary markup but fits within idiomatic Rust. 
+This is different from React's way of generating arbitrary markup but fits within idiomatic Rust.
 
 Typically, with Dioxus, you'll just want to compute your substrings outside of the `rsx!` call and leverage the f-string formatting:
 
@@ -104,7 +104,7 @@ rsx! ( "hello {name}" )
 
 ## Attributes
 
-Every Element in your User Interface will have some sort of properties that the renderer will use when drawing to the screen. These might inform the renderer if the component should be hidden, what its background color should be, or to give it a specific name or ID.
+Every Element in your user interface will have some sort of properties that the renderer will use when drawing to the screen. These might inform the renderer if the component should be hidden, what its background color should be, or to give it a specific name or ID.
 
 To do this, we use the familiar struct-style syntax that Rust provides:
 
@@ -123,7 +123,7 @@ Each field is defined as a method on the element in the `dioxus-html` crate. Thi
 1) file an issue if the attribute _should_ be enabled
 2) add a custom attribute on-the-fly
 
-To use custom attributes, simply put the attribute name in quotes followed by a colon:
+To use custom attributes, simply put the attribute name in quotes:
 
 ```rust
 rsx!(
@@ -138,11 +138,11 @@ rsx!(
 All element attributes must occur *before* child elements. The `rsx!` macro will throw an error if your child elements come before any of your attributes. If you don't see the error, try editing your Rust-Analyzer IDE setting to ignore macro-errors. This is a temporary workaround because Rust-Analyzer currently throws *two* errors instead of just the one we care about.
 
 ```rust
-// settings.json 
+// settings.json
 {
   "rust-analyzer.diagnostics.disabled": [
     "macro-error"
-  ],   
+  ],
 }
 ```
 
@@ -166,8 +166,8 @@ This chapter just scratches the surface on how Elements can be defined.
 
 We learned:
 - Elements are the basic building blocks of User Interfaces
-- Elements can contain other elements 
+- Elements can contain other elements
 - Elements can either be a named container or text
 - Some Elements have properties that the renderer can use to draw the UI to the screen
 
-Next, we'll compose Elements together to form components.
+Next, we'll compose Elements together using Rust-based logic.

docs/guide/src/final.md

@@ -15,7 +15,7 @@ With any luck, you followed through the "Putting it All Together" mini guide and
 
 Continuing on your journey with Dioxus, you can try a number of things:
 
-- Build a simple TUI app 
+- Build a simple TUI app
 - Publish your search engine app
 - Deploy a WASM app to GitHub
 - Design a custom hook
@@ -37,7 +37,7 @@ The core team is actively working on:
 
 - Declarative window management (via Tauri) for Desktop apps
 - Portals for Dioxus Core
-- Mobile support 
+- Mobile support
 - Integration with 3D renderers
 - Better async story (suspense, error handling)
 - Global state management

docs/guide/src/hello_world.md

@@ -1,6 +1,6 @@
 # "Hello, World" desktop app
 
-Let's put together a simple "hello world" desktop application to get acquainted with Dioxus. 
+Let's put together a simple "hello world" desktop application to get acquainted with Dioxus.
 
 In this chapter, we'll cover:
 
@@ -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
@@ -128,13 +128,13 @@ Finally, our app. Every component in Dioxus is a function that takes in `Context
 fn App(cx: Scope) -> Element {
     cx.render(rsx! {
         div { "Hello, world!" }
-    })    
+    })
 }
 ```
 
 ### What is this `Scope` object?
 
-Coming from React, the `Scope` object might be confusing. In React, you'll want to store data between renders with hooks. However, hooks rely on global variables which make them difficult to integrate in multi-tenant systems like server-rendering. 
+Coming from React, the `Scope` object might be confusing. In React, you'll want to store data between renders with hooks. However, hooks rely on global variables which make them difficult to integrate in multi-tenant systems like server-rendering.
 
 In Dioxus, you are given an explicit `Scope` object to control how the component renders and stores data. The `Scope` object provides a handful of useful APIs for features like suspense, rendering, and more.
 

docs/guide/src/interactivity/event_handlers.md

@@ -1 +1,3 @@
 # Event handlers
+
+> This section is currently under construction! 🏗

docs/guide/src/interactivity/hooks.md

@@ -1,5 +1,5 @@
 # Hooks and Internal State
- 
+
 In the [Adding Interactivity](./interactivity.md) section, we briefly covered the concept of hooks and state stored internal to components.
 
 In this section, we'll dive a bit deeper into hooks, exploring both the theory and mechanics.
@@ -10,7 +10,7 @@ In this section, we'll dive a bit deeper into hooks, exploring both the theory a
 
 Over the past several decades, computer scientists and engineers have long sought the "right way" of designing user interfaces. With each new programming language, novel features are unlocked that change the paradigm in which user interfaces are coded.
 
-Generally, a number of patterns have emerged, each with their own strengths and tradeoffs. 
+Generally, a number of patterns have emerged, each with their own strengths and tradeoffs.
 
 Broadly, there are two types of GUI structures:
 
@@ -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.
@@ -48,7 +48,7 @@ fn example(cx: Scope) -> Element {
 }
 ```
 
-Mechanically, each call to `use_hook` provides us with `&mut T` for a new value. 
+Mechanically, each call to `use_hook` provides us with `&mut T` for a new value.
 
 ```rust
 fn example(cx: Scope) -> Element {
@@ -76,6 +76,78 @@ This is why hooks called out of order will fail - if we try to downcast a `Hook<
 
 This pattern might seem strange at first, but it can be a significant upgrade over structs as blobs of state, which tend to be difficult to use in [Rust given the ownership system](https://rust-lang.github.io/rfcs/2229-capture-disjoint-fields.html).
 
+
+## 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)):
+
+- 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
+
+Examples of "no-nos" include:
+
+### ❌ Nested uses
+
+```rust
+// ❌ don't call use_hook or any `use_` function *inside* use_hook!
+cx.use_hook(|_| {
+    let name = cx.use_hook(|_| "ads");
+})
+
+// ✅ instead, move the first hook above
+let name = cx.use_hook(|_| "ads");
+cx.use_hook(|_| {
+    // do something with name here
+})
+```
+
+### ❌ Uses in conditionals
+```rust
+// ❌ don't call use_ in conditionals!
+if do_thing {
+    let name = use_state(&cx, || 0);
+}
+
+// ✅ instead, *always* call use_state but leave your logic
+let name = use_state(&cx, || 0);
+if do_thing {
+    // do thing with name here
+}
+```
+
+### ❌ Uses in loops
+
+
+```rust
+// ❌ Do not use hooks in loops!
+let mut nodes = vec![];
+
+for name in names {
+    let age = use_state(&cx, |_| 0);
+    nodes.push(cx.render(rsx!{
+        div { "{age}" }
+    }))
+}
+
+// ✅ Instead, consider refactoring your usecase into components 
+#[inline_props]
+fn Child(cx: Scope, name: String) -> Element {
+    let age = use_state(&cx, |_| 0);
+    cx.render(rsx!{ div { "{age}" } })
+}
+
+// ✅ Or, use a hashmap with use_ref
+```rust
+let ages = use_ref(&cx, |_| HashMap::new());
+
+names.iter().map(|name| {
+    let age = ages.get(name).unwrap();
+    cx.render(rsx!{ div { "{age}" } })
+})
+```
+
 ## Building new Hooks
 
 However, most hooks you'll interact with *don't* return an `&mut T` since this is not very useful in a real-world situation.
@@ -168,23 +240,15 @@ fn example(cx: Scope) -> Element {
 
 ```
 
+
 ## Hooks provided by the `Dioxus-Hooks` package
 
 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_ref](https://docs.rs/dioxus_hooks/use_ref) - 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_coroutine](https://docs.rs/dioxus_hooks/use_coroutine) - 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_callback](https://docs.rs/dioxus_hooks/use_callback) - store a callback that implements PartialEq for memoization
-- [use_provide_context](https://docs.rs/dioxus_hooks/use_provide_context) - expose state to descendent components
-- [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.
+- [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/latest/dioxus_hooks/fn.use_ref.html) - store non-clone state with a refcell
+- [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/latest/dioxus_hooks/fn.use_coroutine.html) - store a future that can be stopped/started/communicated with
+- [use_context_provider](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_context_provider.html) - expose state to descendent components
+- [use_context](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_context.html) - consume state provided by `use_provide_context`
+- [use_suspense](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_suspense.html)

docs/guide/src/interactivity/importanthooks.md

@@ -0,0 +1,127 @@
+# `use_state` and `use_ref`
+
+Most components you will write in Dioxus will need to store state somehow. For local state, we provide two very convenient hooks:
+
+- [use_state](https://docs.rs/dioxus-hooks/latest/dioxus_hooks/fn.use_state.html)
+- [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!
+
+## `use_state`
+
+The `use_state` hook is very similar to its React counterpart. When we use it, we get two values: 
+
+- The value itself as an `&T`
+- A handle to set the value `&UseState<T>`
+
+```rust
+let (count, set_count) = use_state(&cx, || 0);
+
+// then to set the count
+set_count(count + 1)
+```
+
+However, the `set_count` object is more powerful than it looks. You can use it as a closure, but you can also call methods on it to do more powerful operations.
+
+For instance, we can get a handle to the current value at any time:
+
+```rust
+let current: Rc<T> = set_count.current();
+```
+
+Or, we can get the inner handle to set the value
+
+```rust
+let setter: Rc<dyn Fn(T)> = set_count.setter();
+```
+
+Or, we can set a new value using the current value as a reference:
+
+```rust
+set_count.modify(|i| i + 1);
+```
+
+If the value is cheaply cloneable, then we can call `with_mut` to get a mutable reference to the value:
+
+```rust
+set_count.with_mut(|i| *i += 1);
+```
+
+Alternatively, we can call `make_mut` which gives us a `RefMut` to the underlying value:
+
+```rust
+*set_count.make_mut() += 1;
+```
+
+Plus, the `set_count` handle is cloneable into async contexts, so we can use it in futures.
+
+```rust
+// count up infinitely
+cx.spawn({
+    to_owned![set_count]; 
+    async move {
+        loop {
+            wait_ms(100).await;
+            set_count.modify(|i| i + 1);
+        }
+    }
+})
+```
+
+## `use_ref`
+
+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>>` (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.
+
+> Note: this is *not* exactly like its React counterpart since calling `write` will cause a re-render. For more React parity, use the `write_silent` method.
+
+To use the hook:
+
+```rust
+let names = use_ref(&cx, || vec!["susie", "calvin"]);
+```
+
+To read the hook values, use the `read()` method:
+
+```rust
+cx.render(rsx!{
+    ul {
+        names.read().iter().map(|name| {
+            rsx!{ "{name}" }
+        })
+    }
+})
+```
+
+And then to write into the hook value, use the `write` method:
+
+```rust
+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_silent().push("Transmogrifier");
+```
+
+Again, like `UseState`, the `UseRef` handle is clonable into async contexts:
+
+
+```rust
+// infinitely push calvin into the list
+cx.spawn({
+    to_owned![names]; 
+    async move {
+        loop {
+            wait_ms(100).await;
+            names.write().push("Calvin");
+        }
+    }
+})
+```

docs/guide/src/interactivity/index.md

@@ -1,6 +1,6 @@
 # Adding Interactivity
 
-So far, we've learned how to describe the structure and properties of our user interfaces. Unfortunately, they're static and quite a bit uninteresting. In this chapter, we're going to learn how to add interactivity through events, state, and tasks.
+So far, we've learned how to describe the structure and properties of our user interfaces. Unfortunately, they're static and quite uninteresting. In this chapter, we're going to learn how to add interactivity through events, state, and tasks.
 
 ## Primer on interactivity
 
@@ -10,7 +10,7 @@ Before we get too deep into the mechanics of interactivity, we should first unde
 
 Every app you'll ever build has some sort of information that needs to be rendered to the screen. Dioxus is responsible for translating your desired user interface to what is rendered to the screen. *You* are responsible for providing the content.
 
-The dynamic data in your user interface is called `State`. 
+The dynamic data in your user interface is called `State`.
 
 When you first launch your app with `dioxus::web::launch_with_props` you'll be providing the initial state. You need to declare the initial state *before* starting the app.
 
@@ -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 {
@@ -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)
 
@@ -64,7 +64,7 @@ The most common hook you'll use for storing state is `use_state`. `use_state` pr
 
 ```rust
 fn App(cx: Scope)-> Element {
-    let post = use_state(&cx, || {
+    let (post, set_post) = use_state(&cx, || {
         PostData {
             id: Uuid::new_v4(),
             score: 10,
@@ -73,21 +73,21 @@ fn App(cx: Scope)-> Element {
             url: String::from("dioxuslabs.com"),
             title: String::from("Hello, world"),
             original_poster: String::from("dioxus")
-        }        
+        }
     });
 
     cx.render(rsx!{
         Title { title: &post.title }
         Score { score: &post.score }
         // etc
-    })   
+    })
 }
 ```
 
-Whenever we have a new post that we want to render, we can call `set` on `post` and provide a new value:
+Whenever we have a new post that we want to render, we can call `set_post` and provide a new value:
 
 ```rust
-post.set(PostData {
+set_post(PostData {
     id: Uuid::new_v4(),
     score: 20,
     comment_count: 0,
@@ -102,7 +102,7 @@ We'll dive deeper into how exactly these hooks work later.
 
 ### When do I update my state?
 
-There are a few different approaches to choosing when to update your state. You can update your state in response to user-triggered events or asynchronously in some background task.    
+There are a few different approaches to choosing when to update your state. You can update your state in response to user-triggered events or asynchronously in some background task.
 
 ### Updating state in listeners
 
@@ -112,15 +112,15 @@ For example, let's say we provide a button to generate a new post. Whenever the
 
 ```rust
 fn App(cx: Scope)-> Element {
-    let post = use_state(&cx, || PostData::new());
+    let (post, set_post) = use_state(&cx, || PostData::new());
 
     cx.render(rsx!{
         button {
-            on_click: move |_| post.set(PostData::random())
+            on_click: move |_| set_post(PostData::random())
             "Generate a random post"
         }
         Post { props: &post }
-    })   
+    })
 }
 ```
 
@@ -128,7 +128,12 @@ We'll dive much deeper into event listeners later.
 
 ### Updating state asynchronously
 
-We can also update our state outside of event listeners with `coroutines`. `Coroutines` are asynchronous blocks of our component that have the ability to cleanly interact with values, hooks, and other data in the component. Since coroutines stick around between renders, the data in them must be valid for the `'static` lifetime. We must explicitly declare which values our task will rely on to avoid the `stale props` problem common in React.
+We can also update our state outside of event listeners with `futures` and `coroutines`. 
+
+- `Futures` are Rust's version of promises that can execute asynchronous work by an efficient polling system. We can submit new futures to Dioxus either through `push_future` which returns a `TaskId` or with `spawn`.
+- `Coroutines` are asynchronous blocks of our component that have the ability to cleanly interact with values, hooks, and other data in the component. 
+
+Since coroutines and Futures stick around between renders, the data in them must be valid for the `'static` lifetime. We must explicitly declare which values our task will rely on to avoid the `stale props` problem common in React.
 
 We can use tasks in our components to build a tiny stopwatch that ticks every second.
 
@@ -136,14 +141,14 @@ We can use tasks in our components to build a tiny stopwatch that ticks every se
 
 ```rust
 fn App(cx: Scope)-> Element {
-    let mut sec_elapsed = use_state(&cx, || 0);
+    let (elapsed, set_elapsed) = use_state(&cx, || 0);
 
     use_future(&cx, || {
-        let mut sec_elapsed = sec_elapsed.for_async();
+        to_owned![set_elapsed]; // explicitly capture this hook for use in async
         async move {
             loop {
                 TimeoutFuture::from_ms(1000).await;
-                sec_elapsed += 1;
+                set_elapsed.modify(|i| i + 1)
             }
         }
     });
@@ -152,17 +157,15 @@ fn App(cx: Scope)-> Element {
 }
 ```
 
-Using asynchronous code can be difficult! This is just scratching the surface of what's possible. We have an entire chapter on using async properly in your Dioxus Apps.
+Using asynchronous code can be difficult! This is just scratching the surface of what's possible. We have an entire chapter on using async properly in your Dioxus Apps. We have an entire section dedicated to using `async` properly later in this book.
 
 ### How do I tell Dioxus that my state changed?
 
-So far, we've only updated our state with `.set`. However, you might've noticed that we used `AddAssign` to increment the `sec_elapsed` value in our stopwatch example *without* calling set. This is because the `AddAssign` trait is implemented for `UseState<T>` (the wrapper around our value returned from `use_state`). Under the hood, whenever you try to mutate our value through `UseState`, you're actually calling `.set` which informs Dioxus that _this_ component needs to be updated on the screen.
-
 Whenever you inform Dioxus that the component needs to be updated, it will "render" your component again, storing the previous and current Elements in memory. Dioxus will automatically figure out the differences between the old and the new and generate a list of edits that the renderer needs to apply to change what's on the screen. This process is called "diffing":
 
 ![Diffing](../images/diffing.png)
 
-In React, the specifics of when a component gets re-rendered is somewhat blurry. With Dioxus, any component can mark itself as "dirty" through a method on `Context`: `needs_update`. In addition, any component can mark any _other_ component as dirty provided it knows the other component's ID with `needs_update_any`. 
+In React, the specifics of when a component gets re-rendered is somewhat blurry. With Dioxus, any component can mark itself as "dirty" through a method on `Context`: `needs_update`. In addition, any component can mark any _other_ component as dirty provided it knows the other component's ID with `needs_update_any`.
 
 With these building blocks, we can craft new hooks similar to `use_state` that let us easily tell Dioxus that new information is ready to be sent to the screen.
 
@@ -170,11 +173,37 @@ 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.
+- 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
+
+Though very similar to React, Dioxus is different in a few ways. Most notably, React components will not have a `Scope` parameter in the component declaration.
+
+Have you ever wondered how the `useState()` call works in React without a `this` object to actually store the state?
+
+```javascript
+// in React:
+function Component(props) {
+    // This state persists between component renders, but where does it live?
+    let [state, set_state] = useState(10);
+}
+```
+
+React uses global variables to store this information. However, global mutable variables must be carefully managed and are broadly discouraged in Rust programs. Because Dioxus needs to work with the rules of Rust it uses the `Scope` rather than a global state object to maintain some internal bookkeeping.
+
+That's what the `Scope` object is: a place for the Component to store state, manage listeners, and allocate elements. Advanced users of Dioxus will want to learn how to properly leverage the `Scope` object to build robust and performant extensions for Dioxus.
+
+```rust
+fn Post(cx: Scope<PostProps>) -> Element {
+    cx.render(rsx!("hello"))
+}
+```
 
 ## Moving On
 

docs/guide/src/interactivity/lifecycles.md

@@ -1 +1,3 @@
 # Lifecycle, updates, and effects
+
+> This section is currently under construction! 🏗

docs/guide/src/interactivity/user_input.md

@@ -1 +1,6 @@
 # User Input and Controlled Components
+
+Handling user input is one of the most common things your app will do, but it can be tricky
+
+
+> This section is currently under construction! 🏗

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,47 +15,61 @@ 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.
 
-### Installing Rust
+## Installing Rust
 
-Head over to [https://rust-lang.org](http://rust-lang.org) and install the Rust compiler. 
+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
 ```
 
-### Platform-Specific Dependencies
+## 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/)
 
-For linux users, we need the development libraries for libgtk.
+### Windows
+
+Windows Desktop apps depend on WebView2 - a library which should be installed in all modern Windows distributions. If you have Edge installed, then Dioxus will work fine. If you *don't* have Webview2, [then you can install it through Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/webview2/). MS provides 3 options:
+
+1. A tiny "evergreen" *bootstrapper* which will fetch an installer from Microsoft's CDN
+2. A tiny *installer* which will fetch Webview2 from Microsoft's CDN
+3. A statically linked version of Webview2 in your final binary for offline users
+
+For development purposes, use Option 1. 
+
+### Linux
+
+Webview Linux apps require WebkitGtk. When distributing, this can be part of your dependency tree in your `.rpm` or `.deb`. However, it's very likely that your users will already have WebkitGtk.
 
 ```
 sudo apt install libwebkit2gtk-4.0-dev libgtk-3-dev libappindicator3-dev
 ```
 
-When distributing onto older Windows platforms or less-mainstream 
+
+If you run into issues, make sure you have all the basics installed, as outlined in the [Tauri docs](https://tauri.studio/en/docs/get-started/setup-linux).
 
 
+### macOS
+
+Currently - everything for macOS is built right in! However, you might run into an issue if you're using nightly Rust due to some permissions issues in our Tao dependency (which have been resolved but not published).
 
 
-### Dioxus-CLI for dev server, bundling, etc.
+## 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
@@ -63,7 +77,7 @@ $ cargo install --force dioxus-cli
 
 We provide this 1st-party tool to save you from having to run potentially untrusted code every time you add a crate to your project - as is standard in the NPM ecosystem.
 
-### Suggested extensions
+## Suggested extensions
 
 If you want to keep your traditional `npm install XXX` workflow for adding packages, you might want to install `cargo-edit` and a few other fun `cargo` extensions:
 

docs/guide/src/state/errorhandling.md

@@ -9,3 +9,4 @@ fn App((cx, props): Component) -> Element {
 }
 ```
 
+> This section is currently under construction! 🏗

docs/guide/src/state/index.md

@@ -2,7 +2,27 @@
 
 Every app you'll build with Dioxus will have some sort of state that needs to be maintained and updated as your users interact with it. However, managing state can be particular challenging at times, and is frequently the source of bugs in many GUI frameworks.
 
-In this chapter, we'll cover the various ways to manage state, the appropriate terminology, various patterns, and then take an overview 
-
+In this chapter, we'll cover the various ways to manage state, the appropriate terminology, various patterns, and then take an overview
 
 ## Terminology 
+
+
+> This section is currently under construction! 🏗
+
+
+
+
+## Important hook: `use_state`
+
+
+
+
+
+## Important hook: `use_ref`
+
+
+
+
+## `provide_context` and `consume_context`
+
+## Terminology

docs/guide/src/state/liftingstate.md

@@ -1 +1,4 @@
 # Lifting State
+
+
+> This section is currently under construction! 🏗

docs/guide/src/state/localstate.md

@@ -1 +1,4 @@
 # Local State
+
+
+> This section is currently under construction! 🏗

docs/guide/src/state/sharedstate.md

@@ -1 +1,7 @@
 # Global State
+
+
+cx.provide_context()
+cx.consume_context()
+
+> This section is currently under construction! 🏗

docs/guide/src/tutorial/components.md

@@ -1 +1,3 @@
 # Defining Components
+
+This section is currently under construction! 🏗

docs/guide/src/tutorial/state.md

@@ -1 +1,3 @@
 # Defining State
+
+This section is currently under construction! 🏗

docs/guide/src/tutorial/structure.md

@@ -1 +1,4 @@
 # Structuring our app
+
+
+This section is currently under construction! 🏗

docs/guide/src/tutorial/styling.md

@@ -1 +1,4 @@
 # Styling
+
+
+This section is currently under construction! 🏗

docs/nightly/readme.md

@@ -0,0 +1 @@
+this directory is for deploying into

docs/router/.gitignore

@@ -0,0 +1 @@
+book

docs/router/book.toml

@@ -0,0 +1,6 @@
+[book]
+authors = ["Jonathan Kelley"]
+language = "en"
+multilingual = false
+src = "src"
+title = "Dioxus Router"

docs/router/src/SUMMARY.md

@@ -0,0 +1,3 @@
+# Summary
+
+- [Chapter 1](./chapter_1.md)

docs/router/src/chapter_1.md

@@ -0,0 +1,3 @@
+# Chapter 1
+
+The Dioxus Router is very important!!

examples/borrowed.rs

@@ -1,3 +1,5 @@
+#![allow(non_snake_case)]
+
 /*
 Dioxus manages borrow lifetimes for you. This means any child may borrow from its parent. However, it is not possible
 to hand out an &mut T to children - all props are consumed by &P, so you'd only get an &&mut T.

examples/calculator.rs

@@ -18,17 +18,19 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let display_value: UseState<String> = use_state(&cx, || String::from("0"));
+    let (display_value, set_display_value) = use_state(&cx, || String::from("0"));
 
     let input_digit = move |num: u8| {
-        if display_value.get() == "0" {
-            display_value.set(String::new());
+        if display_value == "0" {
+            set_display_value(String::new());
         }
-        display_value.modify().push_str(num.to_string().as_str());
+        set_display_value
+            .make_mut()
+            .push_str(num.to_string().as_str());
     };
 
     let input_operator = move |key: &str| {
-        display_value.modify().push_str(key);
+        set_display_value.make_mut().push_str(key);
     };
 
     cx.render(rsx!(
@@ -53,7 +55,7 @@ fn app(cx: Scope) -> Element {
                         KeyCode::Num9 => input_digit(9),
                         KeyCode::Backspace => {
                             if !display_value.len() != 0 {
-                                display_value.modify().pop();
+                                set_display_value.make_mut().pop();
                             }
                         }
                         _ => {}
@@ -65,21 +67,21 @@ fn app(cx: Scope) -> Element {
                                 button {
                                     class: "calculator-key key-clear",
                                     onclick: move |_| {
-                                        display_value.set(String::new());
-                                        if display_value != "" {
-                                            display_value.set("0".into());
+                                        set_display_value(String::new());
+                                        if !display_value.is_empty(){
+                                            set_display_value("0".into());
                                         }
                                     },
-                                    [if display_value == "" { "C" } else { "AC" }]
+                                    [if display_value.is_empty() { "C" } else { "AC" }]
                                 }
                                 button {
                                     class: "calculator-key key-sign",
                                     onclick: move |_| {
-                                        let temp = calc_val(display_value.get().clone());
+                                        let temp = calc_val(display_value.clone());
                                         if temp > 0.0 {
-                                            display_value.set(format!("-{}", temp));
+                                            set_display_value(format!("-{}", temp));
                                         } else {
-                                            display_value.set(format!("{}", temp.abs()));
+                                            set_display_value(format!("{}", temp.abs()));
                                         }
                                     },
                                     "±"
@@ -87,8 +89,8 @@ fn app(cx: Scope) -> Element {
                                 button {
                                     class: "calculator-key key-percent",
                                     onclick: move |_| {
-                                        display_value.set(
-                                            format!("{}", calc_val(display_value.get().clone()) / 100.0)
+                                        set_display_value(
+                                            format!("{}", calc_val(display_value.clone()) / 100.0)
                                         );
                                     },
                                     "%"
@@ -98,7 +100,7 @@ fn app(cx: Scope) -> Element {
                                 button { class: "calculator-key key-0", onclick: move |_| input_digit(0),
                                     "0"
                                 }
-                                button { class: "calculator-key key-dot", onclick: move |_| display_value.modify().push_str("."),
+                                button { class: "calculator-key key-dot", onclick: move |_| set_display_value.make_mut().push('.'),
                                     "●"
                                 }
                                 (1..10).map(|k| rsx!{
@@ -130,7 +132,7 @@ fn app(cx: Scope) -> Element {
                             }
                             button { class: "calculator-key key-equals",
                                 onclick: move |_| {
-                                    display_value.set(format!("{}", calc_val(display_value.get().clone())));
+                                    set_display_value(format!("{}", calc_val(display_value.clone())));
                                 },
                                 "="
                             }
@@ -175,7 +177,7 @@ fn calc_val(val: String) -> f64 {
 
     for c in val[start_index..].chars() {
         if c == '+' || c == '-' || c == '*' || c == '/' {
-            if temp != "" {
+            if !temp.is_empty() {
                 match &operation as &str {
                     "+" => result += temp.parse::<f64>().unwrap(),
                     "-" => result -= temp.parse::<f64>().unwrap(),
@@ -191,7 +193,7 @@ fn calc_val(val: String) -> f64 {
         }
     }
 
-    if temp != "" {
+    if !temp.is_empty() {
         match &operation as &str {
             "+" => result += temp.parse::<f64>().unwrap(),
             "-" => result -= temp.parse::<f64>().unwrap(),

examples/crm.rs

@@ -1,7 +1,7 @@
 /*
 Tiny CRM: A port of the Yew CRM example to Dioxus.
 */
-use dioxus::{events::FormEvent, prelude::*};
+use dioxus::prelude::*;
 
 fn main() {
     dioxus::desktop::launch(app);
@@ -20,11 +20,11 @@ pub struct Client {
 }
 
 fn app(cx: Scope) -> Element {
-    let scene = use_state(&cx, || Scene::ClientsList);
     let clients = use_ref(&cx, || vec![] as Vec<Client>);
-    let firstname = use_state(&cx, String::new);
-    let lastname = use_state(&cx, String::new);
-    let description = use_state(&cx, String::new);
+    let (scene, set_scene) = use_state(&cx, || Scene::ClientsList);
+    let (firstname, set_firstname) = use_state(&cx, String::new);
+    let (lastname, set_lastname) = use_state(&cx, String::new);
+    let (description, set_description) = use_state(&cx, String::new);
 
     cx.render(rsx!(
         body {
@@ -38,7 +38,7 @@ fn app(cx: Scope) -> Element {
 
             h1 {"Dioxus CRM Example"}
 
-            match *scene {
+            match scene {
                 Scene::ClientsList => rsx!(
                     div { class: "crm",
                         h2 { margin_bottom: "10px", "List of clients" }
@@ -51,8 +51,8 @@ fn app(cx: Scope) -> Element {
                                 })
                             )
                         }
-                        button { class: "pure-button pure-button-primary", onclick: move |_| scene.set(Scene::NewClientForm), "Add New" }
-                        button { class: "pure-button", onclick: move |_| scene.set(Scene::Settings), "Settings" }
+                        button { class: "pure-button pure-button-primary", onclick: move |_| set_scene(Scene::NewClientForm), "Add New" }
+                        button { class: "pure-button", onclick: move |_| set_scene(Scene::Settings), "Settings" }
                     }
                 ),
                 Scene::NewClientForm => rsx!(
@@ -63,19 +63,19 @@ fn app(cx: Scope) -> Element {
                                 class: "new-client firstname",
                                 placeholder: "First name",
                                 value: "{firstname}",
-                                oninput: move |e| firstname.set(e.value.clone())
+                                oninput: move |e| set_firstname(e.value.clone())
                             }
                             input {
                                 class: "new-client lastname",
                                 placeholder: "Last name",
                                 value: "{lastname}",
-                                oninput: move |e| lastname.set(e.value.clone())
+                                oninput: move |e| set_lastname(e.value.clone())
                             }
                             textarea {
                                 class: "new-client description",
                                 placeholder: "Description",
                                 value: "{description}",
-                                oninput: move |e| description.set(e.value.clone())
+                                oninput: move |e| set_description(e.value.clone())
                             }
                         }
                         button {
@@ -86,13 +86,13 @@ fn app(cx: Scope) -> Element {
                                     first_name: (*firstname).clone(),
                                     last_name: (*lastname).clone(),
                                 });
-                                description.set(String::new());
-                                firstname.set(String::new());
-                                lastname.set(String::new());
+                                set_description(String::new());
+                                set_firstname(String::new());
+                                set_lastname(String::new());
                             },
                             "Add New"
                         }
-                        button { class: "pure-button", onclick: move |_| scene.set(Scene::ClientsList),
+                        button { class: "pure-button", onclick: move |_| set_scene(Scene::ClientsList),
                             "Go Back"
                         }
                     }
@@ -108,7 +108,7 @@ fn app(cx: Scope) -> Element {
                         }
                         button {
                             class: "pure-button pure-button-primary",
-                            onclick: move |_| scene.set(Scene::ClientsList),
+                            onclick: move |_| set_scene(Scene::ClientsList),
                             "Go Back"
                         }
                     }

examples/custom_assets.rs

@@ -0,0 +1,14 @@
+use dioxus::prelude::*;
+
+fn main() {
+    dioxus::desktop::launch(app);
+}
+
+fn app(cx: Scope) -> Element {
+    cx.render(rsx! {
+        div {
+            "This should show an image:"
+            img { src: "examples/assets/logo.png", }
+        }
+    })
+}

examples/disabled.rs

@@ -5,12 +5,12 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let disabled = use_state(&cx, || false);
+    let (disabled, set_disabled) = use_state(&cx, || false);
 
     cx.render(rsx! {
         div {
             button {
-                onclick: move |_| disabled.set(!disabled.get()),
+                onclick: move |_| set_disabled(!disabled),
                 "click to " [if *disabled {"enable"} else {"disable"} ] " the lower button"
             }
 
@@ -18,11 +18,6 @@ fn app(cx: Scope) -> Element {
                 disabled: "{disabled}",
                 "lower button"
             }
-
-            input {
-                value: "false",
-            }
-
         }
     })
 }

examples/dog_app.rs

@@ -1,5 +1,6 @@
+#![allow(non_snake_case)]
+
 //! Render a bunch of doggos!
-//!
 
 use std::collections::HashMap;
 
@@ -15,7 +16,7 @@ struct ListBreeds {
 }
 
 fn app(cx: Scope) -> Element {
-    let fut = use_future(&cx, || async move {
+    let breeds = use_future(&cx, || async move {
         reqwest::get("https://dog.ceo/api/breeds/list/all")
             .await
             .unwrap()
@@ -23,9 +24,9 @@ fn app(cx: Scope) -> Element {
             .await
     });
 
-    let selected_breed = use_state(&cx, || None);
+    let (breed, set_breed) = use_state(&cx, || None);
 
-    match fut.value() {
+    match breeds.value() {
         Some(Ok(breeds)) => cx.render(rsx! {
             div {
                 h1 {"Select a dog breed!"}
@@ -35,14 +36,14 @@ fn app(cx: Scope) -> Element {
                         breeds.message.keys().map(|breed| rsx!(
                             li {
                                 button {
-                                    onclick: move |_| selected_breed.set(Some(breed.clone())),
+                                    onclick: move |_| set_breed(Some(breed.clone())),
                                     "{breed}"
                                 }
                             }
                         ))
                     }
                     div { flex: "50%",
-                        match &*selected_breed {
+                        match breed {
                             Some(breed) => rsx!( Breed { breed: breed.clone() } ),
                             None => rsx!("No Breed selected"),
                         }
@@ -50,7 +51,7 @@ fn app(cx: Scope) -> Element {
                 }
             }
         }),
-        Some(Err(e)) => cx.render(rsx! {
+        Some(Err(_e)) => cx.render(rsx! {
             div { "Error fetching breeds" }
         }),
         None => cx.render(rsx! {
@@ -61,7 +62,7 @@ fn app(cx: Scope) -> Element {
 
 #[inline_props]
 fn Breed(cx: Scope, breed: String) -> Element {
-    #[derive(serde::Deserialize)]
+    #[derive(serde::Deserialize, Debug)]
     struct DogApi {
         message: String,
     }
@@ -72,6 +73,12 @@ fn Breed(cx: Scope, breed: String) -> Element {
         reqwest::get(endpoint).await.unwrap().json::<DogApi>().await
     });
 
+    let (name, set_name) = use_state(&cx, || breed.clone());
+    if name != breed {
+        set_name(breed.clone());
+        fut.restart();
+    }
+
     cx.render(match fut.value() {
         Some(Ok(resp)) => rsx! {
             button {

examples/file_explorer.rs

@@ -15,7 +15,7 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let files = use_ref(&cx, || Files::new());
+    let files = use_ref(&cx, Files::new);
 
     rsx!(cx, div {
         link { href:"https://fonts.googleapis.com/icon?family=Material+Icons", rel:"stylesheet", }
@@ -28,8 +28,8 @@ fn app(cx: Scope) -> Element {
         }
         main {
             files.read().path_names.iter().enumerate().map(|(dir_id, path)| {
-                let path_end = path.split('/').last().unwrap_or(path.as_str());
-                let icon_type = if path_end.contains(".") {
+                let path_end = path.split('/').last().unwrap_or_else(|| path.as_str());
+                let icon_type = if path_end.contains('.') {
                     "description"
                 } else {
                     "folder"
@@ -56,7 +56,6 @@ fn app(cx: Scope) -> Element {
                 )
             })
         }
-
     })
 }
 

examples/filedragdrop.rs

@@ -2,9 +2,9 @@ use dioxus::prelude::*;
 
 fn main() {
     dioxus::desktop::launch_with_props(app, (), |c| {
-        c.with_file_drop_handler(|w, e| {
+        c.with_file_drop_handler(|_w, e| {
             println!("{:?}", e);
-            false
+            true
         })
     });
 }

examples/form.rs

@@ -0,0 +1,26 @@
+//! Forms
+//!
+//! Dioxus forms deviate slightly from html, automatically returning all named inputs
+//! in the "values" field
+
+use dioxus::prelude::*;
+
+fn main() {
+    dioxus::desktop::launch(app);
+}
+
+fn app(cx: Scope) -> Element {
+    cx.render(rsx! {
+        div {
+            h1 { "Form" }
+            form {
+                onsubmit: move |ev| println!("Submitted {:?}", ev.values),
+                oninput: move |ev| println!("Input {:?}", ev.values),
+                input { r#type: "text", name: "username" }
+                input { r#type: "text", name: "full-name" }
+                input { r#type: "password", name: "password" }
+                button { "Submit the form" }
+            }
+        }
+    })
+}

examples/framework_benchmark.rs

@@ -1,3 +1,5 @@
+#![allow(non_snake_case)]
+
 use dioxus::prelude::*;
 use rand::prelude::*;
 
@@ -15,9 +17,9 @@ impl Label {
     fn new_list(num: usize) -> Vec<Self> {
         let mut rng = SmallRng::from_entropy();
         let mut labels = Vec::with_capacity(num);
-        for _ in 0..num {
+        for x in 0..num {
             labels.push(Label {
-                key: 0,
+                key: x,
                 labels: [
                     ADJECTIVES.choose(&mut rng).unwrap(),
                     COLOURS.choose(&mut rng).unwrap(),
@@ -30,8 +32,8 @@ impl Label {
 }
 
 fn app(cx: Scope) -> Element {
-    let items = use_ref(&cx, || vec![]);
-    let selected = use_state(&cx, || None);
+    let items = use_ref(&cx, Vec::new);
+    let (selected, set_selected) = use_state(&cx, || None);
 
     cx.render(rsx! {
         div { class: "container",
@@ -69,7 +71,7 @@ fn app(cx: Scope) -> Element {
                         rsx!(tr { class: "{is_in_danger}",
                             td { class:"col-md-1" }
                             td { class:"col-md-1", "{item.key}" }
-                            td { class:"col-md-1", onclick: move |_| selected.set(Some(id)),
+                            td { class:"col-md-1", onclick: move |_| set_selected(Some(id)),
                                 a { class: "lbl", item.labels }
                             }
                             td { class: "col-md-1",

examples/hydration.rs

@@ -20,13 +20,13 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let val = use_state(&cx, || 0);
+    let (val, set_val) = use_state(&cx, || 0);
 
     cx.render(rsx! {
         div {
             h1 { "hello world. Count: {val}" }
             button {
-                onclick: move |_| *val.modify() += 1,
+                onclick: move |_| set_val(val + 1),
                 "click to increment"
             }
         }

examples/inputs.rs

@@ -2,8 +2,6 @@
 //!
 //! There is some conversion happening when input types are checkbox/radio/select/textarea etc.
 
-use std::sync::Arc;
-
 use dioxus::{events::FormEvent, prelude::*};
 
 fn main() {

examples/link.rs

@@ -0,0 +1,28 @@
+use dioxus::prelude::*;
+
+fn main() {
+    dioxus::desktop::launch(app);
+}
+
+fn app(cx: Scope) -> Element {
+    cx.render(rsx! (
+        div {
+            p {
+                a {
+                    href: "http://dioxuslabs.com/",
+                    "default link"
+                }
+            }
+            p {
+                a {
+                    href: "http://dioxuslabs.com/",
+                    prevent_default: "onclick",
+                    onclick: |_| {
+                        println!("Hello Dioxus");
+                    },
+                    "custom event link",
+                }
+            }
+        }
+    ))
+}

examples/nested_listeners.rs

@@ -0,0 +1,33 @@
+//! Nested Listeners
+//!
+//! This example showcases how to control event bubbling from child to parents.
+//!
+//! Both web and desktop support bubbling and bubble cancelation.
+
+use dioxus::prelude::*;
+
+fn main() {
+    dioxus::desktop::launch(app);
+}
+
+fn app(cx: Scope) -> Element {
+    cx.render(rsx! {
+        div {
+            onclick: move |_| println!("clicked! top"),
+            button {
+                onclick: move |_| println!("clicked! bottom propoate"),
+                "Propogate"
+            }
+            button {
+                onclick: move |evt| {
+                    println!("clicked! bottom no bubbling");
+                    evt.cancel_bubble();
+                },
+                "Dont propogate"
+            }
+            button {
+                "Does not handle clicks"
+            }
+        }
+    })
+}

examples/pattern_model.rs

@@ -1,3 +1,5 @@
+#![allow(non_snake_case)]
+
 //! Example: Calculator
 //! -------------------
 //!
@@ -30,7 +32,7 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let state = use_ref(&cx, || Calculator::new());
+    let state = use_ref(&cx, Calculator::new);
 
     cx.render(rsx! {
         style { [include_str!("./assets/calculator.css")] }
@@ -171,8 +173,8 @@ impl Calculator {
         }
     }
     fn input_dot(&mut self) {
-        if self.display_value.find(".").is_none() {
-            self.display_value.push_str(".");
+        if !self.display_value.contains('.') {
+            self.display_value.push('.');
         }
     }
     fn perform_operation(&mut self) {
@@ -190,8 +192,8 @@ impl Calculator {
         }
     }
     fn toggle_sign(&mut self) {
-        if self.display_value.starts_with("-") {
-            self.display_value = self.display_value.trim_start_matches("-").to_string();
+        if self.display_value.starts_with('-') {
+            self.display_value = self.display_value.trim_start_matches('-').to_string();
         } else {
             self.display_value = format!("-{}", self.display_value);
         }

examples/pattern_reducer.rs

@@ -15,16 +15,16 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let state = use_state(&cx, PlayerState::new);
+    let (state, set_state) = use_state(&cx, PlayerState::new);
 
     cx.render(rsx!(
         div {
             h1 {"Select an option"}
             h3 { "The radio is... " [state.is_playing()] "!" }
-            button { onclick: move |_| state.modify().reduce(PlayerAction::Pause),
+            button { onclick: move |_| set_state.make_mut().reduce(PlayerAction::Pause),
                 "Pause"
             }
-            button { onclick: move |_| state.modify().reduce(PlayerAction::Play),
+            button { onclick: move |_| set_state.make_mut().reduce(PlayerAction::Play),
                 "Play"
             }
         }

examples/readme.rs

@@ -9,13 +9,13 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let mut count = use_state(&cx, || 0);
+    let (count, set_count) = use_state(&cx, || 0);
 
     cx.render(rsx! {
         div {
             h1 { "High-Five counter: {count}" }
-            button { onclick: move |_| count += 1, "Up high!" }
-            button { onclick: move |_| count -= 1, "Down low!" }
+            button { onclick: move |_| set_count(count + 1), "Up high!" }
+            button { onclick: move |_| set_count(count - 1), "Down low!" }
         }
     })
 }

examples/router.rs

@@ -2,6 +2,7 @@
 
 use dioxus::prelude::*;
 use dioxus::router::{Link, Route, Router};
+use serde::Deserialize;
 
 fn main() {
     dioxus::desktop::launch(app);
@@ -18,7 +19,7 @@ fn app(cx: Scope) -> Element {
             Route { to: "/", "Home" }
             Route { to: "users",
                 Route { to: "/", "User list" }
-                Route { to: ":name", BlogPost {} }
+                Route { to: ":name", User {} }
              }
             Route { to: "blog"
                 Route { to: "/", "Blog list" }
@@ -30,7 +31,7 @@ fn app(cx: Scope) -> Element {
 }
 
 fn BlogPost(cx: Scope) -> Element {
-    let post = dioxus::router::use_route(&cx).last_segment()?;
+    let post = dioxus::router::use_route(&cx).last_segment();
 
     cx.render(rsx! {
         div {
@@ -40,14 +41,27 @@ fn BlogPost(cx: Scope) -> Element {
     })
 }
 
+#[derive(Deserialize)]
+struct Query {
+    bold: bool,
+}
+
 fn User(cx: Scope) -> Element {
-    let post = dioxus::router::use_route(&cx).last_segment()?;
-    let bold = dioxus::router::use_route(&cx).param::<bool>("bold");
+    let post = dioxus::router::use_route(&cx).last_segment();
+    let query = dioxus::router::use_route(&cx)
+        .query::<Query>()
+        .unwrap_or(Query { bold: false });
 
     cx.render(rsx! {
         div {
             h1 { "Reading blog post: {post}" }
             p { "example blog post" }
+
+            if query.bold {
+                rsx!{ b { "bold" } }
+            } else {
+                rsx!{ i { "italic" } }
+            }
         }
     })
 }

examples/rsx_compile_fail.rs

@@ -12,7 +12,7 @@ fn main() {
 }
 
 fn example(cx: Scope) -> Element {
-    let items = use_state(&cx, || {
+    let (items, _set_items) = use_state(&cx, || {
         vec![Thing {
             a: "asd".to_string(),
             b: 10,

examples/suspense.rs

@@ -1,3 +1,5 @@
+#![allow(non_snake_case)]
+
 //! Suspense in Dioxus
 //!
 //! Currently, `rsx!` does not accept futures as values. To achieve the functionality

examples/svg.rs

@@ -0,0 +1,101 @@
+// Thanks to @japsu and their project https://github.com/japsu/jatsi for the example!
+
+use dioxus::{events::MouseEvent, prelude::*};
+
+fn main() {
+    dioxus::desktop::launch(app);
+}
+
+fn app(cx: Scope) -> Element {
+    let (val, set_val) = use_state(&cx, || 5);
+
+    cx.render(rsx! {
+        div {
+            user_select: "none",
+            webkit_user_select: "none",
+            margin_left: "10%",
+            margin_right: "10%",
+            h1 { "Click die to generate a new value" }
+            div {
+                cursor: "pointer",
+                height: "80%",
+                width: "80%",
+                Die {
+                    value: *val,
+                    keep: true,
+                    onclick: move |_| {
+                        use rand::Rng;
+                        let mut rng = rand::thread_rng();
+                        set_val(rng.gen_range(1..6));
+                    }
+                }
+            }
+        }
+    })
+}
+
+#[derive(Props)]
+pub struct DieProps<'a> {
+    pub value: u64,
+    pub keep: bool,
+    pub onclick: EventHandler<'a, MouseEvent>,
+}
+
+const DOTS: [(i64, i64); 7] = [(-1, -1), (-1, -0), (-1, 1), (1, -1), (1, 0), (1, 1), (0, 0)];
+const DOTS_FOR_VALUE: [[bool; 7]; 6] = [
+    [false, false, false, false, false, false, true],
+    [false, false, true, true, false, false, false],
+    [false, false, true, true, false, false, true],
+    [true, false, true, true, false, true, false],
+    [true, false, true, true, false, true, true],
+    [true, true, true, true, true, true, false],
+];
+
+const OFFSET: i64 = 600;
+const DOT_RADIUS: &str = "200";
+const HELD_COLOR: &str = "#aaa";
+const UNHELD_COLOR: &str = "#ddd";
+
+// A six-sided die (D6) with dots.
+#[allow(non_snake_case)]
+pub fn Die<'a>(cx: Scope<'a, DieProps<'a>>) -> Element {
+    let &DieProps { value, keep, .. } = cx.props;
+
+    let active_dots = &DOTS_FOR_VALUE[(value - 1) as usize];
+    let fill = if keep { HELD_COLOR } else { UNHELD_COLOR };
+    let dots = DOTS
+        .iter()
+        .zip(active_dots.iter())
+        .filter(|(_, &active)| active)
+        .map(|((x, y), _)| {
+            let dcx = x * OFFSET;
+            let dcy = y * OFFSET;
+            rsx!(circle {
+                cx: "{dcx}",
+                cy: "{dcy}",
+                r: "{DOT_RADIUS}",
+                fill: "#333"
+            })
+        });
+
+    rsx!(cx,
+      svg {
+        onclick: move |e| cx.props.onclick.call(e),
+        prevent_default: "onclick",
+        "dioxus-prevent-default": "onclick",
+        class: "die",
+        view_box: "-1000 -1000 2000 2000",
+
+        rect {
+          x: "-1000",
+          y: "-1000",
+          width: "2000",
+          height: "2000",
+          rx: "{DOT_RADIUS}",
+          fill: "{fill}",
+        }
+
+        dots
+      }
+    )
+}

examples/tailwind.rs

@@ -1,3 +1,5 @@
+#![allow(non_snake_case)]
+
 //! Example: Basic Tailwind usage
 //!
 //! This example shows how an app might be styled with TailwindCSS.

examples/tasks.rs

@@ -10,16 +10,15 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let count = use_state(&cx, || 0);
+    let (count, set_count) = use_state(&cx, || 0);
 
     use_future(&cx, move || {
-        let count = UseState::for_async(&count);
-        // for_async![count];
+        let set_count = set_count.to_owned();
         async move {
-            // loop {
-            //     tokio::time::sleep(Duration::from_millis(1000)).await;
-            //     count += 1;
-            // }
+            loop {
+                tokio::time::sleep(Duration::from_millis(1000)).await;
+                set_count.modify(|f| f + 1);
+            }
         }
     });
 
@@ -27,7 +26,7 @@ fn app(cx: Scope) -> Element {
         div {
             h1 { "Current count: {count}" }
             button {
-                onclick: move |_| count.set(0),
+                onclick: move |_| set_count(0),
                 "Reset the count"
             }
         }

examples/todomvc.rs

@@ -19,15 +19,15 @@ pub struct TodoItem {
 }
 
 pub fn app(cx: Scope<()>) -> Element {
-    let todos = use_state(&cx, || im_rc::HashMap::<u32, TodoItem>::default());
-    let filter = use_state(&cx, || FilterState::All);
-    let draft = use_state(&cx, || "".to_string());
-    let mut todo_id = use_state(&cx, || 0);
+    let (todos, set_todos) = use_state(&cx, im_rc::HashMap::<u32, TodoItem>::default);
+    let (filter, set_filter) = use_state(&cx, || FilterState::All);
+    let (draft, set_draft) = use_state(&cx, || "".to_string());
+    let (todo_id, set_todo_id) = use_state(&cx, || 0);
 
     // Filter the todos based on the filter state
     let mut filtered_todos = todos
         .iter()
-        .filter(|(_, item)| match *filter {
+        .filter(|(_, item)| match filter {
             FilterState::All => true,
             FilterState::Active => !item.checked,
             FilterState::Completed => item.checked,
@@ -54,27 +54,25 @@ pub fn app(cx: Scope<()>) -> Element {
                         placeholder: "What needs to be done?",
                         value: "{draft}",
                         autofocus: "true",
-                        oninput: move |evt| draft.set(evt.value.clone()),
+                        oninput: move |evt| set_draft(evt.value.clone()),
                         onkeydown: move |evt| {
-                            if evt.key == "Enter" {
-                                if !draft.is_empty() {
-                                    todos.modify().insert(
-                                        *todo_id,
-                                        TodoItem {
-                                            id: *todo_id,
-                                            checked: false,
-                                            contents: draft.get().clone(),
-                                        },
-                                    );
-                                    todo_id += 1;
-                                    draft.set("".to_string());
-                                }
+                            if evt.key == "Enter" && !draft.is_empty() {
+                                set_todos.make_mut().insert(
+                                    *todo_id,
+                                    TodoItem {
+                                        id: *todo_id,
+                                        checked: false,
+                                        contents: draft.clone(),
+                                    },
+                                );
+                                set_todo_id(todo_id + 1);
+                                set_draft("".to_string());
                             }
                         }
                     }
                 }
                 ul { class: "todo-list",
-                    filtered_todos.iter().map(|id| rsx!(todo_entry( key: "{id}", id: *id, todos: todos  )))
+                    filtered_todos.iter().map(|id| rsx!(todo_entry( key: "{id}", id: *id, set_todos: set_todos  )))
                 }
                 (!todos.is_empty()).then(|| rsx!(
                     footer { class: "footer",
@@ -83,14 +81,14 @@ pub fn app(cx: Scope<()>) -> Element {
                             span {"{item_text} left"}
                         }
                         ul { class: "filters",
-                            li { class: "All", a { onclick: move |_| filter.set(FilterState::All), "All" }}
-                            li { class: "Active", a { onclick: move |_| filter.set(FilterState::Active), "Active" }}
-                            li { class: "Completed", a { onclick: move |_| filter.set(FilterState::Completed), "Completed" }}
+                            li { class: "All", a { onclick: move |_| set_filter(FilterState::All), "All" }}
+                            li { class: "Active", a { onclick: move |_| set_filter(FilterState::Active), "Active" }}
+                            li { class: "Completed", a { onclick: move |_| set_filter(FilterState::Completed), "Completed" }}
                         }
                         (show_clear_completed).then(|| rsx!(
                             button {
                                 class: "clear-completed",
-                                onclick: move |_| todos.modify().retain(|_, todo| todo.checked == false),
+                                onclick: move |_| set_todos.make_mut().retain(|_, todo| !todo.checked),
                                 "Clear completed"
                             }
                         ))
@@ -108,37 +106,42 @@ pub fn app(cx: Scope<()>) -> Element {
 
 #[derive(Props)]
 pub struct TodoEntryProps<'a> {
-    todos: UseState<'a, im_rc::HashMap<u32, TodoItem>>,
+    set_todos: &'a UseState<im_rc::HashMap<u32, TodoItem>>,
     id: u32,
 }
 
 pub fn todo_entry<'a>(cx: Scope<'a, TodoEntryProps<'a>>) -> Element {
-    let todo = &cx.props.todos[&cx.props.id];
-    let is_editing = use_state(&cx, || false);
+    let (is_editing, set_is_editing) = use_state(&cx, || false);
+
+    let todos = cx.props.set_todos.get();
+    let todo = &todos[&cx.props.id];
     let completed = if todo.checked { "completed" } else { "" };
-    let editing = if *is_editing.get() { "editing" } else { "" };
+    let editing = if *is_editing { "editing" } else { "" };
 
     rsx!(cx, li {
         class: "{completed} {editing}",
-        onclick: move |_| is_editing.set(true),
-        onfocusout: move |_| is_editing.set(false),
         div { class: "view",
             input { class: "toggle", r#type: "checkbox", id: "cbg-{todo.id}", checked: "{todo.checked}",
                 onchange: move |evt| {
-                    cx.props.todos.modify()[&cx.props.id].checked = evt.value.parse().unwrap();
+                    cx.props.set_todos.make_mut()[&cx.props.id].checked = evt.value.parse().unwrap();
                 }
             }
-            label { r#for: "cbg-{todo.id}", pointer_events: "none", "{todo.contents}" }
+            label {
+                r#for: "cbg-{todo.id}",
+                onclick: move |_| set_is_editing(true),
+                onfocusout: move |_| set_is_editing(false),
+                "{todo.contents}"
+            }
         }
         is_editing.then(|| rsx!{
             input {
                 class: "edit",
                 value: "{todo.contents}",
-                oninput: move |evt| cx.props.todos.modify()[&cx.props.id].contents = evt.value.clone(),
+                oninput: move |evt| cx.props.set_todos.make_mut()[&cx.props.id].contents = evt.value.clone(),
                 autofocus: "true",
                 onkeydown: move |evt| {
                     match evt.key.as_str() {
-                        "Enter" | "Escape" | "Tab" => is_editing.set(false),
+                        "Enter" | "Escape" | "Tab" => set_is_editing(false),
                         _ => {}
                     }
                 },

examples/window_event.rs

@@ -0,0 +1,97 @@
+use dioxus::prelude::*;
+
+fn main() {
+    dioxus::desktop::launch_cfg(app, |cfg| {
+        cfg.with_window(|w| w.with_title("BorderLess Demo").with_decorations(false))
+    });
+}
+
+fn app(cx: Scope) -> Element {
+    let window = dioxus::desktop::use_window(&cx);
+
+    // if you want to make window fullscreen, you need close the resizable.
+    // window.set_fullscreen(true);
+    // window.set_resizable(false);
+
+    let (fullscreen, set_fullscreen) = use_state(&cx, || false);
+    let (always_on_top, set_always_on_top) = use_state(&cx, || false);
+    let (decorations, set_decorations) = use_state(&cx, || false);
+
+    cx.render(rsx!(
+        link { href:"https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css", rel:"stylesheet" }
+        header {
+            class: "text-gray-400 bg-gray-900 body-font",
+            onmousedown: move |_| window.drag(),
+            div {
+                class: "container mx-auto flex flex-wrap p-5 flex-col md:flex-row items-center",
+                a { class: "flex title-font font-medium items-center text-white mb-4 md:mb-0",
+                    span { class: "ml-3 text-xl", "Dioxus"}
+                }
+                nav { class: "md:ml-auto flex flex-wrap items-center text-base justify-center" }
+                button {
+                    class: "inline-flex items-center bg-gray-800 border-0 py-1 px-3 focus:outline-none hover:bg-gray-700 rounded text-base mt-4 md:mt-0",
+                    onmousedown: |evt| evt.cancel_bubble(),
+                    onclick: move |_| window.set_minimized(true),
+                    "Minimize"
+                }
+                button {
+                    class: "inline-flex items-center bg-gray-800 border-0 py-1 px-3 focus:outline-none hover:bg-gray-700 rounded text-base mt-4 md:mt-0",
+                    onmousedown: |evt| evt.cancel_bubble(),
+                    onclick: move |_| {
+
+                        window.set_fullscreen(!fullscreen);
+                        window.set_resizable(*fullscreen);
+
+                        set_fullscreen(!fullscreen);
+                    },
+                    "Fullscreen"
+                }
+                button {
+                    class: "inline-flex items-center bg-gray-800 border-0 py-1 px-3 focus:outline-none hover:bg-gray-700 rounded text-base mt-4 md:mt-0",
+                    onmousedown: |evt| evt.cancel_bubble(),
+                    onclick: move |_| window.close(),
+                    "Close"
+                }
+            }
+        }
+        br {}
+        div {
+            class: "container mx-auto",
+            div {
+                class: "grid grid-cols-5",
+                div {
+                    button {
+                        class: "inline-flex items-center text-white bg-green-500 border-0 py-1 px-3 hover:bg-green-700 rounded",
+                        onmousedown: |evt| evt.cancel_bubble(),
+                        onclick: move |_| {
+                            window.set_always_on_top(!always_on_top);
+                            set_always_on_top(!always_on_top);
+                        },
+                        "Always On Top"
+                    }
+                }
+                div {
+                    button {
+                        class: "inline-flex items-center text-white bg-blue-500 border-0 py-1 px-3 hover:bg-green-700 rounded",
+                        onmousedown: |evt| evt.cancel_bubble(),
+                        onclick: move |_| {
+                            window.set_decorations(!decorations);
+                            set_decorations(!decorations);
+                        },
+                        "Set Decorations"
+                    }
+                }
+                div {
+                    button {
+                        class: "inline-flex items-center text-white bg-blue-500 border-0 py-1 px-3 hover:bg-green-700 rounded",
+                        onmousedown: |evt| evt.cancel_bubble(),
+                        onclick: move |_| {
+                            window.set_title("Dioxus Application");
+                        },
+                        "Change Title"
+                    }
+                }
+            }
+        }
+    ))
+}

examples/xss_safety.rs

@@ -9,7 +9,7 @@ fn main() {
 }
 
 fn app(cx: Scope) -> Element {
-    let contents = use_state(&cx, || {
+    let (contents, set_contents) = use_state(&cx, || {
         String::from("<script>alert(\"hello world\")</script>")
     });
 
@@ -20,7 +20,7 @@ fn app(cx: Scope) -> Element {
             input {
                 value: "{contents}",
                 r#type: "text",
-                oninput: move |e| contents.set(e.value.clone()),
+                oninput: move |e| set_contents(e.value.clone()),
             }
         }
     })