fix: parse response and update <ActionForm/> value even if it's redirected

* refactor(cargo-make): extract node

* refactor(cargo-make): extract lint

* refactor(counters_stable): remove redundant tasks

* docs(cargo-make): remove descriptions

* refactor(counters_stable): streamline stages

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,39 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**Leptos Dependencies**
+
+Please copy and paste the Leptos dependencies and features from your `Cargo.toml`.
+
+For example:
+```toml
+leptos = { version = "0.3", features = ["serde"] }
+leptos_axum = { version = "0.3", optional = true }
+leptos_meta = { version = "0.3"}
+leptos_router = { version = "0.3"}
+```
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,7 @@
+contact_links:
+  - name: Support or Question
+    url: https://github.com/leptos-rs/leptos/discussions/new?category=q-a
+    about: Do you need help figuring out how to do something, or want some help troubleshooting a bug? You can ask in our Discussions section.
+  - name: Discord Discussions
+    url: https://discord.gg/YdRAhS7eQB
+    about: For more informal, real-time conversation and support, you can join our Discord server.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/workflows/check-examples.yml

@@ -1,45 +1,46 @@
-name: Test
+name: Check Examples
 
 on:
   push:
-    branches: [main]
+    branches:
+      - main
   pull_request:
-    branches: [main]
-
-env:
-  CARGO_TERM_COLOR: always
+    branches:
+      - main
 
 jobs:
-  test:
-    name: Check examples ${{ matrix.os }} (using rustc ${{ matrix.rust }})
-    runs-on: ${{ matrix.os }}
-    strategy:
-      matrix:
-        rust:
-          - nightly
-        os:
-          - ubuntu-latest
-
+  setup:
+    name: Get Examples
+    runs-on: ubuntu-latest
+    outputs:
+      matrix: ${{ steps.set-matrix.outputs.matrix }}
     steps:
-      - uses: actions/checkout@v3
+      - name: Checkout
+        uses: actions/checkout@v3
 
-      - name: Setup Rust
-        uses: actions-rs/toolchain@v1
-        with:
-          toolchain: ${{ matrix.rust }}
-          override: true
-          components: rustfmt
+      - name: Install JQ Tool
+        uses: mbround18/install-jq@v1
 
-      - name: Add wasm32-unknown-unknown
-        run: rustup target add wasm32-unknown-unknown
+      - name: Set Matrix
+        id: set-matrix
+        run: |
+          examples=$(ls examples | 
+          awk '{print "examples/" $0}' | 
+          grep -v examples/README.md | 
+          grep -v examples/Makefile.toml | 
+          grep -v examples/cargo-make | 
+          grep -v examples/gtk | 
+          jq -R -s -c 'split("\n")[:-1]')
+          echo "Example Directories: $examples"
+          echo "matrix={\"directory\":$examples}" >> "$GITHUB_OUTPUT"
 
-      - name: Setup cargo-make
-        uses: davidB/rust-cargo-make@v1
-
-      - name: Cargo generate-lockfile
-        run: cargo generate-lockfile
-
-      - uses: Swatinem/rust-cache@v2
-
-      - name: Run cargo check on all examples
-        run: cargo make check-examples
+  matrix-job:
+    name: Check
+    needs: [setup]
+    strategy:
+      matrix: ${{ fromJSON(needs.setup.outputs.matrix) }}
+      fail-fast: false
+    uses: ./.github/workflows/run-example-task.yml
+    with:
+      directory: ${{ matrix.directory }}
+      cargo_make_task: "check"

.github/workflows/check-stable.yml

@@ -1,4 +1,4 @@
-name: Test
+name: Check stable
 
 on:
   push:
@@ -8,6 +8,7 @@ on:
 
 env:
   CARGO_TERM_COLOR: always
+  CARGO_REGISTRIES_CRATES_IO_PROTOCOL: sparse
 
 jobs:
   test:

.github/workflows/check.yml

@@ -1,4 +1,4 @@
-name: Test
+name: Check
 
 on:
   push:
@@ -8,6 +8,7 @@ on:
 
 env:
   CARGO_TERM_COLOR: always
+  CARGO_REGISTRIES_CRATES_IO_PROTOCOL: sparse
 
 jobs:
   test:

.github/workflows/fmt.yml

@@ -1,4 +1,4 @@
-name: Test
+name: Format
 
 on:
   push:

.github/workflows/run-example-task.yml

