Frontend Frameworks in Rust: Yew and Leptos

20 min read

If you have built UIs with React, Vue, or Svelte, you already know the two big ideas this page is about: a component model and a reactivity system. Rust has mature, WebAssembly-native frameworks built on both. Yew feels like React with a strict compiler; Leptos feels like Svelte/SolidJS with fine-grained reactivity. This page gives you a working mental model of each and a tiny, compile-verified example so you can decide which fits your project.

Quick Overview

So far in this section you have called individual Rust functions from JavaScript and poked at the DOM by hand. A frontend framework lets you instead write your entire UI in Rust: components, state, events, and rendering, all compiled to a single .wasm module. For a TypeScript developer the headline is that you keep the architectures you already know — declarative components and reactive state — but the compiler now enforces them, and there is no virtual-DOM library or framework runtime shipped as JavaScript.

The two leading choices in 2026 are Yew (a React/Elm-style component framework with a virtual DOM and hooks) and Leptos (a SolidJS-style framework built on fine-grained reactivity, with no virtual DOM). Both run client-side in the browser; Leptos additionally has first-class server-side rendering and “server functions,” which makes it closer to a Next.js-style full-stack framework.

TypeScript/JavaScript Example

Here is the canonical counter as a React function component in TypeScript — useState, an event handler, and JSX:

1
// Counter.tsx — React 19 + TypeScript
2
import { useState } from "react";
3

4
export function Counter() {
5
  const [count, setCount] = useState(0);
6

7
  // A new closure is created on every render; React diffs the virtual DOM
8
  // and patches only the <p> text node that actually changed.
9
  const increment = () => setCount((c) => c + 1);
10

11
  return (
12
    <div>
13
      <button onClick={increment}>Add task</button>
14
      <p>Tasks: {count}</p>
15
    </div>
16
  );
17
}

And the same idea in Svelte 5, which uses runes ($state) for fine-grained reactivity — no virtual DOM, the compiler wires the <p> directly to the count variable:

1
<!-- Counter.svelte — Svelte 5 -->
2
<script lang="ts">
3
  let count = $state(0);
4
</script>
5

6
<div>
7
  <button onclick={() => (count += 1)}>Add task</button>
8
  <p>Tasks: {count}</p>
9
</div>

These two snippets are not just two libraries — they are the two philosophies that Yew and Leptos map onto. Keep them in mind: Yew is the React column, Leptos is the Svelte/Solid column.

Rust Equivalent

Yew — the React/hooks model

Note: All Rust snippets on this page were compiled against Yew 0.23.0 and Leptos 0.8.19 on the current stable toolchain (Rust 1.96.0, 2024 edition) for the wasm32-unknown-unknown target. Add the dependency with cargo add yew --features csr (csr = client-side rendering).

1
// src/lib.rs  —  cargo add yew --features csr
2
use yew::prelude::*;
3

4
#[function_component]
5
fn App() -> Html {
6
    // use_state is Yew's useState. It returns a handle that derefs to the value.
7
    let count = use_state(|| 0_i32);
8

9
    let onclick = {
10
        // The handle is not Copy, so clone it for the closure to own.
11
        let count = count.clone();
12
        Callback::from(move |_| count.set(*count + 1))
13
    };
14

15
    html! {
16
        <div>
17
            <button {onclick}>{ "Add task" }</button>
18
            <p>{ format!("Tasks: {}", *count) }</p>
19
        </div>
20
    }
21
}
22

23
// In a real crate this is your wasm entry point; the bundler calls it.
24
pub fn run() {
25
    yew::Renderer::<App>::new().render();
26
}

Leptos — the SolidJS/signals model

1
// src/lib.rs  —  cargo add leptos --features csr
2
use leptos::prelude::*;
3

4
#[component]
5
fn Counter(#[prop(default = 0)] start: i32) -> impl IntoView {
6
    // signal() returns a (ReadSignal, WriteSignal) pair — like Solid's createSignal.
7
    let (count, set_count) = signal(start);
8

9
    view! {
10
        <div>
11
            <button on:click=move |_| set_count.update(|n| *n += 1)>"Add task"</button>
12
            <p>"Tasks: " {count}</p>
13
        </div>
14
    }
15
}
16

