Leptos

The any_spawner crate provides a utility to spawn tasks across different executors without coupling your code to a specific runtime. This allows you to write asynchronous logic that can be used in various environments (e.g., different async runtimes) by setting the executor at runtime.

Key Constraints

• Single Executor: You can only set one global executor per program.
• One-time Initialization: The executor must be initialized once at runtime.
• No Join Handles: The spawn methods do not return a handle or result to track the task.
• Return Type: The Future being spawned must output ().

use any_spawner::Executor;

// Initialize the global executor (e.g., using futures_executor)
Executor::init_futures_executor()
    .expect("executor should only be initialized once");

// Spawn a thread-safe Future
Executor::spawn(async { /* ... */ });

// Spawn a Future that is !Send (local to the current thread)
Executor::spawn_local(async { /* ... */ });

The projects directory contains medium-to-large-scale examples demonstrating various use cases and integrations between Leptos and other libraries. Unlike the core examples directory, these projects are built against specific versions and may not be regularly linted or updated, allowing for a wider variety of community-driven implementations.

Available project examples include:

• meilisearch-searchbar: Integrating the Meilisearch Rust-based search engine with a Leptos server to provide an autocomplete search bar.
• nginx-mpmc: Using Nginx as a load balancer/proxy to provide different clients to users while running multiple Leptos servers that provide server functions.
• ory-kratos: Running Ory Kratos (Identification service) alongside a Leptos server and utilizing their UI Node data types within Leptos.
• tauri-from-scratch: A detailed guide on using Tauri to render Leptos apps on non-web targets via WebView, supporting SSR and communication with a Leptos server.
• counter_dwarf_debug: Demonstrating how to set up breakpoints in the browser or Visual Studio Code for debugging Leptos applications.
• bevy3d_ui: Using the Bevy 3D game engine alongside Leptos within a WebAssembly (WASM) environment.

The reactive_graph crate implements a fine-grained reactive system using three core primitives. This approach models data flow by composing these units, ensuring that updates to a signal only trigger the specific computations or effects that depend on it, avoiding unnecessary diffing.

Core Primitives

1. Signals: Atomic units of state that can be directly mutated (e.g., ArcRwSignal). They act as "source" nodes.
2. Computations: Derived values that cannot be mutated directly but update automatically when their dependencies change (e.g., ArcMemo). They act as both "source" nodes (for others to subscribe to) and "subscriber" nodes.
3. Effects: Side effects used to synchronize the reactive system with the outside world (e.g., Effect). They act as "subscriber" nodes.

Key Characteristics

• Dynamic Dependency Tracking: Dependencies are tracked at runtime rather than being declared statically. If a computation contains conditional logic, it will only subscribe to the dependencies used in the currently active branch. Subscribers automatically unsubscribe from unused dependencies between runs.
• Asynchronous Effect Scheduling: While updating a signal changes its value immediately, dependent Effects are scheduled as asynchronous tasks. They run during the next "tick" of the async runtime. This makes the library async runtime agnostic (compatible with tokio, wasm-bindgen-futures, glib, etc.).
• Efficiency Focus: The system is optimized to minimize the execution of effects (which are assumed to be expensive) at the cost of a small amount of raw update speed for signal propagation.

use reactive_graph::{
    computed::ArcMemo,
    effect::Effect,
    prelude::{Read, Set},
    signal::ArcRwSignal,
};

let count = ArcRwSignal::new(1);
let double_count = ArcMemo::new({
    let count = count.clone();
    move |_| *count.read() * 2
});

// the effect will run once initially
Effect::new(move |_| {
    println!("double_count = {}", *double_count.read());
});

// updating `count` will propagate changes to the dependencies,
// causing the effect to run again
count.set(2);

The reactive system (leptos_reactive) is the foundation of Leptos. It manages dynamic values (signals), their relationships (derived signals and memos), and side effects (effects).

Key Concepts

• Signals: Dynamic values that you give ownership of to the reactive system. When you create a signal, you receive a Copy + 'static identifier (an index into a slotmap arena) used to access the value.
• Derived Signals & Memos: Values that depend on other signals.
• Effects: Side effects that run in response to reactive changes.
• Reactive Scopes: Data ownership is tied to the lifetime of the reactive scope (e.g., a component). When a scope is dropped, the items owned by the reactive system within that scope are also dropped. This acts as a form of 'garbage collection' tied to the UI lifecycle rather than Rust's lexical scopes.

Design Philosophy

To minimize expensive side effects (like DOM updates or network requests), the system assumes that data is relatively cheap to compute but side effects are expensive to execute.