@@ -0,0 +1,95 @@
+name: Run Example Task
+
+on:
+  workflow_call:
+    inputs:
+      directory:
+        required: true
+        type: string
+      cargo_make_task:
+        required: true
+        type: string
+env:
+  CARGO_TERM_COLOR: always
+  CARGO_REGISTRIES_CRATES_IO_PROTOCOL: sparse
+
+jobs:
+  test:
+    name: Run ${{ matrix.os }} (using rustc ${{ matrix.rust }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        rust:
+          - nightly
+        os:
+          - ubuntu-latest
+
+    steps:
+      # Setup environment
+      - name: Install playwright browser dependencies
+        run: | 
+          sudo apt-get update
+          sudo apt-get install libegl1 libvpx7 libevent-2.1-7 libopus0 libopengl0 libwoff1 libharfbuzz-icu0 libgstreamer-plugins-base1.0-0 libgstreamer-gl1.0-0 libhyphen0 libmanette-0.2-0 libgles2 gstreamer1.0-libav                   
+
+      - uses: actions/checkout@v3
+
+      - name: Setup Rust
+        uses: actions-rs/toolchain@v1
+        with:
+          toolchain: ${{ matrix.rust }}
+          override: true
+          components: rustfmt
+
+      - name: Add wasm32-unknown-unknown
+        run: rustup target add wasm32-unknown-unknown
+
+      - name: Setup cargo-make
+        uses: davidB/rust-cargo-make@v1
+
+      - name: Cargo generate-lockfile
+        run: cargo generate-lockfile
+
+      - uses: Swatinem/rust-cache@v2
+
+      - name: Install Trunk
+        uses: jetli/trunk-action@v0.4.0
+        with:
+          version: "latest"
+
+      - name: Print Trunk Version
+        run: trunk --version
+
+      - name: Install Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18
+
+      - uses: pnpm/action-setup@v2
+        name: Install pnpm
+        id: pnpm-install
+        with:
+          version: 8
+          run_install: false
+
+      - name: Get pnpm store directory
+        id: pnpm-cache
+        run: |
+          echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
+
+      - uses: actions/cache@v3
+        name: Setup pnpm cache
+        with:
+          path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
+          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
+          restore-keys: |
+            ${{ runner.os }}-pnpm-store-
+
+      # Verify project
+      - name: ${{ inputs.cargo_make_task }}
+        run: |
+          if [ "${{ inputs.directory }}" = "INTERNAL" ]; then
+            echo No verification required
+          else
+            cd ${{ inputs.directory }}
+            cargo make --profile=github-actions ${{ inputs.cargo_make_task }}
+          fi

.github/workflows/test.yml

@@ -8,6 +8,7 @@ on:
 
 env:
   CARGO_TERM_COLOR: always
+  CARGO_REGISTRIES_CRATES_IO_PROTOCOL: sparse
 
 jobs:
   test:

.github/workflows/verify-all-examples.yml

@@ -0,0 +1,47 @@
+name: Verify All Examples
+
+on:
+  workflow_dispatch:
+  push:
+    tags:
+      - v*
+  schedule:
+    # Run once a day at 3:00 AM EST
+    - cron: "0 8 * * *"
+
+jobs:
+  setup:
+    name: Get Examples
+    runs-on: ubuntu-latest
+    outputs:
+      matrix: ${{ steps.set-matrix.outputs.matrix }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Install JQ Tool
+        uses: mbround18/install-jq@v1
+
+      - name: Set Matrix
+        id: set-matrix
+        run: |
+          examples=$(ls examples | 
+          awk '{print "examples/" $0}' | 
+          grep -v examples/README.md | 
+          grep -v examples/Makefile.toml | 
+          grep -v examples/cargo-make | 
+          grep -v examples/gtk | 
+          jq -R -s -c 'split("\n")[:-1]')
+          echo "Example Directories: $examples"
+          echo "matrix={\"directory\":$examples}" >> "$GITHUB_OUTPUT"
+
+  matrix-job:
+    name: Verify
+    needs: [setup]
+    strategy:
+      matrix: ${{ fromJSON(needs.setup.outputs.matrix) }}
+      fail-fast: false
+    uses: ./.github/workflows/run-example-task.yml
+    with:
+      directory: ${{ matrix.directory }}
+      cargo_make_task: "verify-flow"

.github/workflows/verify-changed-examples.yml

@@ -0,0 +1,71 @@
+name: Verify Changed Examples
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  setup:
+    name: Get Changes
+    runs-on: ubuntu-latest
+    outputs:
+      matrix: ${{ steps.set-matrix.outputs.matrix }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+
+      - name: Get all example files that changed
+        id: changed-files
+        uses: tj-actions/changed-files@v36
+        with:
+          files: |
+            examples
+
+      - name: List all example files that changed
+        run: echo '${{ steps.changed-files.outputs.all_changed_files }}'
+
+      - name: Get example project directories that changed
+        id: changed-dirs
+        uses: tj-actions/changed-files@v36
+        with:
+          dir_names: true
+          dir_names_max_depth: "2"
+          files: |
+            examples
+            !examples/cargo-make
+            !examples/gtk
+            !examples/Makefile.toml
+            !examples/README.md
+          json: true
+          quotepath: false
+
+      - name: List example project directories that changed
+        run: echo '${{ steps.changed-dirs.outputs.all_changed_files }}'
+
+      - name: Set Matrix
+        id: set-matrix
+        run: |
+          if [ ${{ steps.changed-files.outputs.any_changed }} == 'true' ]; then
+            # Create matrix with changed directories
+            echo "matrix={\"directory\":${{ steps.changed-dirs.outputs.all_changed_files }}}" >> "$GITHUB_OUTPUT"
+          else
+            # Create matrix with one item to prevent an empty vector error
+            echo "matrix={\"directory\":[\"INTERNAL\"]}" >> "$GITHUB_OUTPUT"
+          fi
+
+  matrix-job:
+    name: Verify
+    needs: [setup]
+    strategy:
+      matrix: ${{ fromJSON(needs.setup.outputs.matrix) }}
+      fail-fast: false
+    uses: ./.github/workflows/run-example-task.yml
+    with:
+      directory: ${{ matrix.directory }}
+      cargo_make_task: "verify-flow"

ARCHITECTURE.md

@@ -0,0 +1,231 @@
+# Architecture
+
+The goal of this document is to make it easier for contributors (and anyone
+who’s interested!) to understand the architecture of the framework.
+
+The whole Leptos framework is built from a series of layers. Each of these layers
+depends on the one below it, but each can be used independently from the ones
+built on top of it. While running a command like `cargo leptos new --git 
+leptos-rs/start` pulls in the whole framework, it’s important to remember that
+none of this is magic: each layer of that onion can be stripped away and
+reimplemented, configured, or adapted as needed, incrementally.
+
+> Everything that follows will assume you have a good working understanding
+> of the framework. There will be explanations of how some parts of it work
+> or fit together, but these are not docs. They assume you know what I’m
+> talking about.
+
+## The Reactive System: `leptos_reactive`
+
+The reactive system allows you to define dynamic values (signals),
+the relationships between them (derived signals and memos), and the side effects
+that run in response to them (effects).
+
+These concepts are completely independent of the DOM and can be used to drive
+any kind of reactive updates. The reactive system is based on the assumption
+that data is relatively cheap, and side effects are relatively expensive. Its
+goal is to minimize those side effects (like updating the DOM or making a network
+requests) as infrequently as possible.
+
+The reactive system is implemented as a single data structure that exists at
+runtime. In exchange for giving ownership over a value to the reactive system
+(by creating a signal), you receive a `Copy + 'static` identifier for its
+location in the reactive system. This enables most of the ergonomics of storing
+and sharing state, the use of callback closures without lifetime issues, etc.
+This is implemented by storing signals in a slotmap arena. The signal, memo,
+and scope types that are exposed to users simply carry around an index into that
+slotmap.
+
+> Items owned by the reactive system are dropped when the corresponding reactive
+> scope is dropped, i.e., when the component or section of the UI they’re
+> created in is removed. In a sense, Leptos implements a “garbage collector”
+> in which the lifetime of data is tied to the lifetime of the UI, not Rust’s
+> lexical scopes.
+
+## The DOM Renderer: `leptos_dom`
+
+The reactive system can be used to drive any kinds of side effects. One very
+common side effect is calling an imperative method, for example to update the
+DOM.
+
+The entire DOM renderer is built on top of the reactive system. It provides
+a builder pattern that can be used to create DOM elements dynamically.
+
+The renderer assumes, as a convention, that dynamic attributes, classes,
+styles, and children are defined by being passed a `Fn() -> T`, where their
+static equivalents just receive `T`. There’s nothing about this that is
+divinely ordained, but it’s a useful convention because it allows us to use
+zero-overhead derived signals as one of several ways to indicate dynamic
+content.
+
+`leptos_dom` also contains code for server-side rendering of the same
+UI views to HTML, either for out-of-order streaming (`src/ssr.rs`) or
+in-order streaming/async rendering (`src/ssr_in_order.rs`).
+
+## The Macros: `leptos_macro`
+
+It’s entirely possible to write Leptos code with no macros at all. The
+`view` and `component` macros, the most common, can be replaced by
+the builder syntax and simple functions (see the `counter_without_macros`
+example). But the macros enable a JSX-like syntax for describing views.
+
+This package also contains the `Params` derive macro used for typed
+queries and route params in the router.
+
+### Macro-based Optimizations
+
+Leptos 0.0.x was built much more heavily on macros. Taking its cues  
+from SolidJS, the `view` macro emitted different code for CSR, SSR, and
+hydration, optimizing each. The CSR/hydrate versions worked by compiling
+the view to an HTML template string, cloning that `<template>`, and
+traversing the DOM to set up reactivity. The SSR version worked similarly
+by compiling the static parts of the view to strings at compile time,
+reducing the amount of work that needed to be done on each request.
+
+Proc macros are hard, and this system was brittle. 0.1 introduced a
+more robust renderer, including the builder syntax, and rebuilt the `view`
+macro to use that builder syntax instead. It moved the optimized-but-buggy
+CSR version of the macro to a more-limited `template` macro.
+
+The `view` macro now separately optimizes SSR to use the same static-string
+optimizations, which (by our benchmarks) makes Leptos about 3-4x faster
+than similar Rust frontend frameworks in its HTML rendering.
+
+> The optimization is pretty straightforward. Consider the following view:
+>
+> ```rust
+> view! { cx,
+>   <main class="text-center">
+>     <div class="flex-col">
+>       <button>"Click me."</button>
+>       <p class="italic">"Text."</p>
+>     </div>
+>   </main>
+> }
+> ```
+>
+> Internally, with the builder this is something like
+>
+> ```rust
+> Element {
+>   tag: "main",
+>   attrs: vec![("class", "text-center")],
+>   children: vec![
+> 	  Element {
+> 		tag: "div",
+> 		attrs: vec![("class", "flex-col")],
+>       children: vec![
+>         Element {
+> 	        tag: "button",
+> 			attrs: vec![],
+> 			children: vec!["Click me"]
+>         },
+>         Element {
+> 	        tag: "p",
+> 			attrs: vec![("class", "italic")],
+> 			children: vec!["Text"]
+>         }
+>       ]
+> 	  }
+>   ]
+> }
+> ```
+>
+> This is a _bunch_ of small allocations and separate strings,
+> and in early 0.1 versions we used a `SmallVec` for children and
+> attributes and actually caused some stack overflows.
+>
+> But if you look at the view itself you can see that none of this
+> will _ever_ change. So we can actually optimize it at compile
+> time to a single `&'static str`:
+>
+> ```rust
+> r#"<main class="text-center">
+>     <div class="flex-col">
+>       <button>"Click me."</button>
+>       <p class="italic">"Text."</p>
+>     </div>
+>   </main>"#
+> ```
+
+## Server Functions (`leptos_server`, `server_fn`, and `server_fn_macro`)
+
+Server functions are a framework-agnostic shorthand for converting
+a function, whose body can only be run on the server, into an ad hoc
+REST API endpoint, and then generating code on the client to call that
+endpoint when you call the function.
+
+These are inspired by Solid/Bling’s `server$` functions, and there’s
+similar work being done in a number of other JavaScript frameworks.
+
+RPC is not a new idea, but these kinds of server functions may be.
+Specifically, by using web standards (defaulting to `POST`/`GET` requests
+with URL-encoded form data) they allow easy graceful degradation and the
+use of the `<form>` element.
+
+This function is split across three packages so that `server_fn` and
+`server_fn_macro` can be used by other frameworks. `leptos_server`
+includes some Leptos-specific reactive functionality (like actions).
+
+## `leptos`
+
+This package is built on and reexports most of the layers already
+mentioned, and implements a number of control-flow components (`<Show/>`,
+`<ErrorBoundary/>`, `<For/>`, `<Suspense/>`, `<Transition/>`) that use
+public APIs of the other packages.
+
+This is the main entrypoint for users, but is relatively light itself.
+
+## `leptos_meta`
+
+This package exists to allow you to work with tags normally found in
+the `<head>`, from within your components.
+
+It is implemented as a distinct package, rather than part of
+`leptos_dom`, on the principle that “what can be implemented in userland,
+should be.” The framework can be used without it, so it’s not in core.
+
+## `leptos_router`
+
+The router originates as a direct port of `solid-router`, which is the
+origin of most of its terminology, architecture, and route-matching logic.
+
+Subsequent developments (like animated routing, and managing route transitions
+given the lack of `useTransition` in Leptos) have caused it to diverge
+slightly from Solid’s exact code, but it is still very closely related.
+
+The core principle here is “nested routing,” dividing a single page
+into independently-rendered parts. This is described in some detail in the docs.
+
+Like `leptos_meta`, it is implemented as a distinct package, because it
+can be replaced with another router or with none. The framework can be used
+without it, so it’s not in core.
+
+## Server Integrations
+
+The server integrations are the most “frameworky” layer of the whole framework.
+These **do** assume the use of `leptos`, `leptos_router`, and `leptos_meta`.
+They specifically draw routing data from `leptos_router`, and inject the
+metadata from `leptos_meta` into the `<head>` appropriately.
+
+But of course, if you one day create `leptos-helmet` and `leptos-better-router`,
+you can create new server integrations that plug them into the SSR rendering
+methods from `leptos_dom` instead. Everything involved is quite modular.
+
+These packages essentially provide helpers that save the templates and user apps
+from including a huge amount of boilerplate to connect the various other packages
+correctly. Again, early versions of the framework examples are illustrative here
+for reference: they include large amounts of manual SSR route handling, etc.
+
+## `cargo-leptos` helpers
+
+`leptos_config` and `leptos_hot_reload` exist to support two different features
+of `cargo-leptos`, namely its configuration and its view-patching/hot-
+reloading features.
+
+It’s important to say that the main feature `cargo-leptos` remains its ability
+to conveniently tie together different build tooling, compiling your app to
+WASM for the browser, building the server version, pulling in SASS and
+Tailwind, etc. It is an extremely good build tool, not a magic formula. Each
+of the examples includes instructions for how to run the examples without
+`cargo-leptos`.

CODE_OF_CONDUCT.md

@@ -2,7 +2,7 @@
 
 _This Code of Conduct is based on the [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct)
 and the [Bevy Code of Conduct](https://raw.githubusercontent.com/bevyengine/bevy/main/CODE_OF_CONDUCT.md),
-which are adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) 
+which are adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling)
 and the [Contributor Covenant](https://www.contributor-covenant.org)._
 
 ## Our Pledge

CONTRIBUTING.md

@@ -0,0 +1,75 @@
+# Contributing to Leptos
+
+Thanks for your interesting in contributing to Leptos! This is a truly
+community-driven framework, and while we have a central maintainer (@gbj)
+large parts of the renderer, reactive system, and server integrations have
+all been written by other contributors. Contributions are always welcome.
+
+Participation in this community is governed by a [Code of Conduct](./CODE_OF_CONDUCT.md).
+Some of the most active conversations around development take place on our
+[Discord server](https://discord.gg/YdRAhS7eQB).
+
+This guide seeks to
+
+- describe some of the framework’s values (in a technical, not an ethical, sense)
+- provide a high-level overview of how the pieces of the framework fit together
+- orient you to the organization of this repository
+
+## Values
+
+Leptos, as a framework, reflects certain technical values:
+
+- **Expose primitives rather than imposing patterns.** Provide building blocks
+  that users can combine together to build up more complex behavior, rather than
+  requiring users follow certain templates, file formats, etc. e.g., components
+  are defined as functions, rather than a bespoke single-file component format.
+  The reactive system feeds into the rendering system, rather than being defined
+  by it.
+- **Bottom-up over top-down.** If you envision a user’s application as a tree
+  (like an HTML document), push meaning toward the leaves of the tree. e.g., If data
+  needs to be loaded, load it in a granular primitive (resources) rather than a
+  route- or page-level data structure.
+- **Performance by default.** When possible, users should only pay for what they
+  use. e.g., we don’t make all component props reactive by default. This is
+  because doing so would force the overhead of a reactive prop onto props that don’t
+  need to be reactive.
+- **Full-stack performance.** Performance can’t be limited to a single metric,
+  whether that’s a DOM rendering benchmark, WASM binary size, or server response
+  time. Use methods like HTTP streaming and progressive enhancement to enable
+  applications to load, become interactive, and respond as quickly as possible.
+- **Use safe Rust.** There’s no need for `unsafe` Rust in the framework, and
+  avoiding it at all costs reduces the maintenance and testing burden significantly.
+- **Embrace Rust semantics.** Especially in things like UI templating, use Rust
+  semantics or extend them in a predictable way with control-flow components
+  rather than overloading the meaning of Rust terms like `if` or `for` in a
+  framework-specific way.
+- **Enhance ergonomics without obfuscating what’s happening.** This is by far
+  the hardest to achieve. It’s often the case that adding additional layers to
+  improve DX (like a custom build tool and starter templates) comes across as
+  “too magic” to some people who haven’t had to build the same things manually.
+  When possible, make it easier to see how the pieces fit together, without
+  sacrificing the improved DX.
+
+## Processes
+
+We do not have PR templates or formal processes for approving PRs. But there
+are a few guidelines that will make it a better experience for everyone:
+
+- Run `cargo fmt` before submitting your code.
+- Keep PRs limited to addressing one feature or one issue, in general. In some
+  cases (e.g., “reduce allocations in the reactive system”) this may touch a number
+  of different areas, but is still conceptually one thing.
+- If it’s an unsolicited PR not linked to an open issue, please include a
+  specific explanation for what it’s trying to achieve. For example: “When I
+  was trying to deploy my app under _circumstances X_, I found that the way
+  _function Z_ was implemented caused _issue Z_. This PR should fix that by
+  _solution._”
+- Our CI tests every PR against all the existing examples, sometimes requiring
+  compilation for both server and client side, etc. It’s thorough but slow. If
+  you want to run CI locally to reduce frustration, you can do that by installing
+  `cargo-make` and using `cargo make check && cargo make test && cargo make
+check-examples`.
+
+## Architecture
+
+See [ARCHITECTURE.md](./ARCHITECTURE.md).

Cargo.toml

@@ -1,4 +1,5 @@
 [workspace]
+resolver = "2"
 members = [
   # core
   "leptos",
@@ -25,22 +26,22 @@ members = [
 exclude = ["benchmarks", "examples"]
 
 [workspace.package]
-version = "0.3.0"
+version = "0.4.2"
 
 [workspace.dependencies]
-leptos = { path = "./leptos", default-features = false, version = "0.3.0" }
-leptos_dom = { path = "./leptos_dom", default-features = false, version = "0.3.0" }
-leptos_hot_reload = { path = "./leptos_hot_reload", version = "0.3.0" }
-leptos_macro = { path = "./leptos_macro", default-features = false, version = "0.3.0" }
-leptos_reactive = { path = "./leptos_reactive", default-features = false, version = "0.3.0" }
-leptos_server = { path = "./leptos_server", default-features = false, version = "0.3.0" }
-server_fn = { path = "./server_fn", default-features = false, version = "0.3.0" }
-server_fn_macro = { path = "./server_fn_macro", default-features = false, version = "0.3.0" }
-server_fn_macro_default = { path = "./server_fn/server_fn_macro_default", default-features = false, version = "0.3.0" }
-leptos_config = { path = "./leptos_config", default-features = false, version = "0.3.0" }
-leptos_router = { path = "./router", version = "0.3.0" }
-leptos_meta = { path = "./meta", default-features = false, version = "0.3.0" }
-leptos_integration_utils = { path = "./integrations/utils", version = "0.3.0" }
+leptos = { path = "./leptos", version = "0.4.2" }
+leptos_dom = { path = "./leptos_dom", version = "0.4.2" }
+leptos_hot_reload = { path = "./leptos_hot_reload", version = "0.4.2" }
+leptos_macro = { path = "./leptos_macro", version = "0.4.2" }
+leptos_reactive = { path = "./leptos_reactive", version = "0.4.2" }
+leptos_server = { path = "./leptos_server", version = "0.4.2" }
+server_fn = { path = "./server_fn", version = "0.4.2" }
+server_fn_macro = { path = "./server_fn_macro", version = "0.4.2" }
+server_fn_macro_default = { path = "./server_fn/server_fn_macro_default", version = "0.4.2" }
+leptos_config = { path = "./leptos_config", version = "0.4.2" }
+leptos_router = { path = "./router", version = "0.4.2" }
+leptos_meta = { path = "./meta", version = "0.4.2" }
+leptos_integration_utils = { path = "./integrations/utils", version = "0.4.2" }
 
 [profile.release]
 codegen-units = 1

Makefile.toml

@@ -45,6 +45,8 @@ dependencies = [
 	{ name = "check", path = "examples/fetch" },
 	{ name = "check", path = "examples/hackernews" },
 	{ name = "check", path = "examples/hackernews_axum" },
+	{ name = "check", path = "examples/js-framework-benchmark" },
+	{ name = "check", path = "examples/leptos-tailwind-axum" },
 	{ name = "check", path = "examples/login_with_token_csr_only" },
 	{ name = "check", path = "examples/parent_child" },
 	{ name = "check", path = "examples/router" },
@@ -54,6 +56,7 @@ dependencies = [
 	{ name = "check", path = "examples/ssr_modes_axum" },
 	{ name = "check", path = "examples/tailwind" },
 	{ name = "check", path = "examples/tailwind_csr_trunk" },
+	{ name = "check", path = "examples/timer" },
 	{ name = "check", path = "examples/todo_app_sqlite" },
 	{ name = "check", path = "examples/todo_app_sqlite_axum" },
 	{ name = "check", path = "examples/todo_app_sqlite_viz" },
@@ -94,23 +97,15 @@ args = ["+nightly", "doc"]
 cwd = "leptos_macro/example"
 install_crate = false
 
-[tasks.test-examples]
-description = "Run all unit and web tests for examples"
+[tasks.ci-examples]
 cwd = "examples"
 command = "cargo"
-args = ["make", "test-unit-and-web"]
-
-[tasks.verify-examples]
-description = "Run all quality checks and tests for examples"
-cwd = "examples"
-command = "cargo"
-args = ["make", "verify-flow"]
+args = ["make", "ci-clean"]
 
 [tasks.clean-examples]
-description = "Clean all example projects"
 cwd = "examples"
 command = "cargo"
-args = ["make", "clean-all"]
+args = ["make", "clean"]
 
 [env]
 RUSTFLAGS = ""

README.md

@@ -8,6 +8,8 @@
 [![Discord](https://img.shields.io/discord/1031524867910148188?color=%237289DA&label=discord)](https://discord.gg/YdRAhS7eQB)
 [![Matrix](https://img.shields.io/badge/Matrix-leptos-grey?logo=matrix&labelColor=white&logoColor=black)](https://matrix.to/#/#leptos:matrix.org)
 
+[Website](https://leptos.dev) | [Book](https://leptos-rs.github.io/leptos/) | [Docs.rs](https://docs.rs/leptos/latest/leptos/) | [Playground](https://codesandbox.io/p/sandbox/leptos-rtfggt?file=%2Fsrc%2Fmain.rs%3A1%2C1) | [Discord](https://discord.gg/YdRAhS7eQB)
+
 # Leptos
 
 ```rust
@@ -66,7 +68,7 @@ Here are some resources for learning more about Leptos:
 
 ## `nightly` Note
 
-Most of the examples assume you’re using `nightly` version of Rust. For this, you can either set your toolchain globally or on per-project basis.
+Most of the examples assume you’re using `nightly` version of Rust and the `nightly` feature of Leptos. To use `nightly` Rust, you can either set your toolchain globally or on per-project basis.
 
 To set `nightly` as a default toolchain for all projects (and add the ability to compile Rust to WebAssembly, if you haven’t already):
 
@@ -84,13 +86,9 @@ channel = "nightly"
 targets = ["wasm32-unknown-unknown"]
 ```
 
-If you’re on `stable`, note the following:
+The `nightly` feature enables the function call syntax for accessing and setting signals, as opposed to `.get()` and `.set()`. This leads to a consistent mental model in which accessing a reactive value of any kind (a signal, memo, or derived signal) is always represented as a function call. This is only possible with nightly Rust and the `nightly` feature.
 
-1. You need to enable the `"stable"` flag in `Cargo.toml`: `leptos = { version = "0.2", features = ["stable"] }`
-2. `nightly` enables the function call syntax for accessing and setting signals. If you’re using `stable`,
-   you’ll just call `.get()`, `.set()`, or `.update()` manually. Check out the
-   [`counters_stable` example](https://github.com/leptos-rs/leptos/blob/main/examples/counters_stable/src/main.rs)
-   for examples of the correct API.
+> Note: The `nightly` feature is present on the main branch version right now, but not in 0.3.x. For 0.3.x, nightly is the default and `stable` has a special feature.
 
 ## `cargo-leptos`
 

benchmarks/Cargo.toml

@@ -5,7 +5,7 @@ edition = "2021"
 
 [dependencies]
 l021 = { package = "leptos", version = "0.2.1" }
-leptos = { path = "../leptos", default-features = false, features = ["ssr"] }
+leptos = { path = "../leptos", features = ["ssr"] }
 sycamore = { version = "0.8", features = ["ssr"] }
 yew = { git = "https://github.com/yewstack/yew", features = ["ssr"] }
 tokio-test = "0.4"

docs/book/src/02_getting_started.md

@@ -25,13 +25,18 @@ cargo init leptos-tutorial
 > ```bash
 > rustup toolchain install nightly
 > rustup default nightly
-> rustup target add wasm32-unknown-unknown
 > ```
 
+Make sure you've added the `wasm32-unknown-unknown` target do that Rust can compile your code to WebAssembly to run in the browser. 
+
+```bash
+rustup target add wasm32-unknown-unknown
+```
+
 `cd` into your new `leptos-tutorial` project and add `leptos` as a dependency
 
 ```bash
-cargo add leptos
+cargo add leptos --features=csr,nightly # or just csr if you're using stable Rust
 ```
 
 Create a simple `index.html` in the root of the `leptos-tutorial` directory

docs/book/src/14_create_effect.md

@@ -1,112 +1 @@
-# Responding to Changes with `create_effect`
-
-Believe it or not, we’ve made it this far without having mentioned half of the reactive system: effects.
-
-Leptos is built on a fine-grained reactive system, which means that individual reactive values (“signals,” sometimes known as observables) trigger rerunning the code that reacts to them (“effects,” sometimes known as observers). These two halves of the reactive system are inter-dependent. Without effects, signals can change within the reactive system but never be observed in a way that interacts with the outside world. Without signals, effects run once but never again, as there’s no observable value to subscribe to.
-
-[`create_effect`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_effect.html) takes a function as its argument. It immediately runs the function. If you access any reactive signal inside that function, it registers the fact that the effect depends on that signal with the reactive runtime. Whenever one of the signals that the effect depends on changes, the effect runs again.
-
-```rust
-let (a, set_a) = create_signal(cx, 0);
-let (b, set_b) = create_signal(cx, 0);
-
-create_effect(cx, move |_| {
-  // immediately prints "Value: 0" and subscribes to `a`
-  log::debug!("Value: {}", a());
-});
-```
-
-The effect function is called with an argument containing whatever value it returned the last time it ran. On the initial run, this is `None`.
-
-By default, effects **do not run on the server**. This means you can call browser-specific APIs within the effect function without causing issues. If you need an effect to run on the server, use [`create_isomorphic_effect`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_isomorphic_effect.html).
-
-## Autotracking and Dynamic Dependencies
-
-If you’re familiar with a framework like React, you might notice one key difference. React and similar frameworks typically require you to pass a “dependency array,” an explicit set of variables that determine when the effect should rerun.
-
-Because Leptos comes from the tradition of synchronous reactive programming, we don’t need this explicit dependency list. Instead, we automatically track dependencies depending on which signals are accessed within the effect.
-
-This has two effects (no pun intended). Dependencies are
-
-1. **Automatic**: You don’t need to maintain a dependency list, or worry about what should or shouldn’t be included. The framework simply tracks which signals might cause the effect to rerun, and handles it for you.
-2. **Dynamic**: The dependency list is cleared and updated every time the effect runs. If your effect contains a conditional (for example), only signals that are used in the current branch are tracked. This means that effects rerun the absolute minimum number of times.
-
-> If this sounds like magic, and if you want a deep dive into how automatic dependency tracking works, [check out this video](https://www.youtube.com/watch?v=GWB3vTWeLd4). (Apologies for the low volume!)
-
-## Effects as Zero-Cost-ish Abstraction
-
-While they’re not a “zero-cost abstraction” in the most technical sense—they require some additional memory use, exist at runtime, etc.—at a higher level, from the perspective of whatever expensive API calls or other work you’re doing within them, effects are a zero-cost abstraction. They rerun the absolute minimum number of times necessary, given how you’ve described them.
-
-Imagine that I’m creating some kind of chat software, and I want people to be able to display their full name, or just their first name, and to notify the server whenever their name changes:
-
-```rust
-let (first, set_first) = create_signal(cx, String::new());
-let (last, set_last) = create_signal(cx, String::new());
-let (use_last, set_use_last) = create_signal(cx, true);
-
-// this will add the name to the log
-// any time one of the source signals changes
-create_effect(cx, move |_| {
-    log(
-        cx,
-        if use_last() {
-            format!("{} {}", first(), last())
-        } else {
-            first()
-        },
-    )
-});
-```
-
-If `use_last` is `true`, effect should rerun whenever `first`, `last`, or `use_last` changes. But if I toggle `use_last` to `false`, a change in `last` will never cause the full name to change. In fact, `last` will be removed from the dependency list until `use_last` toggles again. This saves us from sending multiple unnecessary requests to the API if I change `last` multiple times while `use_last` is still `false`.
-
-## To `create_effect`, or not to `create_effect`?
-
-Effects are intended to run _side-effects_ of the system, not to synchronize state _within_ the system. In other words: don’t write to signals within effects.
-
-If you need to define a signal that depends on the value of other signals, use a derived signal or [`create_memo`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_memo.html).
-
-If you need to synchronize some reactive value with the non-reactive world outside—like a web API, the console, the filesystem, or the DOM—create an effect.
-
-> If you’re curious for more information about when you should and shouldn’t use `create_effect`, [check out this video](https://www.youtube.com/watch?v=aQOFJQ2JkvQ) for a more in-depth consideration!
-
-## Effects and Rendering
-
-We’ve managed to get this far without mentioning effects because they’re built into the Leptos DOM renderer. We’ve seen that you can create a signal and pass it into the `view` macro, and it will update the relevant DOM node whenever the signal changes:
-
-```rust
-let (count, set_count) = create_signal(cx, 0);
-
-view! { cx,
-    <p>{count}</p>
-}
-```
-
-This works because the framework essentially creates an effect wrapping this update. You can imagine Leptos translating this view into something like this:
-
-```rust
-let (count, set_count) = create_signal(cx, 0);
-
-// create a DOM element
-let p = create_element("p");
-
-// create an effect to reactively update the text
-create_effect(cx, move |prev_value| {
-    // first, access the signal’s value and convert it to a string
-    let text = count().to_string();
-
-    // if this is different from the previous value, update the node
-    if prev_value != Some(text) {
-        p.set_text_content(&text);
-    }
-
-    // return this value so we can memoize the next update
-    text
-});
-```
-
-Every time `count` is updated, this effect wil rerun. This is what allows reactive, fine-grained updates to the DOM.
-
-[Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/serene-thompson-40974n?file=%2Fsrc%2Fmain.rs&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D)
-
-<iframe src="https://codesandbox.io/p/sandbox/serene-thompson-40974n?file=%2Fsrc%2Fmain.rs&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D" width="100%" height="1000px" style="max-height: 100vh"></iframe>
+# Responding to Changes with create_effect

docs/book/src/15_global_state.md

@@ -1,8 +1,8 @@
 # Global State Management
 
-So far, we've only been working with local state in components
-We've only seen how to communicate between parent and child components
-But there are also more general ways to manage global state
+So far, we've only been working with local state in components, and we’ve seen how to coordinate state between parent and child components. On occasion, there are times where people look for a more general solution for global state management that can work throughout an application.
+
+In general, **you do not need this chapter.** The typical pattern is to compose your application out of components, each of which manages its own local state, not to store all state in a global structure. However, there are some cases (like theming, saving user settings, or sharing data between components in different parts of your UI) in which you may want to use some kind of global state management.
 
 The three best approaches to global state are
 
@@ -12,19 +12,17 @@ The three best approaches to global state are
 
 ## Option #1: URL as Global State
 
-The next few sections of the tutorial will be about the router.
-So for now, we'll just look at options #2 and #3.
+In many ways, the URL is actually the best way to store global state. It can be accessed from any component, anywhere in your tree. There are native HTML elements like `<form>` and `<a>` that exist solely to update the URL. And it persists across page reloads and between devices; you can share a URL with a friend or send it from your phone to your laptop and any state stored in it will be replicated.
+
+The next few sections of the tutorial will be about the router, and we’ll get much more into these topics.
+
+But for now, we'll just look at options #2 and #3.
 
 ## Option #2: Passing Signals through Context
 
-In virtual DOM libraries like React, using the Context API to manage global
-state is a bad idea: because the entire app exists in a tree, changing
-some value provided high up in the tree can cause the whole app to render.
+In the section on [parent-child communication](view/08_parent_child.md), we saw that you can use `provide_context` to pass signal from a parent component to a child, and `use_context` to read it in the child. But `provide_context` works across any distance. If you want to create a global signal that holds some piece of state, you can provide it and access it via context anywhere in the descendants of the component where you provide it.
 
-In fine-grained reactive libraries like Leptos, this is simply not the case.
-You can create a signal in the root of your app and pass it down to other
-components using provide_context(). Changing it will only cause rerendering
-in the specific places it is actually used, not the whole app.
+A signal provided via context only causes reactive updates where it is read, not in any of the components in between, so it maintains the power of fine-grained reactive updates, even at a distance.
 
 We start by creating a signal in the root of the app and providing it to
 all its children and descendants using `provide_context`.
@@ -81,61 +79,72 @@ fn FancyMath(cx: Scope) -> impl IntoView {
 }
 ```
 
-This kind of “provide a signal in a parent, consume it in a child” should be familiar
-from the chapter on [parent-child interactions](./view/08_parent_child.md). The same
-pattern you use to communicate between parents and children works for grandparents and
-grandchildren, or any ancestors and descendants: in other words, between “global” state
-in the root component of your app and any other components anywhere else in the app.
-
-Because of the fine-grained nature of updates, this is usually all you need. However,
-in some cases with more complex state changes, you may want to use a slightly more
-structured approach to global state.
-
-## Option #3: Create a Global State Struct
-
-You can use this approach to build a single global data structure
-that holds the state for your whole app, and then access it by
-taking fine-grained slices using
-[`create_slice`](https://docs.rs/leptos/latest/leptos/fn.create_slice.html)
-or [`create_memo`](https://docs.rs/leptos/latest/leptos/fn.create_memo.html),
-so that changing one part of the state doesn't cause parts of your
-app that depend on other parts of the state to change.
-
-You can begin by defining a simple state struct:
+Note that this same pattern can be applied to more complex state. If you have multiple fields you want to update independently, you can do that by providing some struct of signals:
 
 ```rust
-#[derive(Default, Clone, Debug)]
+#[derive(Copy, Clone, Debug)]
 struct GlobalState {
-    count: u32,
-    name: String,
+    count: RwSignal<i32>,
+    name: RwSignal<String>
 }
-```
 
-Provide it in the root of your app so it’s available everywhere.
+impl GlobalState {
+    pub fn new(cx: Scope) -> Self {
+        Self {
+            count: create_rw_signal(cx, 0),
+            name: create_rw_signal(cx, "Bob".to_string())
+        }
+    }
+}
 
-```rust
 #[component]
 fn App(cx: Scope) -> impl IntoView {
-    // we'll provide a single signal that holds the whole state
-    // each component will be responsible for creating its own "lens" into it
-    let state = create_rw_signal(cx, GlobalState::default());
-    provide_context(cx, state);
+    provide_context(cx, GlobalState::new(cx));
 
-    // ...
+    // etc.
 }
 ```
 
-Then child components can access “slices” of that state with fine-grained
-updates via `create_slice`. Each slice signal only updates when the particular
-piece of the larger struct it accesses updates. This means you can create a single
-root signal, and then take independent, fine-grained slices of it in different
-components, each of which can update without notifying the others of changes.
+## Option #3: Create a Global State Struct and Slices
+
+You may find it cumbersome to wrap each field of a structure in a separate signal like this. In some cases, it can be useful to create a plain struct with non-reactive fields, and then wrap that in a signal.
+
+```rust
+#[derive(Copy, Clone, Debug, Default)]
+struct GlobalState {
+    count: i32,
+    name: String
+}
+
+#[component]
+fn App(cx: Scope) -> impl IntoView {
+    provide_context(cx, create_rw_signal(GlobalState::default()));
+
+    // etc.
+}
+```
+
+But there’s a problem: because our whole state is wrapped in one signal, updating the value of one field will cause reactive updates in parts of the UI that only depend on the other.
+
+```rust
+let state = expect_context::<RwSignal<GlobalState>>(cx);
+view! { cx,
+    <button on:click=move |_| state.update(|n| *n += 1)>"+1"</button>
+    <p>{move || state.with(|state| state.name.clone())}</p>
+}
+```
+
+In this example, clicking the button will cause the text inside `<p>` to be updated, cloning `state.name` again! Because signals are the atomic unit of reactivity, updating any field of the signal triggers updates to everything that depends on the signal.
+
+There’s a better way. You can use take fine-grained, reactive slices by using [`create_memo`](https://docs.rs/leptos/latest/leptos/fn.create_memo.html) or [`create_slice`](https://docs.rs/leptos/latest/leptos/fn.create_slice.html) (which uses `create_memo` but also provides a setter). “Memoizing” a value means creating a new reactive value which will only update when it changes. “Memoizing a slice” means creating a new reactive value which will only update when some field of the state struct updates.
+
+Here, instead of reading from the state signal directly, we create “slices” of that state with fine-grained updates via `create_slice`. Each slice signal only updates when the particular piece of the larger struct it accesses updates. This means you can create a single root signal, and then take independent, fine-grained slices of it in different components, each of which can update without notifying the others of changes.
 
 ```rust
 /// A component that updates the count in the global state.
 #[component]
 fn GlobalStateCounter(cx: Scope) -> impl IntoView {
-    let state = use_context::<RwSignal<GlobalState>>(cx).expect("state to have been provided");
+    let state = expect_context::<RwSignal<GlobalState>>(cx);
 
     // `create_slice` lets us create a "lens" into the data
     let (count, set_count) = create_slice(
@@ -169,6 +178,8 @@ somewhere else that only takes `state.name`, clicking the button won’t cause
 that other slice to update. This allows you to combine the benefits of a top-down
 data flow and of fine-grained reactive updates.
 
+> **Note**: There are some significant drawbacks to this approach. Both signals and memos need to own their values, so a memo will need to clone the field’s value on every change. The most natural way to manage state in a framework like Leptos is always to provide signals that are as locally-scoped and fine-grained as they can be, not to hoist everything up into global state. But when you _do_ need some kind of global state, `create_slice` can be a useful tool.
+
 [Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/1-basic-component-forked-8bte19?selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D&file=%2Fsrc%2Fmain.rs)
 
 <iframe src="https://codesandbox.io/p/sandbox/1-basic-component-forked-8bte19?selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D&file=%2Fsrc%2Fmain.rs" width="100%" height="1000px" style="max-height: 100vh"></iframe>

docs/book/src/SUMMARY.md

@@ -12,7 +12,10 @@
   - [Error Handling](./view/07_errors.md)
   - [Parent-Child Communication](./view/08_parent_child.md)
   - [Passing Children to Components](./view/09_component_children.md)
-- [Interlude: Reactivity and Functions](./interlude_functions.md)
+- [Reactivity](./reactivity/README.md)
+  - [Working with Signals](./reactivity/working_with_signals.md)
+  - [Responding to Changes with `create_effect`](./reactivity/14_create_effect.md)
+  - [Interlude: Reactivity and Functions](./reactivity/interlude_functions.md)
 - [Testing](./testing.md)
 - [Async](./async/README.md)
   - [Loading Data with Resources](./async/10_resources.md)
@@ -29,7 +32,7 @@
   - [`<A/>`](./router/19_a.md)
   - [`<Form/>`](./router/20_form.md)
 - [Interlude: Styling](./interlude_styling.md)
-- [Metadata]()
+- [Metadata](./metadata.md)
 - [Server Side Rendering](./ssr/README.md)
   - [`cargo-leptos`](./ssr/21_cargo_leptos.md)
   - [The Life of a Page Load](./ssr/22_life_cycle.md)
@@ -37,16 +40,9 @@
   - [Hydration Bugs](./ssr/24_hydration_bugs.md)
 - [Working with the Server](./server/README.md)
   - [Server Functions](./server/25_server_functions.md)
-  - [Request/Response]()
-  - [Extractors]()
-    - [Axum]()
-    - [Actix]()
-  - [Headers]()
-  - [Cookies]()
-- [Building Full-Stack Apps]()
-  - [Actions]()
-  - [Forms]()
-  - [`<ActionForm/>`s]()
-  - [Turning off WebAssembly: Progressive Enhancement and Graceful Degradation]()
-- [Advanced Reactivity]()
+  - [Extractors](./server/26_extractors.md)
+  - [Responses and Redirects](./server/27_response.md)
+- [Progressive Enhancement and Graceful Degradation](./progressive_enhancement/README.md)
+  - [`<ActionForm/>`s](./progressive_enhancement/action_form.md)
+- [Deployment]()
 - [Appendix: Optimizing WASM Binary Size](./appendix_binary_size.md)

docs/book/src/appendix_binary_size.md

@@ -41,6 +41,20 @@ build-std = ["std", "panic_abort", "core", "alloc"]
 build-std-features = ["panic_immediate_abort"]
 ```
 
+Note that if you're using this with SSR too, the same Cargo profile will be applied. You'll need to explicitly specify your target:
+```toml
+[build]
+target = "x86_64-unknown-linux-gnu" # or whatever
+```
+
+Also note that in some cases, the cfg feature `has_std` will not be set, which may cause build errors with some dependencies which check for `has_std`. You may fix any build errors due to this by adding:
+```toml
+[build]
+rustflags = ["--cfg=has_std"]
+```
+
+And you'll need to add `panic = "abort"` to `[profile.release]` in `Cargo.toml`. Note that this applies the same `build-std` and panic settings to your server binary, which may not be desirable. Some further exploration is probably needed here.
+
 5. One of the sources of binary size in WASM binaries can be `serde` serialization/deserialization code. Leptos uses `serde` by default to serialize and deserialize resources created with `create_resource`. You might try experimenting with the `miniserde` and `serde-lite` features, which allow you to use those crates for serialization and deserialization instead; each only implements a subset of `serde`’s functionality, but typically optimizes for size over speed.
 
 ## Things to Avoid

docs/book/src/async/13_actions.md

@@ -11,7 +11,7 @@ Actions and resources seem similar, but they represent fundamentally different t
 Say we have some `async` function we want to run.
 
 ```rust
-async fn add_todo(new_title: &str) -> Uuid {
+async fn add_todo_request(new_title: &str) -> Uuid {
     /* do some stuff on the server to add a new todo */
 }
 ```
@@ -41,16 +41,16 @@ async fn add_todo(new_title: &str) -> Uuid {
 So in this case, all we need to do to create an action is
 
 ```rust
-let add_todo = create_action(cx, |input: &String| {
+let add_todo_action = create_action(cx, |input: &String| {
     let input = input.to_owned();
-    async move { add_todo(&input).await }
+    async move { add_todo_request(&input).await }
 });
 ```
 
-Rather than calling `add_todo` directly, we’ll call it with `.dispatch()`, as in
+Rather than calling `add_todo_action` directly, we’ll call it with `.dispatch()`, as in
 
 ```rust
-add_todo.dispatch("Some value".to_string());
+add_todo_action.dispatch("Some value".to_string());
 ```
 
 You can do this from an event listener, a timeout, or anywhere; because `.dispatch()` isn’t an `async` function, it can be called from a synchronous context.
@@ -58,9 +58,9 @@ You can do this from an event listener, a timeout, or anywhere; because `.dispat
 Actions provide access to a few signals that synchronize between the asynchronous action you’re calling and the synchronous reactive system:
 
 ```rust
-let submitted = add_todo.input(); // RwSignal<Option<String>>
-let pending = add_todo.pending(); // ReadSignal<bool>
-let todo_id = add_todo.value(); // RwSignal<Option<Uuid>>
+let submitted = add_todo_action.input(); // RwSignal<Option<String>>
+let pending = add_todo_action.pending(); // ReadSignal<bool>
+let todo_id = add_todo_action.value(); // RwSignal<Option<Uuid>>
 ```
 
 This makes it easy to track the current state of your request, show a loading indicator, or do “optimistic UI” based on the assumption that the submission will succeed.
@@ -73,7 +73,7 @@ view! { cx,
         on:submit=move |ev| {
             ev.prevent_default(); // don't reload the page...
             let input = input_ref.get().expect("input to exist");
-            add_todo.dispatch(input.value());
+            add_todo_action.dispatch(input.value());
         }
     >
         <label>

docs/book/src/interlude_projecting_children.md

@@ -29,9 +29,9 @@ where
 }
 ```
 
-This is pretty straightforward: when the user is logged in, we want to show `children`. Until if the user is not logged in, we want to show `fallback`. And while we’re waiting to find out, we just render `()`, i.e., nothing.
+This is pretty straightforward: when the user is logged in, we want to show `children`. If the user is not logged in, we want to show `fallback`. And while we’re waiting to find out, we just render `()`, i.e., nothing.
 
-In other words, we want to pass the children of `<WhenLoaded/>` _through_ the `<Suspense/>` component to become the children of the `<Show/>`. This is what I mean by “projection.”
+In other words, we want to pass the children of `<LoggedIn/>` _through_ the `<Suspense/>` component to become the children of the `<Show/>`. This is what I mean by “projection.”
 
 This won’t compile.
 

docs/book/src/metadata.md

@@ -0,0 +1,49 @@
+# Metadata
+
+So far, everything we’ve rendered has been inside the `<body>` of the HTML document. And this makes sense. After all, everything you can see on a web page lives inside the `<body>`.
+
+However, there are plenty of occasions where you might want to update something inside the `<head>` of the document using the same reactive primitives and component patterns you use for your UI.
+
+That’s where the [`leptos_meta`](https://docs.rs/leptos_meta/latest/leptos_meta/) package comes in.
+
+## Metadata Components
+
+`leptos_meta` provides special components that let you inject data from inside components anywhere in your application into the `<head>`:
+
+[`<Title/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Title.html) allows you to set the document’s title from any component. It also takes a `formatter` function that can be used to apply the same format to the title set by other pages. So, for example, if you put `<Title formatter=|text| format!("{text} — My Awesome Site")/>` in your `<App/>` component, and then `<Title text="Page 1"/>` and `<Title text="Page 2"/>` on your routes, you’ll get `Page 1 — My Awesome Site` and `Page 2 — My Awesome Site`.
+
+[`<Link/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Link.html) takes the standard attributes of the `<link>` element.
+
+[`<Stylesheet/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Stylesheet.html) creates a `<link rel="stylesheet">` with the `href` you give.
+
+[`<Style/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Style.html) creates a `<style>` with the children you pass in (usually a string). You can use this to import some custom CSS from another file at compile time `<Style>{include_str!("my_route.css")}</Style>`.
+
+[`<Meta/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Meta.html) lets you set `<meta>` tags with descriptions and other metadata.
+
+## `<Script/>` and `<script>`
+
+`leptos_meta` also provides a [`<Script/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Script.html) component, and it’s worth pausing here for a second. All of the other components we’ve considered inject `<head>`-only elements in the `<head>`. But a `<script>` can also be included in the body.
+
+There’s a very simple way to determine whether you should use a capital-S `<Script/>` component or a lowercase-s `<script>` element: the `<Script/>` component will be rendered in the `<head>`, and the `<script>` element will be rendered wherever in the `<body>` of your user interface you put it in, alongside other normal HTML elements. These cause JavaScript to load and run at different times, so use whichever is appropriate to your needs.
+
+## `<Body/>` and `<Html/>`
+
+There are even a couple elements designed to make semantic HTML and styling easier. [`<Html/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Html.html) lets you set the `lang` and `dir` on your `<html>` tag from your application code. `<Html/>` and [`<Body/>`](https://docs.rs/leptos_meta/latest/leptos_meta/fn.Html.html) both have `class` props that let you set their respective `class` attributes, which is sometimes needed by CSS frameworks for styling.
+
+`<Body/>` and `<Html/>` both also have `attributes` props which can be used to set any number of additional attributes on them via the [`AdditionalAttributes`](https://docs.rs/leptos/latest/leptos/struct.AdditionalAttributes.html) type:
+
+```rust
+<Html
+	lang="he"
+	dir="rtl"
+	attributes=AdditionalAttributes::from(vec![("data-theme", "dark")])
+/>
+```
+
+## Metadata and Server Rendering
+
+Now, some of this is useful in any scenario, but some of it is especially important for search-engine optimization (SEO). Making sure you have things like appropriate `<title>` and `<meta>` tags is crucial. Modern search engine crawlers do handle client-side rendering, i.e., apps that are shipped as an empty `index.html` and rendered entirely in JS/WASM. But they prefer to receive pages in which your app has been rendered to actual HTML, with metadata in the `<head>`.
+
+This is exactly what `leptos_meta` is for. And in fact, during server rendering, this is exactly what it does: collect all the `<head>` content you’ve declared by using its components throughout your application, and then inject it into the actual `<head>`.
+
+But I’m getting ahead of myself. We haven’t actually talked about server-side rendering yet. As a matter of fact... Let’s do that next!

docs/book/src/progressive_enhancement/README.md

@@ -0,0 +1,36 @@
+# Progressive Enhancement (and Graceful Degradation)
+
+I’ve been driving around Boston for about fifteen years. If you don’t know Boston, let me tell you: Massachusetts has some of the most aggressive drivers(and pedestrians!) in the world. I’ve learned to practice what’s sometimes called “defensive driving”: assuming that someone’s about to swerve in front of you at an intersection when you have the right of way, preparing for a pedestrian to cross into the street at any moment, and driving accordingly.
+
+“Progressive enhancement” is the “defensive driving” of web design. Or really, that’s “graceful degradation,” although they’re two sides of the same coin, or the same process, from two different directions.
+
+**Progressive enhancement**, in this context, means beginning with a simple HTML site or application that works for any user who arrives at your page, and gradually enhancing it with layers of additional features: CSS for styling, JavaScript for interactivity, WebAssembly for Rust-powered interactivity; using particular Web APIs for a richer experience if they’re available and as needed.
+
+**Graceful degradation** means handling failure gracefully when parts of that stack of enhancement *aren’t* available. Here are some sources of failure your users might encounter in your app:
+- Their browser doesn’t support WebAssembly because it needs to be updated.
+- Their browser can’t support WebAssembly because browser updates are limited to newer OS versions, which can’t be installed on the device. (Looking at you, Apple.)
+- They have WASM turned off for security or privacy reasons.
+- They have JavaScript turned off for security or privacy reasons.
+- JavaScript isn’t supported on their device (for example, some accessibility devices only support HTML browsing)
+- The JavaScript (or WASM) never arrived at their device because they walked outside and lost WiFi.
+- They stepped onto a subway car after loading the initial page and subsequent navigations can’t load data.
+- ... and so on.
+
+How much of your app still works if one of these holds true? Two of them? Three? 
+
+If the answer is something like “95%... okay, then 90%... okay, then 75%,” that’s graceful degradation. If the answer is “my app shows a blank screen unless everything works correctly,” that’s... rapid unscheduled disassembly.
+
+**Graceful degradation is especially important for WASM apps,** because WASM is the newest and least-likely-to-be-supported of the four languages that run in the browser (HTML, CSS, JS, WASM).
+
+Luckily, we’ve got some tools to help.
+
+## Defensive Design
+
+There are a few practices that can help your apps degrade more gracefully:
+1. **Server-side rendering.** Without SSR, your app simply doesn’t work without both JS and WASM loading. In some cases this may be appropriate (think internal apps gated behind a login) but in others it’s simply broken.
+2. **Native HTML elements.** Use HTML elements that do the things that you want, without additional code: `<a>` for navigation (including to hashes within the page), `<details>` for an accordion, `<form>` to persist information in the URL, etc.
+3. **URL-driven state.** The more of your global state is stored in the URL (as a route param or part of the query string), the more of the page can be generated during server rendering and updated by an `<a>` or a `<form>`, which means that not only navigations but state changes can work without JS/WASM.
+4. **[`SsrMode::PartiallyBlocked` or `SsrMode::InOrder`](https://docs.rs/leptos_router/latest/leptos_router/enum.SsrMode.html).** Out-of-order streaming requires a small amount of inline JS, but can fail if 1) the connection is broken halfway through the response or 2) the client’s device doesn’t support JS. Async streaming will give a complete HTML page, but only after all resources load. In-order streaming begins showing pieces of the page sooner, in top-down order. “Partially-blocked” SSR builds on out-of-order streaming by replacing `<Suspense/>` fragments that read from blocking resources on the server. This adds marginally to the initial response time (because of the `O(n)` string replacement work), in exchange for a more complete initial HTML response. This can be a good choice for situations in which there’s a clear distinction between “more important” and “less important” content, e.g., blog post vs. comments, or product info vs. reviews. If you choose to block on all the content, you’ve essentially recreated async rendering.
+5. **Leaning on `<form>`s.** There’s been a bit of a `<form>` renaissance recently, and it’s no surprise. The ability of a `<form>` to manage complicated `POST` or `GET` requests in an easily-enhanced way makes it a powerful tool for graceful degradation. The example in [the `<Form/>` chapter](../router/20_form.md), for example, would work fine with no JS/WASM: because it uses a `<form method="GET">` to persist state in the URL, it works with pure HTML by making normal HTTP requests and then progressively enhances to use client-side navigations instead.
+
+There’s one final feature of the framework that we haven’t seen yet, and which builds on this characteristic of forms to build powerful applications: the `<ActionForm/>`.

docs/book/src/progressive_enhancement/action_form.md

@@ -0,0 +1,56 @@
+# `<ActionForm/>`
+
+[`<ActionForm/>`](https://docs.rs/leptos_router/latest/leptos_router/fn.ActionForm.html) is a specialized `<Form/>` that takes a server action, and automatically dispatches it on form submission. This allows you to call a server function directly from a `<form>`, even without JS/WASM.
+
+The process is simple:
+1. Define a server function using the [`#[server]` macro](https://docs.rs/leptos/latest/leptos/attr.server.html) (see [Server Functions](../server/25_server_functions.md).)
+2. Create an action using [`create_server_action`](https://docs.rs/leptos/latest/leptos/fn.create_server_action.html), specifying the type of the server function you’ve defined.
+3. Create an `<ActionForm/>`, providing the server action in the `action` prop.
+4. Pass the named arguments to the server function as form fields with the same names.
+
+> **Note:** `<ActionForm/>` only works with the default URL-encoded `POST` encoding for server functions, to ensure graceful degradation/correct behavior as an HTML form. 
+
+```rust
+#[server(AddTodo, "/api")]
+pub async fn add_todo(title: String) -> Result<(), ServerFnError> {
+    todo!()
+}
+
+#[component]
+fn AddTodo(cx: Scope) -> impl IntoView {
+	let add_todo = create_server_action::<AddTodo>(cx);
+	// holds the latest *returned* value from the server
+	let value = add_todo.value();
+	// check if the server has returned an error
+	let has_error = move || value.with(|val| matches!(val, Some(Err(_))));
+
+	view! { cx,
+		<ActionForm action=add_todo>
+			<label>
+				"Add a Todo"
+				// `title` matches the `title` argument to `add_todo`
+				<input type="text" name="title"/>
+			</label>
+			<input type="submit" value="Add"/>
+		</ActionForm>
+	}
+}
+```
+It’s really that easy. With JS/WASM, your form will submit without a page reload, storing its most recent submission in the `.input()` signal of the action, its pending status in `.pending()`, and so on. (See the [`Action`](https://docs.rs/leptos/latest/leptos/struct.Action.html) docs for a refresher, if you need.) Without JS/WASM, your form will submit with a page reload. If you call a `redirect` function (from `leptos_axum` or `leptos_actix`) it will redirect to the correct page. By default, it will redirect back to the page you’re currently on. The power of HTML, HTTP, and isomorphic rendering mean that your `<ActionForm/>` simply works, even with no JS/WASM.
+
+## Client-Side Validation
+
+Because the `<ActionForm/>` is just a `<form>`, it fires a `submit` event. You can use either HTML validation, or your own client-side validation logic in an `on:submit`. Just call `ev.prevent_default()` to prevent submission.
+
+The [`FromFormData`](https://docs.rs/leptos_router/latest/leptos_router/trait.FromFormData.html) trait can be helpful here, for attempting to parse your server function’s data type from the submitted form.
+
+```rust
+let on_submit = move |ev| {
+	let data = AddTodo::from_event(&ev);
+	// silly example of validation: if the todo is "nope!", nope it
+	if data.is_err() || data.unwrap().title == "nope!" {
+		// ev.prevent_default() will prevent form submission
+		ev.prevent_default();
+	}
+}
+```

docs/book/src/reactivity/14_create_effect.md

@@ -0,0 +1,114 @@
+# Responding to Changes with `create_effect`
+
+We’ve made it this far without having mentioned half of the reactive system: effects.
+
+Reactivity works in two halves: updating individual reactive values (“signals”) notifies the pieces of code that depend on them (“effects”) that they need to run again. These two halves of the reactive system are inter-dependent. Without effects, signals can change within the reactive system but never be observed in a way that interacts with the outside world. Without signals, effects run once but never again, as there’s no observable value to subscribe to. Effects are quite literally “side effects” of the reactive system: they exist to synchronize the reactive system with the non-reactive world outside it.
+
+Hidden behind the whole reactive DOM renderer that we’ve seen so far is a function called `create_effect`.
+
+[`create_effect`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_effect.html) takes a function as its argument. It immediately runs the function. If you access any reactive signal inside that function, it registers the fact that the effect depends on that signal with the reactive runtime. Whenever one of the signals that the effect depends on changes, the effect runs again.
+
+```rust
+let (a, set_a) = create_signal(cx, 0);
+let (b, set_b) = create_signal(cx, 0);
+
+create_effect(cx, move |_| {
+  // immediately prints "Value: 0" and subscribes to `a`
+  log::debug!("Value: {}", a());
+});
+```
+
+The effect function is called with an argument containing whatever value it returned the last time it ran. On the initial run, this is `None`.
+
+By default, effects **do not run on the server**. This means you can call browser-specific APIs within the effect function without causing issues. If you need an effect to run on the server, use [`create_isomorphic_effect`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_isomorphic_effect.html).
+
+## Autotracking and Dynamic Dependencies
+
+If you’re familiar with a framework like React, you might notice one key difference. React and similar frameworks typically require you to pass a “dependency array,” an explicit set of variables that determine when the effect should rerun.
+
+Because Leptos comes from the tradition of synchronous reactive programming, we don’t need this explicit dependency list. Instead, we automatically track dependencies depending on which signals are accessed within the effect.
+
+This has two effects (no pun intended). Dependencies are:
+
+1. **Automatic**: You don’t need to maintain a dependency list, or worry about what should or shouldn’t be included. The framework simply tracks which signals might cause the effect to rerun, and handles it for you.
+2. **Dynamic**: The dependency list is cleared and updated every time the effect runs. If your effect contains a conditional (for example), only signals that are used in the current branch are tracked. This means that effects rerun the absolute minimum number of times.
+
+> If this sounds like magic, and if you want a deep dive into how automatic dependency tracking works, [check out this video](https://www.youtube.com/watch?v=GWB3vTWeLd4). (Apologies for the low volume!)
+
+## Effects as Zero-Cost-ish Abstraction
+
+While they’re not a “zero-cost abstraction” in the most technical sense—they require some additional memory use, exist at runtime, etc.—at a higher level, from the perspective of whatever expensive API calls or other work you’re doing within them, effects are a zero-cost abstraction. They rerun the absolute minimum number of times necessary, given how you’ve described them.
+
+Imagine that I’m creating some kind of chat software, and I want people to be able to display their full name, or just their first name, and to notify the server whenever their name changes:
+
+```rust
+let (first, set_first) = create_signal(cx, String::new());
+let (last, set_last) = create_signal(cx, String::new());
+let (use_last, set_use_last) = create_signal(cx, true);
+
+// this will add the name to the log
+// any time one of the source signals changes
+create_effect(cx, move |_| {
+    log(
+        cx,
+        if use_last() {
+            format!("{} {}", first(), last())
+        } else {
+            first()
+        },
+    )
+});
+```
+
+If `use_last` is `true`, effect should rerun whenever `first`, `last`, or `use_last` changes. But if I toggle `use_last` to `false`, a change in `last` will never cause the full name to change. In fact, `last` will be removed from the dependency list until `use_last` toggles again. This saves us from sending multiple unnecessary requests to the API if I change `last` multiple times while `use_last` is still `false`.
+
+## To `create_effect`, or not to `create_effect`?
+
+Effects are intended to run _side-effects_ of the system, not to synchronize state _within_ the system. In other words: don’t write to signals within effects.
+
+If you need to define a signal that depends on the value of other signals, use a derived signal or [`create_memo`](https://docs.rs/leptos_reactive/latest/leptos_reactive/fn.create_memo.html).
+
+If you need to synchronize some reactive value with the non-reactive world outside—like a web API, the console, the filesystem, or the DOM—create an effect.
+
+> If you’re curious for more information about when you should and shouldn’t use `create_effect`, [check out this video](https://www.youtube.com/watch?v=aQOFJQ2JkvQ) for a more in-depth consideration!
+
+## Effects and Rendering
+
+We’ve managed to get this far without mentioning effects because they’re built into the Leptos DOM renderer. We’ve seen that you can create a signal and pass it into the `view` macro, and it will update the relevant DOM node whenever the signal changes:
+
+```rust
+let (count, set_count) = create_signal(cx, 0);
+
+view! { cx,
+    <p>{count}</p>
+}
+```
+
+This works because the framework essentially creates an effect wrapping this update. You can imagine Leptos translating this view into something like this:
+
+```rust
+let (count, set_count) = create_signal(cx, 0);
+
+// create a DOM element
+let p = create_element("p");
+
+// create an effect to reactively update the text
+create_effect(cx, move |prev_value| {
+    // first, access the signal’s value and convert it to a string
+    let text = count().to_string();
+
+    // if this is different from the previous value, update the node
+    if prev_value != Some(text) {
+        p.set_text_content(&text);
+    }
+
+    // return this value so we can memoize the next update
+    text
+});
+```
+
+Every time `count` is updated, this effect wil rerun. This is what allows reactive, fine-grained updates to the DOM.
+
+[Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/serene-thompson-40974n?file=%2Fsrc%2Fmain.rs&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D)
+
+<iframe src="https://codesandbox.io/p/sandbox/serene-thompson-40974n?file=%2Fsrc%2Fmain.rs&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A2%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A2%7D%5D" width="100%" height="1000px" style="max-height: 100vh"></iframe>

docs/book/src/reactivity/README.md

@@ -0,0 +1,5 @@
+# Reactivity
+
+Leptos is built on top of a fine-grained reactive system, designed to run expensive side effects (like rendering something in a browser, or making a network request) as infrequently as possible in response to change, reactive values.
+
+So far we’ve seen signals in action. These chapters will go into a bit more depth, and look at effects, which are the other half of the story.

docs/book/src/reactivity/working_with_signals.md

@@ -0,0 +1,106 @@
+# Working with Signals
+
+So far we’ve used some simple examples of [`create_signal`](https://docs.rs/leptos/latest/leptos/fn.create_signal.html), which returns a [`ReadSignal`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html) getter and a [`WriteSignal`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html) setter.
+
+## Getting and Setting
+
+There are four basic signal operations:
+
+1. [`.get()`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html#impl-SignalGet%3CT%3E-for-ReadSignal%3CT%3E) clones the current value of the signal and tracks any future changes to the value reactively.
+2. [`.with()`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html#impl-SignalWith%3CT%3E-for-ReadSignal%3CT%3E) takes a function, which receives the current value of the signal by reference (`&T`), and tracks any future changes.
+3. [`.set()`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html#impl-SignalSet%3CT%3E-for-WriteSignal%3CT%3E) replaces the current value of the signal and notifies any subscribers that they need to update.
+4. [`.update()`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html#impl-SignalUpdate%3CT%3E-for-WriteSignal%3CT%3E) takes a function, which receives a mutable reference to the current value of the signal (`&mut T`), and notifies any subscribers that they need to update. (`.update()` doesn’t return the value returned by the closure, but you can use [`.try_update()`](https://docs.rs/leptos/latest/leptos/trait.SignalUpdate.html#tymethod.try_update) if you need to; for example, if you’re removing an item from a `Vec<_>` and want the removed item.)
+
+Calling a `ReadSignal` as a function is syntax sugar for `.get()`. Calling a `WriteSignal` as a function is syntax sugar for `.set()`. So
+
+```rust
+let (count, set_count) = create_signal(cx, 0);
+set_count(1);
+log!(count());
+```
+
+is the same as
+
+```rust
+let (count, set_count) = create_signal(cx, 0);
+set_count.set(1);
+log!(count.get());
+```
+
+You might notice that `.get()` and `.set()` can be implemented in terms of `.with()` and `.update()`. In other words, `count.get()` is identical with `count.with(|n| n.clone())`, and `count.set(1)` is implemented by doing `count.update(|n| *n = 1)`.
+
+But of course, `.get()` and `.set()` (or the plain function-call forms!) are much nicer syntax.
+
+However, there are some very good use cases for `.with()` and `.update()`.
+
+For example, consider a signal that holds a `Vec<String>`.
+
+```rust
+let (names, set_names) = create_signal(cx, Vec::new());
+if names().is_empty() {
+	set_names(vec!["Alice".to_string()]);
+}
+```
+
+In terms of logic, this is simple enough, but it’s hiding some significant inefficiencies. Remember that `names().is_empty()` is sugar for `names.get().is_empty()`, which clones the value (it’s `names.with(|n| n.clone()).is_empty()`). This means we clone the whole `Vec<String>`, run `is_empty()`, and then immediately throw away the clone.
+
+Likewise, `set_names` replaces the value with a whole new `Vec<_>`. This is fine, but we might as well just mutate the original `Vec<_>` in place.
+
+```rust
+let (names, set_names) = create_signal(cx, Vec::new());
+if names.with(|names| names.is_empty()) {
+	set_names.update(|names| names.push("Alice".to_string()));
+}
+```
+
+Now our function simply takes `names` by reference to run `is_empty()`, avoiding that clone.
+
+And if you have Clippy on, or if you have sharp eyes, you may notice we can make this even neater:
+
+```rust
+if names.with(Vec::is_empty) {
+	// ...
+}
+```
+
+After all, `.with()` simply takes a function that takes the value by reference. Since `Vec::is_empty` takes `&self`, we can pass it in directly and avoid the unncessary closure.
+
+## Making signals depend on each other
+
+Often people ask about situations in which some signal needs to change based on some other signal’s value. There are three good ways to do this, and one that’s less than ideal but okay under controlled circumstances.
+
+### Good Options
+**1) B is a function of A.** Create a signal for A and a derived signal or memo for B.
+
+```rust
+let (count, set_count) = create_signal(cx, 1);
+let derived_signal_double_count = move || count() * 2;
+let memoized_double_count = create_memo(cx, move |_| count() * 2);
+```
+> For guidance on whether to use a derived signal or a memo, see the docs for [`create_memo`](https://docs.rs/leptos/latest/leptos/fn.create_memo.html)
+> 
+**2) C is a function of A and some other thing B.** Create signals for A and B and a derived signal or memo for C.
+
+```rust
+let (first_name, set_first_name) = create_signal(cx, "Bridget".to_string());
+let (last_name, set_last_name) = create_signal(cx, "Jones".to_string());
+let full_name = move || format!("{} {}", first_name(), last_name());
+```
+**3) A and B are independent signals, but sometimes updated at the same time.** When you make the call to update A, make a separate call to update B.
+```rust
+let (age, set_age) = create_signal(cx, 32);
+let (favorite_number, set_favorite_number) = create_signal(cx, 42);
+// use this to handle a click on a `Clear` button
+let clear_handler = move |_| {
+  set_age(0);
+  set_favorite_number(0);
+};
+```
+### If you really must...
+**4) Create an effect to write to B whenever A changes.** This is officially discouraged, for several reasons:
+a) It will always be less efficient, as it means every time A updates you do two full trips through the reactive process. (You set A, which causes the effect to run, as well as any other effects that depend on A. Then you set B, which causes any effects that depend on B to run.)
+b) It increases your chances of accidentally creating things like infinite loops or over-re-running effects. This is the kind of ping-ponging, reactive spaghetti code that was common in the early 2010s and that we try to avoid with things like read-write segregation and discouraging writing to signals from effects.
+
+In most situations, it’s best to rewrite things such that there’s a clear, top-down data flow based on derived signals or memos. But this isn’t the end of the world.
+
+> I’m intentionally not providing an example here. Read the [`create_effect`](https://docs.rs/leptos/latest/leptos/fn.create_effect.html) docs to figure out how this would work.

docs/book/src/router/16_routes.md

@@ -34,7 +34,7 @@ use leptos_router::*;
 
 #[component]
 pub fn App(cx: Scope) -> impl IntoView {
-  view! {
+  view! { cx,
     <Router>
       <nav>
         /* ... */
@@ -59,7 +59,7 @@ use leptos_router::*;
 
 #[component]
 pub fn App(cx: Scope) -> impl IntoView {
-  view! {
+  view! { cx,
     <Router>
       <nav>
         /* ... */

docs/book/src/router/17_nested_routing.md

@@ -124,7 +124,7 @@ You can go even deeper. Say you want to have tabs for each contact’s address,
 
 ## `<Outlet/>`
 
-Parent routes do not automatically render their nested routes. After all, they are just components; they don’t know exactly where they should render their children, and “just stick at at the end of the parent component” is not a great answer.
+Parent routes do not automatically render their nested routes. After all, they are just components; they don’t know exactly where they should render their children, and “just stick it at the end of the parent component” is not a great answer.
 
 Instead, you tell a parent component where to render any nested components with an `<Outlet/>` component. The `<Outlet/>` simply renders one of two things:
 

docs/book/src/router/18_params_and_queries.md

@@ -39,7 +39,7 @@ struct ContactSearch {
 
 Now we can use them in a component. Imagine a URL that has both params and a query, like `/contacts/:id?q=Search`.
 
-The typed versions return `Memo<Result<T>, _>`. It’s a Memo so it reacts to changes in the URL. It’s a `Result` because the params or query need to be parsed from the URL, and may or may not be valid.
+The typed versions return `Memo<Result<T, _>>`. It’s a Memo so it reacts to changes in the URL. It’s a `Result` because the params or query need to be parsed from the URL, and may or may not be valid.
 
 ```rust
 let params = use_params::<ContactParams>(cx);
@@ -70,9 +70,9 @@ let id = move || {
 This can get a little messy: deriving a signal that wraps an `Option<_>` or `Result<_>` can involve a couple steps. But it’s worth doing this for two reasons:
 
 1. It’s correct, i.e., it forces you to consider the cases, “What if the user doesn’t pass a value for this query field? What if they pass an invalid value?”
-2. It’s performant. Specifically, when you navigate between different paths that match the same `<Route/>` with only params or the query changing, you can get fine-grained updates to different parts of your app without rerendering. For example, navigating between different contacts in our contact-list example does a targeted update to the name field (and eventually contact info) without needing to replacing or rerender the wrapping `<Contact/>`. This is what fine-grained reactivity is for.
+2. It’s performant. Specifically, when you navigate between different paths that match the same `<Route/>` with only params or the query changing, you can get fine-grained updates to different parts of your app without rerendering. For example, navigating between different contacts in our contact-list example does a targeted update to the name field (and eventually contact info) without needing to replace or rerender the wrapping `<Contact/>`. This is what fine-grained reactivity is for.
 
-> This is the same example from the previous section. The router is such an integrated system that it makes sense to provide a single example highlighting multiple features, even if we haven’t explain them all yet.
+> This is the same example from the previous section. The router is such an integrated system that it makes sense to provide a single example highlighting multiple features, even if we haven’t explained them all yet.
 
 [Click to open CodeSandbox.](https://codesandbox.io/p/sandbox/16-router-fy4tjv?file=%2Fsrc%2Fmain.rs&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A3%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A3%7D%5D)
 

docs/book/src/router/20_form.md

@@ -1,12 +1,12 @@
 # The `<Form/>` Component
 
-Links and forms sometimes seem completely unrelated. But in fact, they work in very similar ways.
+Links and forms sometimes seem completely unrelated. But, in fact, they work in very similar ways.
 
 In plain HTML, there are three ways to navigate to another page:
 
-1. An `<a>` element that links to another page. Navigates to the URL in its `href` attribute with the `GET` HTTP method.
-2. A `<form method="GET">`. Navigates to the URL in its `action` attribute with the `GET` HTTP method and the form data from its inputs encoded in the URL query string.
-3. A `<form method="POST">`. Navigates to the URL in its `action` attribute with the `POST` HTTP method and the form data from its inputs encoded in the body of the request.
+1. An `<a>` element that links to another page: Navigates to the URL in its `href` attribute with the `GET` HTTP method.
+2. A `<form method="GET">`: Navigates to the URL in its `action` attribute with the `GET` HTTP method and the form data from its inputs encoded in the URL query string.
+3. A `<form method="POST">`: Navigates to the URL in its `action` attribute with the `POST` HTTP method and the form data from its inputs encoded in the body of the request.
 
 Since we have a client-side router, we can do client-side link navigations without reloading the page, i.e., without a full round-trip to the server and back. It makes sense that we can do client-side form navigations in the same way.
 

docs/book/src/router/README.md

@@ -4,10 +4,10 @@
 
 Routing drives most websites. A router is the answer to the question, “Given this URL, what should appear on the page?”
 
-A URL consists of many parts. For example, the URL `https://leptos.dev/blog/search?q=Search#results` consists of
+A URL consists of many parts. For example, the URL `https://my-cool-blog.com/blog/search?q=Search#results` consists of
 
 - a _scheme_: `https`
-- a _domain_: `leptos.dev`
+- a _domain_: `my-cool-blog.com`
 - a **path**: `/blog/search`
 - a **query** (or **search**): `?q=Search`
 - a _hash_: `#results`

docs/book/src/server/25_server_functions.md

@@ -43,15 +43,6 @@ pub fn BusyButton(cx: Scope) -> impl IntoView {
         </button>
 	}
 }
-
-// somewhere in main.rs
-fn main() {
-	// ...
-
-	AddTodo::register();
-
-	// ...
-}
 ```
 
 You’ll notice a couple things here right away:
@@ -75,7 +66,7 @@ move |_| {
 There are a few things to note about the way you define a server function, too.
 
 - Server functions are created by using the [`#[server]` macro](https://docs.rs/leptos_server/latest/leptos_server/index.html#server) to annotate a top-level function, which can be defined anywhere.
-- We provide the macro a type name. The type name is used to register the server function (in `main.rs`), and it’s used internally as a container to hold, serialize, and deserialize the arguments.
+- We provide the macro a type name. The type name is used internally as a container to hold, serialize, and deserialize the arguments.
 - We provide the macro a path. This is a prefix for the path at which we’ll mount a server function handler on our server. (See examples for [Actix](https://github.com/leptos-rs/leptos/blob/main/examples/todo_app_sqlite/src/main.rs#L44) and [Axum](https://github.com/leptos-rs/leptos/blob/598523cd9d0d775b017cb721e41ebae9349f01e2/examples/todo_app_sqlite_axum/src/main.rs#L51).)
 - You’ll need to have `serde` as a dependency with the `derive` featured enabled for the macro to work properly. You can easily add it to `Cargo.toml` with `cargo add serde --features=derive`.
 
@@ -106,6 +97,14 @@ In other words, you have two choices:
 
 **But remember**: Leptos will handle all the details of this encoding and decoding for you. When you use a server function, it looks just like calling any other asynchronous function!
 
+> **Why not `PUT` or `DELETE`? Why URL/form encoding, and not JSON?**
+>
+> These are reasonable questions. Much of the web is built on REST API patterns that encourage the use of semantic HTTP methods like `DELETE` to delete an item from a database, and many devs are accustomed to sending data to APIs in the JSON format.
+> 
+> The reason we use `POST` or `GET` with URL-encoded data by default is the `<form>` support. For better or for worse, HTML forms don’t support `PUT` or `DELETE`, and they don’t support sending JSON. This means that if you use anything but a `GET` or `POST` request with URL-encoded data, it can only work once WASM has loaded. As we’ll see [in a later chapter](../progressive_enhancement), this isn’t always a great idea.
+> 
+> The CBOR encoding is suported for historical reasons; an earlier version of server functions used a URL encoding that didn’t support nested objects like structs or vectors as server function arguments, which CBOR did. But note that the CBOR forms encounter the same issue as `PUT`, `DELETE`, or JSON: they do not degrade gracefully if the WASM version of your app is not available.
+
 ## An Important Note on Security
 
 Server functions are a cool technology, but it’s very important to remember. **Server functions are not magic; they’re syntax sugar for defining a public API.** The _body_ of a server function is never made public; it’s just part of your server binary. But the server function is a publicly accessible API endpoint, and it’s return value is just a JSON or similar blob. You should _never_ return something sensitive from a server function.

docs/book/src/server/26_extractors.md

@@ -0,0 +1,73 @@
+# Extractors
+
+The server functions we looked at in the last chapter showed how to run code on the server, and integrate it with the user interface you’re rendering in the browser. But they didn’t show you much about how to actually use your server to its full potential.
+
+## Server Frameworks
+
+We call Leptos a “full-stack” framework, but “full-stack” is always a misnomer (after all, it never means everything from the browser to your power company.) For us, “full stack” means that your Leptos app can run in the browser, and can run on the server, and can integrate the two, drawing together the unique features available in each; as we’ve seen in the book so far, a button click on the browser can drive a database read on the server, both written in the same Rust module. But Leptos itself doesn’t provide the server (or the database, or the operating system, or the firmware, or the electrical cables...)
+
+Instead, Leptos provides integrations for the two most popular Rust web server frameworks, Actix Web ([`leptos_actix`](https://docs.rs/leptos_actix/latest/leptos_actix/)) and Axum ([`leptos_axum`](https://docs.rs/leptos_actix/latest/leptos_axum/)). We’ve built integrations with each server’s router so that you can simply plug your Leptos app into an existing server with `.leptos_routes()`, and easily handle server function calls.
+
+> If haven’t seen our [Actix](https://github.com/leptos-rs/start) and [Axum](https://github.com/leptos-rs/start-axum) templates, now’s a good time to check them out.
+
+## Using Extractors
+
+Both Actix and Axum handlers are built on the same powerful idea of **extractors**. Extractors “extract” typed data from an HTTP request, allowing you to access server-specific data easily.
+
+Leptos provides `extract` helper functions to let you use these extractors directly in your server functions, with a convenient syntax very similar to handlers for each framework.
+
+### Actix Extractors
+
+The [`extract` function in `leptos_actix`](https://docs.rs/leptos_actix/latest/leptos_actix/fn.extract.html) takes a handler function as its argument. The handler follows similar rules to an Actix handler: it is an async function that receives arguments that will be extracted from the request and returns some value. The handler function receives that extracted data as its arguments, and can do further `async` work on them inside the body of the `async move` block. It returns whatever value you return back out into the server function.
+
+```rust
+
+#[server(ActixExtract, "/api")]
+pub async fn actix_extract(cx: Scope) -> Result<String, ServerFnError> {
+	use leptos_actix::extract;
+    use actix_web::dev::ConnectionInfo;
+    use actix_web::web::{Data, Query};
+
+    extract(cx,
+        |search: Query<Search>, connection: ConnectionInfo| async move {
+            format!(
+                "search = {}\nconnection = {:?}",
+                search.q,
+                connection
+            )
+        },
+    )
+    .await
+}
+```
+
+## Axum Extractors
+
+The syntax for the `leptos_axum::extract` function is very similar. (**Note**: This is available on the git main branch, but has not been released as of writing.) Note that Axum extractors return a `Result`, so you’ll need to add something to handle the error case.
+
+```rust
+#[server(AxumExtract, "/api")]
+pub async fn axum_extract(cx: Scope) -> Result<String, ServerFnError> {
+    use axum::{extract::Query, http::Method};
+    use leptos_axum::extract;
+
+    extract(cx, |method: Method, res: Query<MyQuery>| async move {
+            format!("{method:?} and {}", res.q)
+        },
+    )
+    .await
+    .map_err(|e| ServerFnError::ServerError("Could not extract method and query...".to_string()))
+}
+```
+
+These are relatively simple examples accessing basic data from the server. But you can use extractors to access things like headers, cookies, database connection pools, and more, using the exact same `extract()` pattern.
+
+> Note: For now, the Axum `extract` function only supports extractors for which the state is `()`, i.e., you can't yet use it to extract `State(_)`. You can access `State(_)` by using a custom handler that extracts the state and then provides it via context. [Click here for an example](https://github.com/leptos-rs/leptos/blob/a5f73b441c079f9138102b3a7d8d4828f045448c/examples/session_auth_axum/src/main.rs#L91-L92).
+
+## A Note about Data-Loading Patterns
+
+Because Actix and (especially) Axum are built on the idea of a single round-trip HTTP request and response, you typically run extractors near the “top” of your application (i.e., before you start rendering) and use the extracted data to determine how that should be rendered. Before you render a `<button>`, you load all the data your app could need. And any given route handler needs to know all the data that will need to be extracted by that route.
+
+But Leptos integrates both the client and the server, and it’s important to be able to refresh small pieces of your UI with new data from the server without forcing a full reload of all the data. So Leptos likes to push data loading “down” in your application, as far towards the leaves of your user interface as possible. When you click a `<button>`, it can refresh just the data it needs. This is exactly what server functions are for: they give you granular access to data to be loaded and reloaded.
+
+The `extract()` functions let you combine both models by using extractors in your server functions. You get access to the full power of route extractors, while decentralizing knowledge of what needs to be extracted down to your individual components. This makes it easier to refactor and reorganize routes: you don’t need to specify all the data a route needs up front.

docs/book/src/server/27_response.md

@@ -0,0 +1,74 @@
+# Responses and Redirects
+
+Extractors provide an easy way to access request data inside server functions. Leptos also provides a way to modify the HTTP response, using the `ResponseOptions` type (see docs for [Actix](https://docs.rs/leptos_actix/latest/leptos_actix/struct.ResponseOptions.html) or [Axum](https://docs.rs/leptos_axum/latest/leptos_axum/struct.ResponseOptions.html)) types and the `redirect` helper function (see docs for [Actix](https://docs.rs/leptos_actix/latest/leptos_actix/fn.redirect.html) or [Axum](https://docs.rs/leptos_axum/latest/leptos_axum/fn.redirect.html)).
+
+## `ResponseOptions`
+
+`ResponseOptions` is provided via context during the initial server rendering response and during any subsequent server function call. It allows you to easily set the status code for the HTTP response, or to add headers to the HTTP response, e.g., to set cookies.
+
+```rust
+#[server(TeaAndCookies)]
+pub async fn tea_and_cookies(cx: Scope) -> Result<(), ServerFnError> {
+	use actix_web::{cookie::Cookie, http::header, http::header::HeaderValue};
+	use leptos_actix::ResponseOptions;
+
+	// pull ResponseOptions from context
+	let response = expect_context::<ResponseOptions>(cx);
+
+	// set the HTTP status code
+	response.set_status(StatusCode::IM_A_TEAPOT);
+
+	// set a cookie in the HTTP response
+	let mut cookie = Cookie::build("biscuits", "yes").finish();
+	if let Ok(cookie) = HeaderValue::from_str(&cookie.to_string()) {
+		res.insert_header(header::SET_COOKIE, cookie);
+	}
+}
+```
+
+## `redirect`
+
+One common modification to an HTTP response is to redirect to another page. The Actix and Axum integrations provide a `redirect` function to make this easy to do. `redirect` simply sets an HTTP status code of `302 Found` and sets the `Location` header.
+
+Here’s a simplified example from our [`session_auth_axum` example](https://github.com/leptos-rs/leptos/blob/a5f73b441c079f9138102b3a7d8d4828f045448c/examples/session_auth_axum/src/auth.rs#L154-L181).
+
+```rust
+#[server(Login, "/api")]
+pub async fn login(
+    cx: Scope,
+    username: String,
+    password: String,
+    remember: Option<String>,
+) -> Result<(), ServerFnError> {
+	// pull the DB pool and auth provider from context
+    let pool = pool(cx)?;
+    let auth = auth(cx)?;
+
+	// check whether the user exists
+    let user: User = User::get_from_username(username, &pool)
+        .await
+        .ok_or_else(|| {
+            ServerFnError::ServerError("User does not exist.".into())
+        })?;
+
+	// check whether the user has provided the correct password
+    match verify(password, &user.password)? {
+		// if the password is correct...
+        true => {
+			// log the user in
+            auth.login_user(user.id);
+            auth.remember_user(remember.is_some());
+
+			// and redirect to the home page
+            leptos_axum::redirect(cx, "/");
+            Ok(())
+        }
+		// if not, return an error
+        false => Err(ServerFnError::ServerError(
+            "Password does not match.".to_string(),
+        )),
+    }
+}
+```
+
+This server function can then be used from your application. This `redirect` works well with the progressively-enhanced `<ActionForm/>` component: without JS/WASM, the server response will redirect because of the status code and header. With JS/WASM, the `<ActionForm/>` will detect the redirect in the server function response, and use client-side navigation to redirect to the new page.

docs/book/src/ssr/23_ssr_modes.md

@@ -62,6 +62,16 @@ If you’re using server-side rendering, the synchronous mode is almost never wh
   - Able to show the fallback loading state and dynamically replace it, instead of showing blank sections for un-loaded data.
 - _Cons_: Requires JavaScript to be enabled for suspended fragments to appear in correct order. (This small chunk of JS streamed down in a `<script>` tag alongside the `<template>` tag that contains the rendered `<Suspense/>` fragment, so it does not need to load any additional JS files.)
 
+5. **Partially-blocked streaming**: “Partially-blocked” streaming is useful when you have multiple separate `<Suspense/>` components on the page. If one of them reads from one or more “blocking resources” (see below), the fallback will not be sent; rather, the server will wait until that `<Suspense/>` has resolved and then replace the fallback with the resolved fragment on the server, which means that it is included in the initial HTML response and appears even if JavaScript is disabled or not supported. Other `<Suspense/>` stream in out of order as usual.
+
+This is useful when you have multiple `<Suspense/>` on the page, and one is more important than the other: think of a blog post and comments, or product information and reviews. It is *not* useful if there’s only one `<Suspense/>`, or if every `<Suspense/>` reads from blocking resources. In those cases it is a slower form of `async` rendering.
+
+- _Pros_: Works if JavaScript is disabled or not supported on the user’s device.
+- _Cons_
+  - Slower initial response time than out-of-order.
+  - Marginally overall response due to additional work on the server.
+  - No fallback state shown.
+
 ## Using SSR Modes
 
 Because it offers the best blend of performance characteristics, Leptos defaults to out-of-order streaming. But it’s really simple to opt into these different modes. You do it by adding an `ssr` property onto one or more of your `<Route/>` components, like in the [`ssr_modes` example](https://github.com/leptos-rs/leptos/blob/main/examples/ssr_modes/src/app.rs).

docs/book/src/view/01_basic_component.md

@@ -28,7 +28,7 @@ fn App(cx: Scope) -> impl IntoView {
     view! { cx,
         <button
             on:click=move |_| {
-                set_count.update(|n| *n += 1);
+                set_count(3);
             }
         >
             "Click me: "
@@ -78,8 +78,7 @@ This returns a `(getter, setter)` tuple. To access the current value, you’ll
 use `count.get()` (or, on `nightly` Rust, the shorthand `count()`). To set the
 current value, you’ll call `set_count.set(...)` (or `set_count(...)`).
 
-> `.get()` clones the value and `.set()` overwrites it. In many cases, it’s more
-> efficient to use `.with()` or `.update()`; check out the docs for [`ReadSignal`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html) and [`WriteSignal`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html) if you’d like to learn more about those trade-offs at this point.
+> `.get()` clones the value and `.set()` overwrites it. In many cases, it’s more efficient to use `.with()` or `.update()`; check out the docs for [`ReadSignal`](https://docs.rs/leptos/latest/leptos/struct.ReadSignal.html) and [`WriteSignal`](https://docs.rs/leptos/latest/leptos/struct.WriteSignal.html) if you’d like to learn more about those trade-offs at this point.
 
 ## The View
 
@@ -90,7 +89,8 @@ view! { cx,
     <button
         // define an event listener with on:
         on:click=move |_| {
-            set_count.update(|n| *n += 1);
+            // on stable, this is set_count.set(3);
+            set_count(3);
         }
     >
         // text nodes are wrapped in quotation marks
@@ -142,6 +142,16 @@ in a function, telling the framework to update the view every time `count` chang
 `{count()}` access the value of `count` once, and passes an `i32` into the view,
 rendering it once, unreactively. You can see the difference in the CodeSandbox below!
 
+Let’s make one final change. `set_count(3)` is a pretty useless thing for a click handler to do. Let’s replace “set this value to 3” with “increment this value by 1”:
+
+```rust
+move |_| {
+    set_count.update(|n| *n += 1);
+}
+```
+
+You can see here that while `set_count` just sets the value, `set_count.update()` gives us a mutable reference and mutates the value in place. Either one will trigger a reactive update in our UI.
+
 > Throughout this tutorial, we’ll use CodeSandbox to show interactive examples. To
 > show the browser in the sandbox, you may need to click `Add DevTools >
 Other Previews > 8080.` Hover over any of the variables to show Rust-Analyzer details

docs/book/src/view/03_components.md

@@ -15,7 +15,7 @@ You _could_ do this by just creating two `<progress>` elements:
 let (count, set_count) = create_signal(cx, 0);
 let double_count = move || count() * 2;
 
-view! {
+view! { cx,
     <progress
         max="50"
         value=count
@@ -98,18 +98,6 @@ notice that you can easily tell the difference between an element and a componen
 because components always have `PascalCase` names. You pass the `progress` prop
 in as if it were an HTML element attribute. Simple.
 
-> ### Important Note
->
-> For every `Component`, Leptos generates a corresponding `ComponentProps` type. This
-> is what allows us to have named props, when Rust does not have named function parameters.
-> If you’re defining a component in one module and importing it into another, make
-> sure you include this `ComponentProps` type:
->
-> `use progress_bar::{ProgressBar, ProgressBarProps};`
->
-> **Note**: This is still true as of `0.2.5`, but the requirement has been removed on `main`
-> and will not apply to later versions.
-
 ### Reactive and Static Props
 
 You’ll notice that throughout this example, `progress` takes a reactive

docs/book/src/view/06_control_flow.md

@@ -198,7 +198,7 @@ let (value, set_value) = create_signal(cx, 0);
 
 view! { cx,
   <Show
-    when=move || value() > 5
+    when=move || { value() > 5 }
     fallback=|cx| view! { cx, <Small/> }
   >
     <Big/>

docs/book/src/view/07_errors.md

@@ -19,7 +19,7 @@ fn NumericInput(cx: Scope) -> impl IntoView {
     view! { cx,
         <label>
             "Type a number (or not!)"
-            <input type="number" on:input=on_input/>
+            <input on:input=on_input/>
             <p>
                 "You entered "
                 <strong>{value}</strong>
@@ -69,7 +69,7 @@ fn NumericInput(cx: Scope) -> impl IntoView {
         <h1>"Error Handling"</h1>
         <label>
             "Type a number (or something that's not a number!)"
-            <input type="number" on:input=on_input/>
+            <input on:input=on_input/>
             <ErrorBoundary
                 // the fallback receives a signal containing current errors
                 fallback=|cx, errors| view! { cx,

docs/book/src/view/08_parent_child.md

@@ -117,7 +117,7 @@ pub fn App(cx: Scope) -> impl IntoView {
 
 
 #[component]
-pub fn ButtonC<F>(cx: Scope) -> impl IntoView {
+pub fn ButtonC(cx: Scope) -> impl IntoView {
     view! { cx,
         <button>"Toggle"</button>
     }

examples/Makefile.toml

@@ -1,4 +1,4 @@
-extend = [{ path = "./cargo-make/common.toml" }]
+extend = [{ path = "./cargo-make/main.toml" }]
 
 [env]
 CARGO_MAKE_EXTEND_WORKSPACE_MAKEFILE = true
@@ -15,43 +15,33 @@ CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = [
     "fetch",
     "hackernews",
     "hackernews_axum",
+    "js-framework-benchmark",
+    "leptos-tailwind-axum",
     "login_with_token_csr_only",
     "parent_child",
     "router",
     "session_auth_axum",
+    "slots",
     "ssr_modes",
     "ssr_modes_axum",
     "tailwind",
     "tailwind_csr_trunk",
+    "timer",
     "todo_app_sqlite",
     "todo_app_sqlite_axum",
     "todo_app_sqlite_viz",
     "todomvc",
 ]
 
-[tasks.verify-flow]
-description = "Provides pre and post hooks for verify"
-dependencies = ["pre-verify", "verify", "post-verify"]
-
-[tasks.verify]
-description = "Run all quality checks and tests"
-dependencies = ["check-style", "test-unit-and-web"]
-
-[tasks.test-unit-and-web]
-description = "Run all unit and web tests"
-dependencies = ["test-flow", "web-test-flow"]
-
-[tasks.pre-verify]
-
-[tasks.post-verify]
-dependencies = ["clean-all"]
-
-[tasks.web-test-flow]
-description = "Provides pre and post hooks for web-test"
-dependencies = ["pre-web-test", "web-test", "post-web-test"]
-
-[tasks.pre-web-test]
-
-[tasks.web-test]
-
-[tasks.post-web-test]
+[tasks.gen-members]
+workspace = false
+description = "Generate the list of workspace members"
+script = '''
+examples=$(ls | 
+grep -v README.md | 
+grep -v Makefile.toml | 
+grep -v cargo-make | 
+grep -v gtk | 
+jq -R -s -c 'split("\n")[:-1]')
+echo "CARGO_MAKE_CRATE_WORKSPACE_MEMBERS = $examples"
+'''

examples/README.md

@@ -0,0 +1,7 @@
+# Examples
+
+The examples in this directory are all built and tested against the current `main` branch.
+
+To the extent that new features have been released or breaking changes have been made since the previous release, the examples are compatible with the `main` branch and not the current release.
+
+To see the examples as they were at the time of the `0.3.0` release, [click here](https://github.com/leptos-rs/leptos/tree/v0.3.0/examples).

examples/cargo-make/cargo-leptos-test.toml

@@ -0,0 +1,6 @@
+[tasks.integration-test]
+dependencies = ["cargo-leptos-e2e"]
+
+[tasks.cargo-leptos-e2e]
+command = "cargo"
+args = ["leptos", "end-to-end"]

examples/cargo-make/clean.toml

@@ -0,0 +1,28 @@
+[tasks.clean]
+dependencies = [
+    "clean-cargo",
+    "clean-trunk",
+    "clean-node_modules",
+    "clean-playwright",
+]
+
+[tasks.clean-cargo]
+command = "cargo"
+args = ["clean"]
+
+[tasks.clean-trunk]
+command = "trunk"
+args = ["clean"]
+
+[tasks.clean-node_modules]
+script = '''
+project_dir=${PWD##*/}
+if [ "$project_dir" != "todomvc" ]; then
+  find . -type d -name node_modules | xargs rm -rf
+fi
+'''
+
+[tasks.clean-playwright]
+script = '''
+find . -name playwright-report -name playwright -name test-results | xargs rm -rf
+'''

examples/cargo-make/common.toml

@@ -1,23 +0,0 @@
-[tasks.pre-clippy]
-env = { CARGO_MAKE_CLIPPY_ARGS = "--all-targets --all-features -- -D warnings" }
-
-[tasks.check-style]
-description = "Check for style violations"
-dependencies = ["check-format-flow", "clippy-flow"]
-
-[tasks.verify-local]
-description = "Run all quality checks and tests from an example directory"
-dependencies = ["check-style", "test-local"]
-
-[tasks.test-local]
-description = "Run all tests from an example directory"
-dependencies = ["test", "web-test"]
-
-[tasks.clean-trunk]
-description = "Runs the trunk clean command."
-category = "Cleanup"
-command = "trunk"
-args = ["clean"]
-
-[tasks.clean-all]
-dependencies = ["clean", "clean-trunk"]

examples/cargo-make/lint.toml

@@ -0,0 +1,9 @@
+[tasks.pre-clippy]
+env = { CARGO_MAKE_CLIPPY_ARGS = "--all-targets --all-features -- -D warnings" }
+
+[tasks.check-style]
+dependencies = ["check-format-flow", "clippy-flow"]
+
+[tasks.check-format]
+env = { LEPTOS_PROJECT_DIRECTORY = "../../" }
+args = ["fmt", "--", "--check", "--config-path", "${LEPTOS_PROJECT_DIRECTORY}"]

examples/cargo-make/main.toml

@@ -0,0 +1,32 @@
+extend = [
+    { path = "../cargo-make/clean.toml" },
+    { path = "../cargo-make/lint.toml" },
+    { path = "../cargo-make/node.toml" },
+]
+
+# CI Stages
+
+[tasks.ci]
+dependencies = ["prepare", "lint", "build", "test-flow", "integration-test"]
+
+[tasks.ci-clean]
+dependencies = ["ci", "clean"]
+
+[tasks.prepare]
+dependencies = ["setup-node"]
+
+[tasks.lint]
+dependencies = ["check-style"]
+
+[tasks.integration-test]
+
+# ALIASES
+
+[tasks.verify-flow]
+alias = "ci"
+
+[tasks.t]
+dependencies = ["test-flow"]
+
+[tasks.it]
+alias = "integration-test"

examples/cargo-make/node.toml

@@ -0,0 +1,43 @@
+[tasks.setup-node]
+description = "Install node dependencies and playwright browsers"
+env = { PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD = "1" }
+script = '''
+BOLD="\e[1m"
+GREEN="\e[0;32m"
+RED="\e[0;31m"
+RESET="\e[0m"
+
+project_dir=$CARGO_MAKE_WORKING_DIRECTORY
+
+# Discover commands
+if command -v pnpm; then
+    NODE_CMD=pnpm
+    PLAYWRIGHT_CMD=pnpm
+elif command -v npm; then
+    NODE_CMD=npm
+    PLAYWRIGHT_CMD=npx
+else
+    echo "${RED}${BOLD}ERROR${RESET} - pnpm or npm is required by this task"
+    exit 1
+fi
+
+# Install node dependencies
+for node_path in $(find . -name package.json -not -path '*/node_modules/*')
+do
+  node_dir=$(dirname $node_path)
+  echo Install node dependencies for $node_dir
+  cd $node_dir
+  ${NODE_CMD} install
+  cd ${project_dir}
+done
+
+# Install playwright browsers
+for pw_path in $(find . -name playwright.config.ts)
+do
+  pw_dir=$(dirname $pw_path)
+  echo Install playwright browsers for $pw_dir
+  cd $pw_dir
+  ${PLAYWRIGHT_CMD} playwright install
+  cd $project_dir
+done
+'''

examples/cargo-make/playwright-test.toml

@@ -0,0 +1,4 @@
+extend = [{ path = "../cargo-make/playwright.toml" }]
+
+[tasks.integration-test]
+dependencies = ["test-playwright-autostart"]

examples/cargo-make/playwright.toml

@@ -0,0 +1,101 @@
+[tasks.test-playwright-autostart]
+command = "npm"
+args = ["run", "e2e:auto-start"]
+
+[tasks.test-playwright]
+script = '''
+BOLD="\e[1m"
+GREEN="\e[0;32m"
+RED="\e[0;31m"
+RESET="\e[0m"
+
+project_dir=$CARGO_MAKE_WORKING_DIRECTORY
+
+# Discover commands
+if command -v pnpm; then
+    PLAYWRIGHT_CMD=pnpm
+elif command -v npm; then
+    PLAYWRIGHT_CMD=npx
+else
+    echo "${RED}${BOLD}ERROR${RESET} - pnpm or npm is required by this task"
+    exit 1
+fi
+
+# Run playwright command
+for pw_path in $(find . -name playwright.config.ts)
+do
+  pw_dir=$(dirname $pw_path)
+  cd $pw_dir
+  ${PLAYWRIGHT_CMD} playwright test
+  cd $project_dir
+done
+'''
+
+[tasks.test-playwright-ui]
+script = '''
+BOLD="\e[1m"
+GREEN="\e[0;32m"
+RED="\e[0;31m"
+RESET="\e[0m"
+
+project_dir=$CARGO_MAKE_WORKING_DIRECTORY
+
+# Discover commands
+if command -v pnpm; then
+    PLAYWRIGHT_CMD=pnpm
+elif command -v npm; then
+    PLAYWRIGHT_CMD=npx
+else
+    echo "${RED}${BOLD}ERROR${RESET} - pnpm or npm is required by this task"
+    exit 1
+fi
+
+# Run playwright command
+for pw_path in $(find . -name playwright.config.ts)
+do
+  pw_dir=$(dirname $pw_path)
+  cd $pw_dir
+  ${PLAYWRIGHT_CMD} playwright test --ui
+  cd $project_dir
+done
+'''
+
+[tasks.test-playwright-report]
+script = '''
+BOLD="\e[1m"
+GREEN="\e[0;32m"
+RED="\e[0;31m"
+RESET="\e[0m"
+
+project_dir=$CARGO_MAKE_WORKING_DIRECTORY
+
+# Discover commands
+if command -v pnpm; then
+    PLAYWRIGHT_CMD=pnpm
+elif command -v npm; then
+    PLAYWRIGHT_CMD=npx
+else
+    echo "${RED}${BOLD}ERROR${RESET} - pnpm or npm is required by this task"
+    exit 1
+fi
+
+# Run playwright command
+for pw_path in $(find . -name playwright.config.ts)
+do
+  pw_dir=$(dirname $pw_path)
+  cd $pw_dir
+  ${PLAYWRIGHT_CMD} playwright show-report
+  cd $project_dir
+done
+'''
+
+# ALIASES
+
+[tasks.pw]
+dependencies = ["test-playwright"]
+
+[tasks.pw-ui]
+dependencies = ["test-playwright-ui"]
+
+[tasks.pw-report]
+dependencies = ["test-playwright-report"]

examples/cargo-make/trunk_server.toml

@@ -0,0 +1,18 @@
+[tasks.build]
+command = "trunk"
+args = ["build"]
+
+[tasks.start-trunk]
+command = "trunk"
+args = ["serve", "${@}"]
+
+[tasks.stop-trunk]
+script = '''
+  pkill -f "cargo-make"
+  pkill -f "trunk"
+'''
+
+# ALIASES
+
+[tasks.dev]
+dependencies = ["start-trunk"]

examples/cargo-make/wasm-test.toml

@@ -0,0 +1,11 @@
+[tasks.test]
+env = { RUN_CARGO_TEST = false }
+condition = { env_true = ["RUN_CARGO_TEST"] }
+
+[tasks.post-test]
+dependencies = ["test-wasm"]
+
+[tasks.test-wasm]
+env = { CARGO_MAKE_WASM_TEST_ARGS = "--headless --chrome" }
+command = "cargo"
+args = ["make", "wasm-pack-test"]

examples/cargo-make/wasm-web-test.toml

@@ -1,4 +0,0 @@
-[tasks.web-test]
-env = { CARGO_MAKE_WASM_TEST_ARGS = "--headless --chrome" }
-command = "cargo"
-args = ["make", "wasm-pack-test"]

examples/counter/Cargo.toml

@@ -8,7 +8,7 @@ codegen-units = 1
 lto = true
 
 [dependencies]
-leptos = { path = "../../leptos" }
+leptos = { path = "../../leptos", features = ["csr", "nightly"] }
 console_log = "1"
 log = "0.4"
 console_error_panic_hook = "0.1.7"

examples/counter/Makefile.toml

@@ -1,6 +1,6 @@
 extend = [
-    { path = "../cargo-make/common.toml" },
-    { path = "../cargo-make/wasm-web-test.toml" },
+    { path = "../cargo-make/main.toml" },
+    { path = "../cargo-make/wasm-test.toml" },
 ]
 
 [tasks.build]

examples/counter_isomorphic/Cargo.toml

@@ -19,19 +19,17 @@ console_error_panic_hook = "0.1"
 futures = "0.3"
 cfg-if = "1"
 lazy_static = "1"
-leptos = { path = "../../leptos", default-features = false, features = [
-	"serde",
-] }
+leptos = { path = "../../leptos" }
 leptos_actix = { path = "../../integrations/actix", optional = true }
-leptos_meta = { path = "../../meta", default-features = false }
-leptos_router = { path = "../../router", default-features = false }
+leptos_meta = { path = "../../meta" }
+leptos_router = { path = "../../router" }
 log = "0.4"
 gloo-net = { git = "https://github.com/rustwasm/gloo" }
-wasm-bindgen = "0.2"
+wasm-bindgen = "=0.2.87"
 serde = { version = "1", features = ["derive"] }
 
 [features]
-default = []
+default = ["nightly"]
 hydrate = ["leptos/hydrate", "leptos_meta/hydrate", "leptos_router/hydrate"]
 ssr = [
 	"dep:actix-files",
@@ -41,10 +39,10 @@ ssr = [
 	"leptos_meta/ssr",
 	"leptos_router/ssr",
 ]
-stable = ["leptos/stable", "leptos_router/stable"]
+nightly = ["leptos/nightly", "leptos_router/nightly"]
 
 [package.metadata.cargo-all-features]
-denylist = ["actix-files", "actix-web", "leptos_actix", "stable"]
+denylist = ["actix-files", "actix-web", "leptos_actix", "nightly"]
 skip_feature_sets = [["ssr", "hydrate"]]
 
 [package.metadata.leptos]

examples/counter_isomorphic/Makefile.toml

@@ -1,4 +1,4 @@
-extend = [{ path = "../cargo-make/common.toml" }]
+extend = [{ path = "../cargo-make/main.toml" }]
 
 [tasks.build]
 command = "cargo"

examples/counter_isomorphic/src/counters.rs

@@ -12,13 +12,6 @@ cfg_if! {
         lazy_static::lazy_static! {
             pub static ref COUNT_CHANNEL: BroadcastChannel<i32> = BroadcastChannel::new();
         }
-
-        pub fn register_server_functions() {
-            _ = GetServerCount::register();
-            _ = AdjustServerCount::register();
-            _ = ClearServerCount::register();
-        }
-
     }
 }
 
@@ -74,24 +67,10 @@ pub fn Counters(cx: Scope) -> impl IntoView {
             <Link rel="shortcut icon" type_="image/ico" href="/favicon.ico"/>
             <main>
                 <Routes>
-                    <Route
-                        path=""
-                        view=|cx| {
-                            view! { cx, <Counter/> }
-                        }
-                    />
-                    <Route
-                        path="form"
-                        view=|cx| {
-                            view! { cx, <FormCounter/> }
-                        }
-                    />
-                    <Route
-                        path="multi"
-                        view=|cx| {
-                            view! { cx, <MultiuserCounter/> }
-                        }
-                    />
+                    <Route path="" view=Counter/>
+                    <Route path="form" view=FormCounter/>
+                    <Route path="multi" view=MultiuserCounter/>
+                    <Route path="multi" view=NotFound/>
                 </Routes>
             </main>
         </Router>
@@ -182,13 +161,9 @@ pub fn FormCounter(cx: Scope) -> impl IntoView {
                 "This counter uses forms to set the value on the server. When progressively enhanced, it should behave identically to the “Simple Counter.”"
             </p>
             <div>
-                // calling a server function is the same as POSTing to its API URL
-                // so we can just do that with a form and button
                 <ActionForm action=clear>
                     <input type="submit" value="Clear"/>
                 </ActionForm>
-                // We can submit named arguments to the server functions
-                // by including them as input values with the same name
                 <ActionForm action=adjust>
                     <input type="hidden" name="delta" value="-1"/>
                     <input type="hidden" name="msg" value="form value down"/>
@@ -263,3 +238,14 @@ pub fn MultiuserCounter(cx: Scope) -> impl IntoView {
         </div>
     }
 }
+
+#[component]
+fn NotFound(cx: Scope) -> impl IntoView {
+    #[cfg(feature = "ssr")]
+    {
+        let resp = expect_context::<leptos_actix::ResponseOptions>(cx);
+        resp.set_status(actix_web::http::StatusCode::NOT_FOUND);
+    }
+
+    view! { cx, <h1>"Not Found"</h1> }
+}

examples/counter_isomorphic/src/main.rs

@@ -31,7 +31,12 @@ cfg_if! {
         #[actix_web::main]
         async fn main() -> std::io::Result<()> {
 
-            crate::counters::register_server_functions();
+            // Explicit server function registration is no longer required
+            // on the main branch. On 0.3.0 and earlier, uncomment the lines
+            // below to register the server functions.
+            // _ = GetServerCount::register();
+            // _ = AdjustServerCount::register();
+            // _ = ClearServerCount::register();
 
             // Setting this to None means we'll be using cargo-leptos and its env vars.
             // when not using cargo-leptos None must be replaced with Some("Cargo.toml")
@@ -47,15 +52,36 @@ cfg_if! {
                 App::new()
                     .service(counter_events)
                     .route("/api/{tail:.*}", leptos_actix::handle_server_fns())
-                    .leptos_routes(leptos_options.to_owned(), routes.to_owned(), |cx| view! { cx, <Counters/> })
-                    .service(Files::new("/", site_root))
+                    // serve JS/WASM/CSS from `pkg`
+                    .service(Files::new("/pkg", format!("{site_root}/pkg")))
+                    // serve other assets from the `assets` directory
+                    .service(Files::new("/assets", site_root))
+                    // serve the favicon from /favicon.ico
+                    .service(favicon)
+                    .leptos_routes(
+                        leptos_options.to_owned(),
+                        routes.to_owned(),
+                        Counters,
+                    )
+                    .app_data(web::Data::new(leptos_options.to_owned()))
                     //.wrap(middleware::Compress::default())
             })
             .bind(&addr)?
             .run()
             .await
         }
+
+        #[actix_web::get("favicon.ico")]
+        async fn favicon(
+            leptos_options: actix_web::web::Data<leptos::LeptosOptions>,
+        ) -> actix_web::Result<actix_files::NamedFile> {
+            let leptos_options = leptos_options.into_inner();
+            let site_root = &leptos_options.site_root;
+            Ok(actix_files::NamedFile::open(format!(
+                "{site_root}/favicon.ico"
+            ))?)
         }
+    }
 
     // client-only main for Trunk
     else {

examples/counter_without_macros/Cargo.toml

@@ -8,7 +8,7 @@ codegen-units = 1
 lto = true
 
 [dependencies]
-leptos = { path = "../../leptos", features = ["stable"] }
+leptos = { path = "../../leptos", features = ["csr"] }
 console_log = "1"
 log = "0.4"
 console_error_panic_hook = "0.1.7"

examples/counter_without_macros/Makefile.toml

@@ -1,6 +1,6 @@
 extend = [
-    { path = "../cargo-make/common.toml" },
-    { path = "../cargo-make/wasm-web-test.toml" },
+    { path = "../cargo-make/main.toml" },
+    { path = "../cargo-make/wasm-test.toml" },
 ]
 
 [tasks.build]

examples/counter_without_macros/src/main.rs

@@ -1,6 +1,7 @@
 use counter_without_macros::counter;
 use leptos::*;
 
+/// Show the counter
 pub fn main() {
     _ = console_log::init_with_level(log::Level::Debug);
     console_error_panic_hook::set_once();

examples/counters/Cargo.toml

@@ -4,7 +4,7 @@ version = "0.1.0"
 edition = "2021"
 
 [dependencies]
-leptos = { path = "../../leptos" }
+leptos = { path = "../../leptos", features = ["csr", "nightly"]  }
 log = "0.4"
 console_log = "1"
 console_error_panic_hook = "0.1.7"

examples/counters/Makefile.toml

@@ -1,6 +1,6 @@
 extend = [
-    { path = "../cargo-make/common.toml" },
-    { path = "../cargo-make/wasm-web-test.toml" },
+    { path = "../cargo-make/main.toml" },
+    { path = "../cargo-make/wasm-test.toml" },
 ]
 
 [tasks.build]

examples/counters/tests/web.rs

@@ -107,7 +107,7 @@ fn inc() {
          Counters</button><button>Clear Counters</button><p>Total: <span><!-- \
          <DynChild> -->5<!-- </DynChild> --></span> from <span><!-- \
          <DynChild> -->2<!-- </DynChild> --></span> counters.</p><ul><!-- \
-         <Each> --><!-- <EachItem> --><!-- <Counter> \
+         <Each> --><!-- <EachItem> --><!-- <EachItem> --><!-- <Counter> \
          --><li><button>-1</button><input type=\"text\"><span><!-- <DynChild> \
          -->2<!-- </DynChild> \
          --></span><button>+1</button><button>x</button></li><!-- </Counter> \

examples/counters_stable/.gitignore

@@ -0,0 +1,20 @@
+# Generated by Cargo
+# will have compiled files and executables
+/target/
+
+# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
+# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
+Cargo.lock
+
+# These are backup files generated by rustfmt
+**/*.rs.bk
+
+# Support playwright testing
+node_modules/
+test-results/
+end2end/playwright-report/
+playwright/.cache/
+pnpm-lock.yaml
+
+# Support trunk
+dist

examples/counters_stable/Cargo.toml

@@ -4,11 +4,24 @@ version = "0.1.0"
 edition = "2021"
 
 [dependencies]
-leptos = { path = "../../leptos", features = ["stable"] }
+leptos = { path = "../../leptos", features = ["csr"] }
+leptos_meta = { path = "../../meta", features = ["csr"] }
 log = "0.4"
 console_log = "1"
 console_error_panic_hook = "0.1.7"
 
 [dev-dependencies]
-wasm-bindgen-test = "0.3.0"
+wasm-bindgen = "0.2.87"
+wasm-bindgen-test = "0.3.37"
+pretty_assertions = "1.3.0"
 
+[dev-dependencies.web-sys]
+features = [
+    "Event",
+    "EventInit",
+    "EventTarget",
+    "HtmlElement",
+    "HtmlInputElement",
+    "XPathResult",
+]
+version = "0.3.64"

examples/counters_stable/Makefile.toml

@@ -1,3 +1,10 @@
+extend = [
+    { path = "../cargo-make/main.toml" },
+    { path = "../cargo-make/wasm-test.toml" },
+    { path = "../cargo-make/trunk_server.toml" },
+    { path = "../cargo-make/playwright-test.toml" },
+]
+
 [tasks.build]
 command = "cargo"
 args = ["+stable", "build-all-features"]

examples/counters_stable/e2e/.gitignore

@@ -0,0 +1,4 @@
+node_modules/
+/test-results/
+/playwright-report/
+/playwright/.cache/

examples/counters_stable/e2e/package-lock.json

@@ -0,0 +1,83 @@
+{
+  "name": "grip",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "grip",
+      "devDependencies": {
+        "@playwright/test": "^1.35.1"
+      }
+    },
+    "node_modules/.pnpm/@playwright+test@1.33.0": {
+      "extraneous": true
+    },
+    "node_modules/.pnpm/@types+node@20.2.1/node_modules/@types/node": {
+      "version": "20.2.1",
+      "extraneous": true,
+      "license": "MIT"
+    },
+    "node_modules/.pnpm/playwright-core@1.33.0/node_modules/playwright-core": {
+      "version": "1.33.0",
+      "extraneous": true,
+      "license": "Apache-2.0",
+      "bin": {
+        "playwright": "cli.js"
+      },
+      "engines": {
+        "node": ">=14"
+      }
+    },
+    "node_modules/@playwright/test": {
+      "version": "1.35.1",
+      "resolved": "https://registry.npmjs.org/@playwright/test/-/test-1.35.1.tgz",
+      "integrity": "sha512-b5YoFe6J9exsMYg0pQAobNDR85T1nLumUYgUTtKm4d21iX2L7WqKq9dW8NGJ+2vX0etZd+Y7UeuqsxDXm9+5ZA==",
+      "dev": true,
+      "dependencies": {
+        "@types/node": "*",
+        "playwright-core": "1.35.1"
+      },
+      "bin": {
+        "playwright": "cli.js"
+      },
+      "engines": {
+        "node": ">=16"
+      },
+      "optionalDependencies": {
+        "fsevents": "2.3.2"
+      }
+    },
+    "node_modules/@types/node": {
+      "version": "20.3.1",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-20.3.1.tgz",
+      "integrity": "sha512-EhcH/wvidPy1WeML3TtYFGR83UzjxeWRen9V402T8aUGYsCHOmfoisV3ZSg03gAFIbLq8TnWOJ0f4cALtnSEUg==",
+      "dev": true
+    },
+    "node_modules/fsevents": {
+      "version": "2.3.2",
+      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.2.tgz",
+      "integrity": "sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==",
+      "dev": true,
+      "hasInstallScript": true,
+      "optional": true,
+      "os": [
+        "darwin"
+      ],
+      "engines": {
+        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
+      }
+    },
+    "node_modules/playwright-core": {
+      "version": "1.35.1",
+      "resolved": "https://registry.npmjs.org/playwright-core/-/playwright-core-1.35.1.tgz",
+      "integrity": "sha512-pNXb6CQ7OqmGDRspEjlxE49w+4YtR6a3X6mT1hZXeJHWmsEz7SunmvZeiG/+y1yyMZdHnnn73WKYdtV1er0Xyg==",
+      "dev": true,
+      "bin": {
+        "playwright-core": "cli.js"
+      },
+      "engines": {
+        "node": ">=16"
+      }
+    }
+  }
+}

examples/counters_stable/e2e/package.json

@@ -0,0 +1,7 @@
+{
+  "private": "true",
+  "scripts": {},
+  "devDependencies": {
+    "@playwright/test": "^1.35.1"
+  }
+}

examples/counters_stable/e2e/playwright.config.ts

@@ -0,0 +1,77 @@
+import { defineConfig, devices } from "@playwright/test";
+
+/**
+ * Read environment variables from file.
+ * https://github.com/motdotla/dotenv
+ */
+// require('dotenv').config();
+
+/**
+ * See https://playwright.dev/docs/test-configuration.
+ */
+export default defineConfig({
+  testDir: "./tests",
+  /* Run tests in files in parallel */
+  fullyParallel: true,
+  /* Fail the build on CI if you accidentally left test.only in the source code. */
+  forbidOnly: !process.env.DEV,
+  /* Retry on CI only */
+  retries: process.env.DEV ? 0 : 10,
+  /* Opt out of parallel tests on CI. */
+  workers: process.env.DEV ? 1 : 1,
+  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
+  reporter: [["html", { open: "never" }], ["list"]],
+  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
+  use: {
+    /* Base URL to use in actions like `await page.goto('/')`. */
+    baseURL: "http://127.0.0.1:8080",
+
+    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
+    trace: "on-first-retry",
+  },
+
+  /* Configure projects for major browsers */
+  projects: [
+    {
+      name: "chromium",
+      use: { ...devices["Desktop Chrome"] },
+    },
+
+    // {
+    //   name: "firefox",
+    //   use: { ...devices["Desktop Firefox"] },
+    // },
+
+    // {
+    //   name: "webkit",
+    //   use: { ...devices["Desktop Safari"] },
+    // },
+
+    /* Test against mobile viewports. */
+    // {
+    //   name: 'Mobile Chrome',
+    //   use: { ...devices['Pixel 5'] },
+    // },
+    // {
+    //   name: 'Mobile Safari',
+    //   use: { ...devices['iPhone 12'] },
+    // },
+
+    /* Test against branded browsers. */
+    // {
+    //   name: 'Microsoft Edge',
+    //   use: { ...devices['Desktop Edge'], channel: 'msedge' },
+    // },
+    // {
+    //   name: 'Google Chrome',
+    //   use: { ..devices['Desktop Chrome'], channel: 'chrome' },
+    // },
+  ],
+
+  /* Run your local dev server before starting the tests */
+  // webServer: {
+  //   command: "cd ../ && trunk serve",
+  //   url: "http://127.0.0.1:8080",
+  //   reuseExistingServer: false, //!process.env.CI,
+  // },
+});

examples/counters_stable/e2e/tests/add_1k_counters.spec.ts

@@ -0,0 +1,19 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Add 1000 Counters", () => {
+  test("should increase the number of counters", async ({ page }) => {
+    const ui = new CountersPage(page);
+
+    await Promise.all([
+      await ui.goto(),
+      await ui.addOneThousandCountersButton.waitFor(),
+    ]);
+
+    await ui.addOneThousandCounters();
+    await ui.addOneThousandCounters();
+    await ui.addOneThousandCounters();
+
+    await expect(ui.counters).toHaveText("3000");
+  });
+});

examples/counters_stable/e2e/tests/add_counter.spec.ts

@@ -0,0 +1,15 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Add Counter", () => {
+  test("should increase the number of counters", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+
+    await ui.addCounter();
+    await ui.addCounter();
+    await ui.addCounter();
+
+    await expect(ui.counters).toHaveText("3");
+  });
+});

examples/counters_stable/e2e/tests/clear_counters.spec.ts

@@ -0,0 +1,18 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Clear Counters", () => {
+  test("should reset the counts", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+
+    await ui.addCounter();
+    await ui.addCounter();
+    await ui.addCounter();
+
+    await ui.clearCounters();
+
+    await expect(ui.total).toHaveText("0");
+    await expect(ui.counters).toHaveText("0");
+  });
+});

examples/counters_stable/e2e/tests/decrement_count.spec.ts

@@ -0,0 +1,16 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Decrement Count", () => {
+  test("should decrease the total count", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+    await ui.addCounter();
+
+    await ui.decrementCount();
+    await ui.decrementCount();
+    await ui.decrementCount();
+
+    await expect(ui.total).toHaveText("-3");
+  });
+});

examples/counters_stable/e2e/tests/enter_count.spec.ts

@@ -0,0 +1,30 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Enter Count", () => {
+  test("should increase the total count", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+    await ui.addCounter();
+
+    await ui.enterCount("5");
+
+    await expect(ui.total).toHaveText("5");
+    await expect(ui.counters).toHaveText("1");
+  });
+
+  test("should decrease the total count", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+    await ui.addCounter();
+    await ui.addCounter();
+    await ui.addCounter();
+
+    await ui.enterCount("100");
+    await ui.enterCount("100", 1);
+    await ui.enterCount("100", 2);
+    await ui.enterCount("50", 1);
+
+    await expect(ui.total).toHaveText("250");
+  });
+});

examples/counters_stable/e2e/tests/fixtures/counters_page.ts

@@ -0,0 +1,98 @@
+import { expect, Locator, Page } from "@playwright/test";
+
+export class CountersPage {
+  readonly page: Page;
+  readonly addCounterButton: Locator;
+  readonly addOneThousandCountersButton: Locator;
+  readonly clearCountersButton: Locator;
+
+  readonly incrementCountButton: Locator;
+  readonly counterInput: Locator;
+  readonly decrementCountButton: Locator;
+  readonly removeCountButton: Locator;
+
+  readonly total: Locator;
+  readonly counters: Locator;
+
+  constructor(page: Page) {
+    this.page = page;
+
+    this.addCounterButton = page.locator("button", { hasText: "Add Counter" });
+
+    this.addOneThousandCountersButton = page.locator("button", {
+      hasText: "Add 1000 Counters",
+    });
+
+    this.clearCountersButton = page.locator("button", {
+      hasText: "Clear Counters",
+    });
+
+    this.decrementCountButton = page.locator("button", {
+      hasText: "-1",
+    });
+
+    this.incrementCountButton = page.locator("button", {
+      hasText: "+1",
+    });
+
+    this.removeCountButton = page.locator("button", {
+      hasText: "x",
+    });
+
+    this.total = page.getByTestId("total");
+
+    this.counters = page.getByTestId("counters");
+
+    this.counterInput = page.getByRole("textbox");
+  }
+
+  async goto() {
+    await this.page.goto("/");
+  }
+
+  async addCounter() {
+    await Promise.all([
+      this.addCounterButton.waitFor(),
+      this.addCounterButton.click(),
+    ]);
+  }
+
+  async addOneThousandCounters() {
+    this.addOneThousandCountersButton.click();
+  }
+
+  async decrementCount(index: number = 0) {
+    await Promise.all([
+      this.decrementCountButton.nth(index).waitFor(),
+      this.decrementCountButton.nth(index).click(),
+    ]);
+  }
+
+  async incrementCount(index: number = 0) {
+    await Promise.all([
+      this.incrementCountButton.nth(index).waitFor(),
+      this.incrementCountButton.nth(index).click(),
+    ]);
+  }
+
+  async clearCounters() {
+    await Promise.all([
+      this.clearCountersButton.waitFor(),
+      this.clearCountersButton.click(),
+    ]);
+  }
+
+  async enterCount(count: string, index: number = 0) {
+    await Promise.all([
+      this.counterInput.nth(index).waitFor(),
+      this.counterInput.nth(index).fill(count),
+    ]);
+  }
+
+  async removeCounter(index: number = 0) {
+    await Promise.all([
+      this.removeCountButton.nth(index).waitFor(),
+      this.removeCountButton.nth(index).click(),
+    ]);
+  }
+}

examples/counters_stable/e2e/tests/increment_count.spec.ts

@@ -0,0 +1,16 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Increment Count", () => {
+  test("should increase the total count", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+    await ui.addCounter();
+
+    await ui.incrementCount();
+    await ui.incrementCount();
+    await ui.incrementCount();
+
+    await expect(ui.total).toHaveText("3");
+  });
+});

examples/counters_stable/e2e/tests/remove_counter.spec.ts

@@ -0,0 +1,17 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("Remove Counter", () => {
+  test("should decrement the number of counters", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+
+    await ui.addCounter();
+    await ui.addCounter();
+    await ui.addCounter();
+
+    await ui.removeCounter(1);
+
+    await expect(ui.counters).toHaveText("2");
+  });
+});

examples/counters_stable/e2e/tests/view_counters.spec.ts

@@ -0,0 +1,19 @@
+import { test, expect } from "@playwright/test";
+import { CountersPage } from "./fixtures/counters_page";
+
+test.describe("View Counters", () => {
+  test("should see the title", async ({ page }) => {
+    const ui = new CountersPage(page);
+    await ui.goto();
+
+    await expect(page).toHaveTitle("Counters (Stable)");
+  });
+
+  test("should see the initial counts", async ({ page }) => {
+    const counters = new CountersPage(page);
+    await counters.goto();
+
+    await expect(counters.total).toHaveText("0");
+    await expect(counters.counters).toHaveText("0");
+  });
+});

examples/counters_stable/index.html

@@ -1,6 +1,7 @@
 <!DOCTYPE html>
 <html>
 	<head>
+		<title>Counters (Stable)</title>
 		<link data-trunk rel="rust" data-wasm-opt="z" data-weak-refs/>
 	</head>
 	<body></body>

examples/counters_stable/package.json

@@ -0,0 +1,11 @@
+{
+  "private": "true",
+  "scripts": {
+    "start-server": "trunk serve",
+    "e2e": "cargo make test-playwright",
+    "e2e:auto-start": "start-server-and-test start-server http://127.0.0.1:8080 e2e"
+  },
+  "devDependencies": {
+    "start-server-and-test": "^1.15.4"
+  }
+}

examples/counters_stable/src/lib.rs

@@ -0,0 +1,109 @@
+use leptos::*;
+use leptos_meta::*;
+
+const MANY_COUNTERS: usize = 1000;
+
+type CounterHolder = Vec<(usize, (ReadSignal<i32>, WriteSignal<i32>))>;
+
+#[derive(Copy, Clone)]
+struct CounterUpdater {
+    set_counters: WriteSignal<CounterHolder>,
+}
+
+#[component]
+pub fn Counters(cx: Scope) -> impl IntoView {
+    let (next_counter_id, set_next_counter_id) = create_signal(cx, 0);
+    let (counters, set_counters) = create_signal::<CounterHolder>(cx, vec![]);
+    provide_context(cx, CounterUpdater { set_counters });
+    provide_meta_context(cx);
+
+    let add_counter = move |_| {
+        let id = next_counter_id.get();
+        let sig = create_signal(cx, 0);
+        set_counters.update(move |counters| counters.push((id, sig)));
+        set_next_counter_id.update(|id| *id += 1);
+    };
+
+    let add_many_counters = move |_| {
+        let next_id = next_counter_id.get();
+        let new_counters = (next_id..next_id + MANY_COUNTERS).map(|id| {
+            let signal = create_signal(cx, 0);
+            (id, signal)
+        });
+
+        set_counters.update(move |counters| counters.extend(new_counters));
+        set_next_counter_id.update(|id| *id += MANY_COUNTERS);
+    };
+
+    let clear_counters = move |_| {
+        set_counters.update(|counters| counters.clear());
+    };
+
+    view! { cx,
+        <Title text="Counters (Stable)" />
+        <div>
+            <button on:click=add_counter>
+                "Add Counter"
+            </button>
+            <button on:click=add_many_counters>
+                {format!("Add {MANY_COUNTERS} Counters")}
+            </button>
+            <button on:click=clear_counters>
+                "Clear Counters"
+            </button>
+            <p>
+                "Total: "
+                <span data-testid="total">{move ||
+                    counters.get()
+                        .iter()
+                        .map(|(_, (count, _))| count.get())
+                        .sum::<i32>()
+                        .to_string()
+                }</span>
+                " from "
+                <span data-testid="counters">{move || counters.with(|counters| counters.len()).to_string()}</span>
+                " counters."
+            </p>
+            <ul>
+                <For
+                    each={move || counters.get()}
+                    key={|counter| counter.0}
+                    view=move |cx, (id, (value, set_value))| {
+                        view! {
+                            cx,
+                            <Counter id value set_value/>
+                        }
+                    }
+                />
+            </ul>
+        </div>
+    }
+}
+
+#[component]
+fn Counter(
+    cx: Scope,
+    id: usize,
+    value: ReadSignal<i32>,
+    set_value: WriteSignal<i32>,
+) -> impl IntoView {
+    let CounterUpdater { set_counters } = use_context(cx).unwrap();
+
+    let input = move |ev| {
+        set_value
+            .set(event_target_value(&ev).parse::<i32>().unwrap_or_default())
+    };
+
+    view! { cx,
+        <li>
+            <button data-testid="decrement_count" on:click=move |_| set_value.update(move |value| *value -= 1)>"-1"</button>
+            <input data-testid="counter_input" type="text"
+                prop:value={move || value.get().to_string()}
+                on:input=input
+            />
+            <span>{value}</span>
+            <button data-testid="increment_count" on:click=move |_| set_value.update(move |value| *value += 1)>"+1"</button>
+            <button data-testid="remove_counter" on:click=move |_| set_counters.update(move |counters| counters.retain(|(counter_id, _)| counter_id != &id))>"x"</button>
+        </li>
+    }
+}

examples/counters_stable/src/main.rs

@@ -1,3 +1,4 @@
+use counters_stable::Counters;
 use leptos::*;
 
 fn main() {
@@ -5,108 +6,3 @@ fn main() {
     console_error_panic_hook::set_once();
     mount_to_body(|cx| view! { cx,  <Counters/> })
 }
-
-const MANY_COUNTERS: usize = 1000;
-
-type CounterHolder = Vec<(usize, (ReadSignal<i32>, WriteSignal<i32>))>;
-
-#[derive(Copy, Clone)]
-struct CounterUpdater {
-    set_counters: WriteSignal<CounterHolder>,
-}
-
-#[component]
-pub fn Counters(cx: Scope) -> impl IntoView {
-    let (next_counter_id, set_next_counter_id) = create_signal(cx, 0);
-    let (counters, set_counters) = create_signal::<CounterHolder>(cx, vec![]);
-    provide_context(cx, CounterUpdater { set_counters });
-
-    let add_counter = move |_| {
-        let id = next_counter_id.get();
-        let sig = create_signal(cx, 0);
-        set_counters.update(move |counters| counters.push((id, sig)));
-        set_next_counter_id.update(|id| *id += 1);
-    };
-
-    let add_many_counters = move |_| {
-        let next_id = next_counter_id.get();
-        let new_counters = (next_id..next_id + MANY_COUNTERS).map(|id| {
-            let signal = create_signal(cx, 0);
-            (id, signal)
-        });
-
-        set_counters.update(move |counters| counters.extend(new_counters));
-        set_next_counter_id.update(|id| *id += MANY_COUNTERS);
-    };
-
-    let clear_counters = move |_| {
-        set_counters.update(|counters| counters.clear());
-    };
-
-    view! { cx,
-        <div>
-            <button on:click=add_counter>
-                "Add Counter"
-            </button>
-            <button on:click=add_many_counters>
-                {format!("Add {MANY_COUNTERS} Counters")}
-            </button>
-            <button on:click=clear_counters>
-                "Clear Counters"
-            </button>
-            <p>
-                "Total: "
-                <span>{move ||
-                    counters.get()
-                        .iter()
-                        .map(|(_, (count, _))| count.get())
-                        .sum::<i32>()
-                        .to_string()
-                }</span>
-                " from "
-                <span>{move || counters.with(|counters| counters.len()).to_string()}</span>
-                " counters."
-            </p>
-            <ul>
-                <For
-                    each={move || counters.get()}
-                    key={|counter| counter.0}
-                    view=move |cx, (id, (value, set_value))| {
-                        view! {
-                            cx,
-                            <Counter id value set_value/>
-                        }
-                    }
-                />
-            </ul>
-        </div>
-    }
-}
-
-#[component]
-fn Counter(
-    cx: Scope,
-    id: usize,
-    value: ReadSignal<i32>,
-    set_value: WriteSignal<i32>,
-) -> impl IntoView {
-    let CounterUpdater { set_counters } = use_context(cx).unwrap();
-
-    let input = move |ev| {
-        set_value
-            .set(event_target_value(&ev).parse::<i32>().unwrap_or_default())
-    };
-
-    view! { cx,
-        <li>
-            <button on:click=move |_| set_value.update(move |value| *value -= 1)>"-1"</button>
-            <input type="text"
-                prop:value={move || value.get().to_string()}
-                on:input=input
-            />
-            <span>{move || value.get().to_string()}</span>
-            <button on:click=move |_| set_value.update(move |value| *value += 1)>"+1"</button>
-            <button on:click=move |_| set_counters.update(move |counters| counters.retain(|(counter_id, _)| counter_id != &id))>"x"</button>
-        </li>
-    }
-}

examples/counters_stable/tests/web/add_1k_counters.rs

@@ -0,0 +1,17 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_increase_the_number_of_counters() {
+    // Given
+    ui::view_counters();
+
+    // When
+    ui::add_1k_counters();
+    ui::add_1k_counters();
+    ui::add_1k_counters();
+
+    // Then
+    assert_eq!(ui::counters(), 3000);
+}

examples/counters_stable/tests/web/add_counter.rs

@@ -0,0 +1,17 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_increase_the_number_of_counters() {
+    // Given
+    ui::view_counters();
+
+    // When
+    ui::add_counter();
+    ui::add_counter();
+    ui::add_counter();
+
+    // Then
+    assert_eq!(ui::counters(), 3);
+}

examples/counters_stable/tests/web/clear_counters.rs

@@ -0,0 +1,19 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_reset_the_counts() {
+    // Given
+    ui::view_counters();
+    ui::add_counter();
+    ui::add_counter();
+    ui::add_counter();
+
+    // When
+    ui::clear_counters();
+
+    // Then
+    assert_eq!(ui::total(), 0);
+    assert_eq!(ui::counters(), 0);
+}

examples/counters_stable/tests/web/decrement_counter.rs

@@ -0,0 +1,18 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_decrease_the_total_count() {
+    // Given
+    ui::view_counters();
+    ui::add_counter();
+
+    // When
+    ui::decrement_counter(1);
+    ui::decrement_counter(1);
+    ui::decrement_counter(1);
+
+    // Then
+    assert_eq!(ui::total(), -3);
+}

examples/counters_stable/tests/web/enter_count.rs

@@ -0,0 +1,34 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_increase_the_total_count() {
+    // Given
+    ui::view_counters();
+    ui::add_counter();
+
+    // When
+    ui::enter_count(1, 5);
+
+    // Then
+    assert_eq!(ui::total(), 5);
+}
+
+#[wasm_bindgen_test]
+fn should_decrease_the_total_count() {
+    // Given
+    ui::view_counters();
+    ui::add_counter();
+    ui::add_counter();
+    ui::add_counter();
+
+    // When
+    ui::enter_count(1, 100);
+    ui::enter_count(2, 100);
+    ui::enter_count(3, 100);
+    ui::enter_count(1, 50);
+
+    // Then
+    assert_eq!(ui::total(), 250);
+}

examples/counters_stable/tests/web/fixtures/counters_page.rs

@@ -0,0 +1,112 @@
+use counters_stable::Counters;
+use leptos::*;
+use wasm_bindgen::JsCast;
+use web_sys::{Element, Event, EventInit, HtmlElement, HtmlInputElement};
+
+// Actions
+
+pub fn add_1k_counters() {
+    find_by_text("Add 1000 Counters").click();
+}
+
+pub fn add_counter() {
+    find_by_text("Add Counter").click();
+}
+
+pub fn clear_counters() {
+    find_by_text("Clear Counters").click();
+}
+
+pub fn decrement_counter(index: u32) {
+    counter_html_element(index, "decrement_count").click();
+}
+
+pub fn enter_count(index: u32, count: i32) {
+    let input = counter_input_element(index, "counter_input");
+    input.set_value(count.to_string().as_str());
+    let mut event_init = EventInit::new();
+    event_init.bubbles(true);
+    let event = Event::new_with_event_init_dict("input", &event_init).unwrap();
+    input.dispatch_event(&event).unwrap();
+}
+
+pub fn increment_counter(index: u32) {
+    counter_html_element(index, "increment_count").click();
+}
+
+pub fn remove_counter(index: u32) {
+    counter_html_element(index, "remove_counter").click();
+}
+
+pub fn view_counters() {
+    remove_existing_counters();
+    mount_to_body(|cx| view! { cx,  <Counters/> });
+}
+
+// Results
+
+pub fn counters() -> i32 {
+    data_test_id("counters").parse::<i32>().unwrap()
+}
+
+pub fn title() -> String {
+    leptos::document().title()
+}
+
+pub fn total() -> i32 {
+    data_test_id("total").parse::<i32>().unwrap()
+}
+
+// Internal
+
+fn counter_element(index: u32, text: &str) -> Element {
+    let selector =
+        format!("li:nth-child({}) [data-testid=\"{}\"]", index, text);
+    leptos::document()
+        .query_selector(&selector)
+        .unwrap()
+        .unwrap()
+}
+
+fn counter_html_element(index: u32, text: &str) -> HtmlElement {
+    counter_element(index, text)
+        .dyn_into::<HtmlElement>()
+        .unwrap()
+}
+
+fn counter_input_element(index: u32, text: &str) -> HtmlInputElement {
+    counter_element(index, text)
+        .dyn_into::<HtmlInputElement>()
+        .unwrap()
+}
+
+fn data_test_id(id: &str) -> String {
+    let selector = format!("[data-testid=\"{}\"]", id);
+    leptos::document()
+        .query_selector(&selector)
+        .unwrap()
+        .expect("counters not found")
+        .text_content()
+        .unwrap()
+}
+
+fn find_by_text(text: &str) -> HtmlElement {
+    let xpath = format!("//*[text()='{}']", text);
+    let document = leptos::document();
+    document
+        .evaluate(&xpath, &document)
+        .unwrap()
+        .iterate_next()
+        .unwrap()
+        .unwrap()
+        .dyn_into::<HtmlElement>()
+        .unwrap()
+}
+
+fn remove_existing_counters() {
+    if let Some(counter) =
+        leptos::document().query_selector("body div").unwrap()
+    {
+        counter.remove();
+    }
+}

examples/counters_stable/tests/web/fixtures/mod.rs

@@ -0,0 +1 @@
+pub mod counters_page;

examples/counters_stable/tests/web/increment_counter.rs

@@ -0,0 +1,18 @@
+use super::*;
+use crate::counters_page as ui;
+use pretty_assertions::assert_eq;
+
+#[wasm_bindgen_test]
+fn should_increase_the_total_count() {
+    // Given
+    ui::view_counters();
+    ui::add_counter();
+
+    // When
+    ui::increment_counter(1);
+    ui::increment_counter(1);
+    ui::increment_counter(1);
+
+    // Then
+    assert_eq!(ui::total(), 3);
+}

examples/counters_stable/tests/web/main.rs

@@ -0,0 +1,16 @@
+use wasm_bindgen_test::*;
+
+// Test Suites
+pub mod add_1k_counters;
+pub mod add_counter;
+pub mod clear_counters;
+pub mod decrement_counter;
+pub mod enter_count;
+pub mod increment_counter;
+pub mod remove_counter;
+pub mod view_counters;
+
+pub mod fixtures;
+pub use fixtures::*;
+
+wasm_bindgen_test_configure!(run_in_browser);