17
pub fn run() {
18
    // Mount the component tree into <body> for client-side rendering.
19
    leptos::mount::mount_to_body(|| view! { <Counter start=0 /> });
20
}

Both compile cleanly for wasm32-unknown-unknown. You build and serve them with a Wasm-aware bundler — most commonly Trunk (cargo install trunk, then trunk serve), which compiles the crate, runs wasm-bindgen, and serves an index.html with hot reload. Deployment is covered in deployment.md; the underlying wasm-bindgen machinery in wasm-bindgen.md.

Detailed Explanation

Reading the Yew version

use yew::prelude::*; pulls in function_component, use_state, Callback, html!, and Html in one line, the same convenience as a barrel import in TypeScript.
#[function_component] turns a plain fn App() -> Html into a component. This is the direct analogue of a React function component. There is no separate “props interface” here because App takes no props; a component with props takes &SomeProps as its single argument (shown in the Real-World Example).
use_state(|| 0_i32) is useState(0). The argument is a closure that produces the initial value, so the work only runs on first render — like React’s lazy useState(() => expensive()). It returns a UseStateHandle<i32>.
count.clone() before the closure is the line every React developer trips over. In JavaScript a closure captures count by reference and you never think about it. In Rust the closure must own what it captures (move), and UseStateHandle is a cheap reference-counted handle that is not Copy, so you clone it. Cloning is O(1) — it bumps a refcount, it does not copy your state. (See Section 05 — Move, Copy, Clone.)
Callback::from(move |_| ...) wraps the closure in Yew’s event-callback type. count.set(*count + 1) reads the current value via the Deref to i32 (*count) and schedules a re-render with the new value — exactly setCount(count + 1).
html! { ... } is a procedural macro that parses JSX-like syntax at compile time into virtual-DOM nodes. Note the differences from JSX: text and expressions are wrapped in braces ({ "Add task" }, { *count }), and the shorthand {onclick} is attribute punning (like <button onClick={onclick}> written <button {onclick}>).
yew::Renderer::<App>::new().render() mounts the app into <body>. This replaced the old yew::start_app API several versions ago; Renderer is the current entry point.

Reading the Leptos version

#[component] marks Counter as a component. Unlike Yew, props are ordinary function parameters — start: i32 is a prop, and #[prop(default = 0)] gives it a default value so <Counter /> is valid. This is far closer to how you think about props in TypeScript than Yew’s separate props struct.
signal(start) creates a reactive signal and returns a (ReadSignal<i32>, WriteSignal<i32>) tuple. (Older Leptos called this create_signal; that name is deprecated — use signal on 0.7+.) Read with count.get(), write with set_count.set(v) or set_count.update(|n| *n += 1).
{count} in the view binds the signal directly. This is the crux of fine-grained reactivity: Leptos does not re-run the whole component when count changes. It runs Counter exactly once to build the DOM, and the {count} expression creates a tiny reactive effect that updates only that one text node when the signal changes. There is no virtual DOM and no diffing. This is the Svelte/Solid model.
on:click=move |_| ... attaches a real DOM event listener. The move keyword is mandatory: the closure outlives Counter’s stack frame (it lives as long as the button does), so it must own its captures. Forget move and the compiler stops you — see Common Pitfalls.
mount_to_body is the client-side-rendering entry point, taking a closure that returns a view.

The one-render difference, made concrete

In React/Yew, the component function runs again on every state change, and the framework diffs the result. In Solid/Leptos, the component function runs once; only the reactive expressions re-run. This is why a React developer reaches for useMemo/useCallback to avoid re-creating things on every render, while a Leptos developer rarely needs to — there is no “every render.”

Key Differences

Concept	React/TypeScript	Yew (Rust)	Leptos (Rust)
Mental model	Component re-renders + virtual DOM	Component re-renders + virtual DOM	Fine-grained reactivity, no VDOM
Component runs…	on every state change	on every state change	once (effects re-run, not the fn)
Template syntax	JSX (`.tsx`)	`html! { }` macro, braces for exprs	`view! { }` macro, string literals for text
State	`useState(0)`	`use_state(\|\| 0)`	`signal(0)` → `(read, write)`
Read state	`count`	`*count` (Deref)	`count.get()` or bind `{count}`
Write state	`setCount(c => c+1)`	`count.set(...)`	`set_count.update(\|n\| *n += 1)`
Props	`interface Props {}`	`#[derive(Properties, PartialEq)] struct`	plain `fn` parameters + `#[prop(..)]`
Event handler	`onClick={fn}`	`onclick={Callback::from(..)}`	`on:click=move \|_\| ..`
Capture in closure	implicit by-ref	explicit `.clone()` + `move`	explicit `move`
SSR / full-stack	Next.js (separate)	community SSR	built-in SSR + server functions
Runtime shipped as JS	React (~40 KB+)	none (all in Wasm)	none (all in Wasm)

Two takeaways for a TypeScript developer:

Neither framework ships a JavaScript runtime to the browser. React itself is JavaScript you download; Yew and Leptos compile their machinery into your .wasm. That trades a JS download for a (often larger, but cacheable) Wasm download — the bundle-size tradeoffs are analyzed in performance.md.
Yew minimizes new concepts; Leptos minimizes runtime work. If your team thinks in React, Yew’s hooks and virtual DOM transfer almost one-to-one. If you want Svelte/Solid-style “set a variable, the DOM updates,” and possibly full-stack Rust, Leptos is the closer fit — at the cost of learning signals deeply (the ownership rules around move closures bite more often).

Tip: Both projects are production-used and actively maintained. Yew is the more conservative, “it works like React” choice; Leptos is the more ambitious, “one Rust codebase for client and server” choice. Picking is mostly about whether you want SSR/full-stack and which reactivity model your team prefers.

Common Pitfalls

Pitfall 1 (Yew): using a `use_state` handle after moving it into a closure

A React developer writes the handler inline and reuses count in the JSX, expecting it to “just work.” In Rust the closure moves the handle, so the later use in html! is a use-after-move.

1
// does not compile (error[E0382]: borrow of moved value: `count`)
2
use yew::prelude::*;
3

4
#[function_component]
5
fn App() -> Html {
6
    let count = use_state(|| 0_i32);
7
    let onclick = Callback::from(move |_| count.set(*count + 1)); // moves `count`
8
    html! {
9
        <div>
10
            <button {onclick}>{ "+1" }</button>
11
            <p>{ *count }</p>   // `count` was moved into the closure above
12
        </div>
13
    }
14
}
15

16
pub fn run() { yew::Renderer::<App>::new().render(); }

The real compiler error:

1
error[E0382]: borrow of moved value: `count`
2
   --> src/lib.rs:10:19
3
    |
4
  5 |     let count = use_state(|| 0_i32);
5
    |         ----- move occurs because `count` has type `UseStateHandle<i32>`, which does not implement the `Copy` trait
6
  6 |     let onclick = Callback::from(move |_| count.set(*count + 1));
7
    |                                  -------- ----- variable moved due to use in closure
8
    |                                  |
9
    |                                  value moved into closure here
10
...
11
 10 |             <p>{ *count }</p>
12
    |                   ^^^^^ value borrowed here after move

The fix is the clone()-into-a-block pattern from the Rust Equivalent: clone the handle just for the closure, leaving the original free to use in the view.

Pitfall 2 (Yew): a `Properties` struct without `PartialEq`

Props in Yew must derive both Properties and PartialEq — Yew uses PartialEq to decide whether a child needs re-rendering (its memoization). Forgetting PartialEq produces a confusing “can’t compare” error:

1
// does not compile (error[E0277]: can't compare `CardProps` with `CardProps`)
2
use yew::prelude::*;
3

4
#[derive(Properties)]      // missing PartialEq
5
struct CardProps { title: String }
6

7
#[function_component]
8
fn Card(props: &CardProps) -> Html {
9
    html! { <h2>{ &props.title }</h2> }
10
}

1
error[E0277]: can't compare `CardProps` with `CardProps`
2
 --> src/lib.rs:3:10
3
  |
4
3 | #[derive(Properties)]
5
  |          ^^^^^^^^^^ no implementation for `CardProps == CardProps`
6
  |
7
  = help: the trait `PartialEq` is not implemented for `CardProps`

Fix: #[derive(Properties, PartialEq)].

Pitfall 3 (Leptos): forgetting `move` on an event closure

Leptos event handlers must be 'static because they outlive the component’s function call. A non-move closure borrows the signal, which cannot outlive the stack frame:

1
// does not compile (error[E0373]: closure may outlive the current function)
2
use leptos::prelude::*;
3

4
#[component]
5
fn Counter() -> impl IntoView {
6
    let (count, set_count) = signal(0);
7
    view! {
8
        <button on:click=|_| set_count.update(|n| *n += 1)>"+1"</button> // missing `move`
9
        <p>{count}</p>
10
    }
11
}

1
error[E0373]: closure may outlive the current function, but it borrows `set_count`, which is owned by the current function
2
 --> src/lib.rs:7:26
3
  |
4
7 |         <button on:click=|_| set_count.update(|n| *n += 1)>"+1"</button>
5
  |                          ^^^ --------- `set_count` is borrowed here
6
  |                          |
7
  |                          may outlive borrowed value `set_count`
8
  |
9
note: function requires argument type to outlive `'static`

Fix: add move — on:click=move |_| set_count.update(|n| *n += 1). Because Leptos signals are Copy (they are arena handles, not the data), move closures can capture the same signal in several handlers without any cloning — a nice ergonomic win over Yew’s use_state handles.

Pitfall 4 (Leptos): reading a signal eagerly instead of reactively

A subtle conceptual trap, not a compiler error. Writing {count.get()} in a view! reads the value once at build time and never updates. To stay reactive you bind the signal itself ({count}) or wrap the expression in a closure ({move || count.get() * 2}) so Leptos can re-run it when the signal changes.

1
// Both compile, but only one stays reactive:
2
// <p>{count.get()}</p>          // read once, never updates  — usually a bug
3
// <p>{count}</p>                // reactive: updates on every change
4
// <p>{move || count.get() * 2}</p> // reactive derived value

This is the inverse of a React habit: in React you always read the current value (count) and the re-render handles updates; in Leptos you must hand the framework something it can re-run.

Best Practices

Pick the model your team already thinks in. React shop with no SSR need → Yew. Want Svelte/Solid reactivity or full-stack Rust with SSR → Leptos. Do not fight a framework’s philosophy.
Use Trunk for client-side apps. cargo install trunk && trunk serve gives you compile + wasm-bindgen + dev server + hot reload from one tool. It is the de-facto standard for Yew/Leptos CSR; bundler integration is covered in deployment.md.
Yew: always derive Properties, PartialEq together on props structs, and keep props cheap to compare (Yew compares them to decide whether to re-render).
Leptos: prefer .update() over .set() when the new value depends on the old, and remember that signal() returns two handles — keep the read handle for reading/binding and the write handle for mutation.
Keep components small and pass data down as props. The component boundary is also your re-render boundary in Yew and your reactivity boundary in Leptos.
Do not reach for a framework for a single widget. If you are adding one fast function to an existing JS/TS app, plain wasm-bindgen (first-wasm.md) is lighter than pulling in a whole UI framework. Frameworks pay off when the UI itself is Rust.
Test logic in plain Rust. Extract pure logic (reducers, validation, formatting) into ordinary functions you can unit-test with cargo test on the host, and keep components thin. (See Section 13 — Testing.)

Real-World Example

A small but realistic todo app — text input, add button, click-to-toggle-done, and a live count — written once in each framework. Both compile cleanly for wasm32-unknown-unknown.

Yew

The input handler reaches into web_sys to read the DOM element’s value, so add the feature: cargo add web-sys --features HtmlInputElement (web-sys and feature flags are covered in web-apis.md).

1
// cargo add yew --features csr
2
// cargo add web-sys --features HtmlInputElement
3
use web_sys::HtmlInputElement;
4
use yew::prelude::*;
5

6
#[derive(Clone, PartialEq)]
7
struct Todo {
8
    text: String,
9
    done: bool,
10
}
11

12
#[function_component]
13
fn App() -> Html {
14
    let todos = use_state(Vec::<Todo>::new);
15
    let draft = use_state(String::new);
16

17
    // Two-way bind the input field to `draft`.
18
    let on_input = {
19
        let draft = draft.clone();
20
        Callback::from(move |e: InputEvent| {
21
            let input: HtmlInputElement = e.target_unchecked_into();
22
            draft.set(input.value());
23
        })
24
    };
25

26
    let on_add = {
27
        let todos = todos.clone();
28
        let draft = draft.clone();
29
        Callback::from(move |_| {
30
            if draft.is_empty() {
31
                return;
32
            }
33
            let mut next = (*todos).clone();
34
            next.push(Todo { text: (*draft).clone(), done: false });
35
            todos.set(next);
36
            draft.set(String::new());
37
        })
38
    };
39

40
    // A helper that builds a per-item toggle callback.
41
    let toggle = |idx: usize, todos: UseStateHandle<Vec<Todo>>| {
42
        Callback::from(move |_| {
43
            let mut next = (*todos).clone();
44
            next[idx].done = !next[idx].done;
45
            todos.set(next);
46
        })
47
    };
48

49
    html! {
50
        <section>
51
            <h1>{ "Todos" }</h1>
52
            <input value={(*draft).clone()} oninput={on_input} placeholder="What needs doing?" />
53
            <button onclick={on_add}>{ "Add" }</button>
54
            <ul>
55
                { for todos.iter().enumerate().map(|(idx, todo)| {
56
                    let style = if todo.done { "text-decoration: line-through" } else { "" };
57
                    html! {
58
                        <li {style} onclick={toggle(idx, todos.clone())}>
59
                            { &todo.text }
60
                        </li>
61
                    }
62
                }) }
63
            </ul>
64
            <p>{ format!("{} item(s)", todos.len()) }</p>
65
        </section>
66
    }
67
}
68

69
pub fn run() {
70
    yew::Renderer::<App>::new().render();
71
}

Notice the Yew idiom: state is one big Vec, and every mutation clones it, edits the clone, and calls .set() — the same immutable-update pattern you use with React’s useState and a setter. The whole App re-renders and the virtual DOM diffs the result.

Leptos

1
// cargo add leptos --features csr
2
use leptos::prelude::*;
3

4
#[derive(Clone)]
5
struct Todo {
6
    id: usize,
7
    text: String,
8
    done: RwSignal<bool>, // each todo owns its own fine-grained signal
9
}
10

11
#[component]
12
fn App() -> impl IntoView {
13
    let (todos, set_todos) = signal(Vec::<Todo>::new());
14
    let (draft, set_draft) = signal(String::new());
15
    let next_id = RwSignal::new(0usize);
16

17
    let add = move |_| {
18
        let text = draft.get();
19
        if text.is_empty() {
20
            return;
21
        }
22
        let id = next_id.get();
23
        next_id.set(id + 1);
24
        set_todos.update(|list| {
25
            list.push(Todo { id, text, done: RwSignal::new(false) });
26
        });
27
        set_draft.set(String::new());
28
    };
29

30
    // Derived value: recomputed only when its dependencies change.
31
    let remaining = move || todos.get().iter().filter(|t| !t.done.get()).count();
32

33
    view! {
34
        <section>
35
            <h1>"Todos"</h1>
36
            <input
37
                prop:value=draft
38
                on:input=move |e| set_draft.set(event_target_value(&e))
39
                placeholder="What needs doing?"
40
            />
41
            <button on:click=add>"Add"</button>
42
            <ul>
43
                <For
44
                    each=move || todos.get()
45
                    key=|todo| todo.id
46
                    children=move |todo| {
47
                        let done = todo.done;
48
                        view! {
49
                            <li
50
                                style=move || if done.get() { "text-decoration: line-through" } else { "" }
51
                                on:click=move |_| done.update(|d| *d = !*d)
52
                            >
53
                                {todo.text.clone()}
54
                            </li>
55
                        }
56
                    }
57
                />
58
            </ul>
59
            <p>{remaining} " remaining"</p>
60
        </section>
61
    }
62
}
63

64
pub fn run() {
65
    leptos::mount::mount_to_body(App);
66
}

The Leptos version shows the fine-grained model paying off. Toggling a single todo flips that todo’s own RwSignal<bool>; only that one <li>’s style effect re-runs. The list is rendered with <For>, which keys items by id and adds/removes only the DOM nodes that actually changed — no full re-render, no virtual-DOM diff. event_target_value(&e) is Leptos’s helper for reading an input’s value, sparing you the manual web_sys cast the Yew version needed.

Exercises

Exercise 1: A bounded counter in Yew

Difficulty: Easy

Objective: Practice the use_state + cloned-handle pattern with multiple event handlers.

Instructions: Build a Yew component with three buttons — -1, +1, and reset — and a <span> showing the count. The count is a u32 and must never go below zero. (Hint: u32 has a saturating_sub method, and UseStateHandle<u32> derefs to u32.)

1
use yew::prelude::*;
2

3
#[function_component]
4
fn Counter() -> Html {
5
    let count = use_state(|| 0_u32);
6
    // TODO: build inc, dec (saturating), and reset callbacks
7
    html! {
8
        <div>
9
            /* TODO: three buttons + a <span> showing the count */
10
        </div>
11
    }
12
}
13

14
pub fn run() { yew::Renderer::<Counter>::new().render(); }

Solution

1
use yew::prelude::*;
2

3
#[function_component]
4
fn Counter() -> Html {
5
    let count = use_state(|| 0_u32);
6

7
    let inc = {
8
        let count = count.clone();
9
        Callback::from(move |_| count.set(*count + 1))
10
    };
11
    let dec = {
12
        let count = count.clone();
13
        Callback::from(move |_| count.set(count.saturating_sub(1)))
14
    };
15
    let reset = {
16
        let count = count.clone();
17
        Callback::from(move |_| count.set(0))
18
    };
19

20
    html! {
21
        <div>
22
            <button onclick={dec}>{ "-1" }</button>
23
            <span>{ *count }</span>
24
            <button onclick={inc}>{ "+1" }</button>
25
            <button onclick={reset}>{ "reset" }</button>
26
        </div>
27
    }
28
}
29

30
pub fn run() {
31
    yew::Renderer::<Counter>::new().render();
32
}

This compiles cleanly for wasm32-unknown-unknown. Each handler clones the handle in its own block so all three can capture it. count.saturating_sub(1) calls u32::saturating_sub through the handle’s Deref, returning 0 instead of panicking when the count is already zero.

Exercise 2: A reactive temperature converter in Leptos

Difficulty: Medium

Objective: Use a signal plus a derived value so the output updates automatically.

Instructions: Build a Leptos component with a numeric input for Celsius and a paragraph showing the equivalent Fahrenheit, formatted to one decimal place. The Fahrenheit value must be a derived value (a move || closure), not a second signal you keep in sync by hand. Use event_target_value(&e) to read the input and .parse().unwrap_or(0.0) to tolerate empty/invalid input.

1
use leptos::prelude::*;
2

3
#[component]
4
fn TempConverter() -> impl IntoView {
5
    let (celsius, set_celsius) = signal(0.0_f64);
6
    // TODO: a derived `fahrenheit` value
7
    view! {
8
        <div>
9
            /* TODO: a number input bound to celsius, and a <p> showing fahrenheit */
10
        </div>
11
    }
12
}
13

14
pub fn run() { leptos::mount::mount_to_body(TempConverter); }

Solution

1
use leptos::prelude::*;
2

3
#[component]
4
fn TempConverter() -> impl IntoView {
5
    let (celsius, set_celsius) = signal(0.0_f64);
6

7
    // Derived signal: recomputed automatically whenever `celsius` changes.
8
    let fahrenheit = move || celsius.get() * 9.0 / 5.0 + 32.0;
9

10
    view! {
11
        <div>
12
            <label>
13
                "Celsius: "
14
                <input
15
                    type="number"
16
                    prop:value=celsius
17
                    on:input=move |e| {
18
                        let v = event_target_value(&e).parse().unwrap_or(0.0);
19
                        set_celsius.set(v);
20
                    }
21
                />
22
            </label>
23
            <p>{move || format!("{:.1}", fahrenheit())} " F"</p>
24
        </div>
25
    }
26
}
27

28
pub fn run() {
29
    leptos::mount::mount_to_body(TempConverter);
30
}

This compiles cleanly for wasm32-unknown-unknown. fahrenheit is a plain closure — Leptos re-runs it inside the <p> whenever celsius changes, so there is no second piece of state to keep in sync. Wrapping the format! in move || keeps the text node reactive (Pitfall 4).

Exercise 3: A child component with props (Yew)

Difficulty: Hard

Objective: Split a UI into a parent and a reusable child component that takes props and a callback, the way you would lift state up in React.

Instructions: Write a TaskItem child component that takes a label: String, a done: bool, and an on_toggle: Callback<()> prop, rendering an <li> (struck through when done) that emits on_toggle when clicked. Then write a parent App holding a Vec<(String, bool)> in use_state that renders one TaskItem per task and toggles the matching entry when a child fires its callback. Remember props need #[derive(Properties, PartialEq)].

Solution

1
use yew::prelude::*;
2

3
#[derive(Properties, PartialEq)]
4
struct TaskItemProps {
5
    label: String,
6
    done: bool,
7
    on_toggle: Callback<()>,
8
}
9

10
#[function_component]
11
fn TaskItem(props: &TaskItemProps) -> Html {
12
    let style = if props.done { "text-decoration: line-through" } else { "" };
13
    let on_toggle = props.on_toggle.clone();
14
    let onclick = Callback::from(move |_| on_toggle.emit(()));
15
    html! {
16
        <li {style} {onclick}>{ &props.label }</li>
17
    }
18
}
19

20
#[function_component]
21
fn App() -> Html {
22
    let tasks = use_state(|| vec![
23
        ("Write Rust".to_string(), true),
24
        ("Compile to Wasm".to_string(), false),
25
    ]);
26

27
    html! {
28
        <ul>
29
            { for tasks.iter().enumerate().map(|(idx, (label, done))| {
30
                let on_toggle = {
31
                    let tasks = tasks.clone();
32
                    Callback::from(move |_| {
33
                        let mut next = (*tasks).clone();
34
                        next[idx].1 = !next[idx].1;
35
                        tasks.set(next);
36
                    })
37
                };
38
                html! {
39
                    <TaskItem label={label.clone()} done={*done} {on_toggle} />
40
                }
41
            }) }
42
        </ul>
43
    }
44
}
45

46
pub fn run() {
47
    yew::Renderer::<App>::new().render();
48
}

This compiles cleanly for wasm32-unknown-unknown. The pattern mirrors React precisely: state lives in the parent, the child receives data plus an on_toggle: Callback<()> (React’s onToggle: () => void), and clicking the child calls on_toggle.emit(()). Each row builds its own callback in a block that clones the tasks handle, captures the row index, and performs the immutable update — the Yew equivalent of an inline () => setTasks(...) arrow in JSX.

Frontend Frameworks in Rust: Yew and Leptos

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Yew — the React/hooks model

Leptos — the SolidJS/signals model

Detailed Explanation

Reading the Yew version

Reading the Leptos version

The one-render difference, made concrete

Key Differences

Common Pitfalls

Pitfall 1 (Yew): using a use_state handle after moving it into a closure

Pitfall 2 (Yew): a Properties struct without PartialEq

Pitfall 3 (Leptos): forgetting move on an event closure

Pitfall 4 (Leptos): reading a signal eagerly instead of reactively

Best Practices

Real-World Example

Yew

Leptos

Further Reading

Exercises

Exercise 1: A bounded counter in Yew

Exercise 2: A reactive temperature converter in Leptos

Exercise 3: A child component with props (Yew)

Pitfall 1 (Yew): using a `use_state` handle after moving it into a closure

Pitfall 2 (Yew): a `Properties` struct without `PartialEq`

Pitfall 3 (Leptos): forgetting `move` on an event closure