DEV Community: tengxgfyrz67s

构建组件

tengxgfyrz67s — Fri, 19 Jun 2026 09:53:06 +0000

组件简介

组件是任何 euv 应用的构建块。它们让你将 UI 拆分为独立的、可复用的片段，每个片段都有自己的逻辑和展示。在 euv 中，组件是接受一个 VirtualNode（携带 props 和子节点）并返回一个 VirtualNode（描述渲染输出）的函数。

定义组件

要在 euv 中定义组件，你需要两个东西：

一个 Props 结构体，定义组件接受的数据
一个用 #[component] 属性装饰的组件函数

Props 结构体

Props 结构体定义了组件接收的数据的形状。它必须派生 Clone 和 Default：

#[derive(Clone, Default)]
struct MyCardProps {
    title: &'static str,
}

Props 可以是各种类型，包括：

&'static str — 静态字符串切片，适合固定文本
String — 拥有的字符串，适合动态文本
bool — 布尔值，用于标志位
Signal<bool> — 响应式布尔信号
i32、f64 — 数值类型
Option<Rc<dyn Fn(Event)>> — 可选的回调函数
Signal<T> — 任意类型的响应式信号
VirtualNode — 子虚拟节点
Css — CSS 样式值

组件函数

组件函数接受一个 VirtualNode<YourProps> 并返回一个 VirtualNode：

#[component]
pub fn my_card(node: VirtualNode<MyCardProps>) -> VirtualNode {
    let MyCardProps { title, .. } = node.try_get_props().unwrap_or_default();
    let children: VirtualNode = node.try_get_child_node();
    html! {
        div {
            h3 { title }
            children
        }
    }
}

让我们逐步分析：

#[component] — 这个属性将函数标记为组件，使其能够通过 VirtualNode 包装器接收 props 和子节点。
node: VirtualNode<MyCardProps> — 函数接收一个用 props 类型参数化的 VirtualNode。这个节点携带 props 和任何子节点。
node.try_get_props() — 该方法尝试从虚拟节点中提取类型化的 props。unwrap_or_default() 调用在提取失败时提供默认值（例如，当组件在没有 props 的情况下使用时）。
node.try_get_child_node() — 该方法提取传递给组件的子节点。这些可以在组件的模板内部渲染。
html! { ... } — 组件返回一棵描述要渲染内容的 VirtualNode 树。

使用组件

定义完成后，可以在 html! 宏中通过引用函数名来使用组件：

fn app() -> VirtualNode {
    html! {
        div {
            MyCard {
                title: "Welcome to euv"
                p { "This content is passed as children." }
            }
        }
    }
}

Props 被指定为命名属性（title: "Welcome to euv"），子节点嵌套在组件的花括号内。

组件嵌套

组件可以嵌套在其他组件内部，以构建复杂的 UI：

#[derive(Clone, Default)]
struct AlertProps {
    message: &'static str,
}

#[component]
pub fn alert(node: VirtualNode<AlertProps>) -> VirtualNode {
    let AlertProps { message, .. } = node.try_get_props().unwrap_or_default();
    html! {
        div {
            p { message }
        }
    }
}

#[derive(Clone, Default)]
struct DashboardProps {
    username: &'static str,
}

#[component]
pub fn dashboard(node: VirtualNode<DashboardProps>) -> VirtualNode {
    let DashboardProps { username, .. } = node.try_get_props().unwrap_or_default();
    html! {
        div {
            h1 { username }
            Alert {
                message: "Welcome to your dashboard!"
            }
        }
    }
}

在这个示例中，dashboard 组件在其模板内部嵌套了 alert 组件。这种组合能力是组件系统的关键优势之一。

向组件传递子节点

子节点是一种创建包装器组件的强大模式。父组件传递内容，子组件决定在哪里渲染它：

#[derive(Clone, Default)]
struct CardProps {
    title: &'static str,
}

#[component]
pub fn card(node: VirtualNode<CardProps>) -> VirtualNode {
    let CardProps { title, .. } = node.try_get_props().unwrap_or_default();
    let children: VirtualNode = node.try_get_child_node();
    html! {
        div {
            h3 { title }
            div {
                children
            }
        }
    }
}

fn app() -> VirtualNode {
    html! {
        Card {
            title: "My Card"
            p { "This is the card body." }
            button { onclick: move |event: Event| { /* handler */ } "Action" }
        }
    }
}

card 组件接收 title prop 和子节点（p 和 button），然后在自己的布局中渲染它们。

Props Down / Callback Up

euv 遵循 "Props Down, Callback Up" 模式：

Props Down：父组件通过 props 向子组件传递数据
Callback Up：子组件通过回调函数向父组件传递信息

#[derive(Clone, Default)]
struct ChildProps {
    on_click: Option<Rc<dyn Fn(Event)>>,
}

#[component]
pub fn child(node: VirtualNode<ChildProps>) -> VirtualNode {
    let ChildProps { on_click, .. } = node.try_get_props().unwrap_or_default();
    html! {
        button {
            onclick: on_click
            "Click me"
        }
    }
}

fn app() -> VirtualNode {
    let count: Signal<i32> = use_signal(|| 0);

    html! {
        div {
            Child {
                on_click: Some(Rc::new(move |event: Event| {
                    count.set(count.get() + 1);
                }))
            }
        }
    }
}

共享信号实现双向绑定

要在父组件和子组件之间实现真正的双向绑定，可以直接共享一个 Signal：

#[derive(Clone, Default)]
struct InputProps {
    value: Signal<String>,
}

#[component]
pub fn text_input(node: VirtualNode<InputProps>) -> VirtualNode {
    let InputProps { value, .. } = node.try_get_props().unwrap_or_default();
    html! {
        input {
            oninput: on_input_value(value)
        }
    }
}

fn app() -> VirtualNode {
    let name: Signal<String> = use_signal(|| "".to_string());

    html! {
        div {
            TextInput {
                value: name
            }
            p { "You typed:" }
        }
    }
}

通过共享 name 信号，父组件和子组件都可以读取和写入同一个状态，实现双向绑定。

使用 watch! 实现跨组件响应式绑定

watch! 宏通过监控信号并在信号变化时运行回调来实现跨组件响应式绑定：

fn app() -> VirtualNode {
    let celsius: Signal<f64> = use_signal(|| 0.0);
    let fahrenheit: Signal<f64> = use_signal(|| 32.0);

    watch!(celsius, |celsius_value: f64| {
        fahrenheit.set(celsius_value * 9.0 / 5.0 + 32.0);
    });

    html! {
        div {
            input {
                oninput: on_input_value(celsius)
            }
            p { "Fahrenheit" }
        }
    }
}

在这里，watch! 监控 celsius 信号，并在 celsius 变化时自动更新 fahrenheit。这个模式在保持多个状态片段同步时很有用。

Keep-Alive 模式

有时你想隐藏组件而不卸载它（保留其状态）。euv 通过 CSS display: none/block 的 Keep-Alive 模式来支持这一点：

fn app() -> VirtualNode {
    let show: Signal<bool> = use_signal(|| true);

    html! {
        div {
            if { show.get() } {
                div { class: euv-fade-in "Content visible" }
            } else {
                div { style: "display: none" "Content hidden but alive" }
            }
            button {
                onclick: use_toggle(show)
                "Toggle"
            }
        }
    }
}

与其使用条件渲染（会卸载并丢失状态），不如使用 CSS 来切换可见性，同时保持组件存活。

总结

组件是 euv 应用架构的基础：

Props 结构体：使用 #[derive(Clone, Default)] 和类型化字段定义
组件函数：用 #[component] 装饰，接受 VirtualNode<Props>，返回 VirtualNode
提取 props：使用 node.try_get_props().unwrap_or_default()
提取子节点：使用 node.try_get_child_node()
组件嵌套：在 html! 宏中使用组件，传入命名 props 和嵌套子节点
Props Down / Callback Up：通过 props 向下传递数据，通过回调向上通信
共享信号：共享 Signal 实现双向绑定
watch!：使用 watch! 实现跨组件响应式绑定
Keep-Alive：使用 CSS display: none/block 隐藏而不卸载

使用这些模式，你可以在 euv 中构建复杂、可维护且可复用的 UI 应用。

HTTP Compression and Optimization

tengxgfyrz67s — Fri, 19 Jun 2026 09:30:39 +0000

HTTP compression is one of the most effective techniques for reducing bandwidth usage and improving response times. When building high-performance web servers with Hyperlane, understanding how to leverage compression and other optimization strategies can dramatically improve your application's throughput and user experience.

Why Compression Matters

Modern web applications often exchange large volumes of data — JSON responses, HTML pages, API payloads, and static assets. Without compression, this data travels across the network in its raw form, consuming significant bandwidth and increasing latency. HTTP compression addresses this by encoding response bodies using algorithms like gzip, deflate, or brotli before transmission, reducing payload sizes by 60–90% in many cases.

For a framework like Hyperlane, which already delivers impressive performance benchmarks — 316,211 QPS in ab tests with 1 million requests, 334,888 QPS with Keep-Alive enabled — adding compression can further reduce the effective data transfer, making your server even more efficient.

Understanding Compression Algorithms

gzip

gzip is the most widely supported compression algorithm on the web. It uses the DEFLATE algorithm, which combines LZ77 lossless data compression with Huffman coding. gzip offers a good balance between compression ratio and CPU overhead, making it the default choice for most web applications.

deflate

deflate is the underlying compression algorithm used by gzip. It produces slightly smaller output than gzip because it omits the gzip header and checksum. However, browser support for raw deflate is inconsistent, so gzip is generally preferred.

brotli

brotli is a newer compression algorithm developed by Google. It typically achieves 20–26% better compression ratios than gzip, especially for text-based content like HTML, CSS, and JSON. brotli is supported by all modern browsers and is increasingly popular for API responses.

Integrating Compression with Hyperlane

While Hyperlane itself focuses on the HTTP server layer, compression is typically handled at the middleware or reverse proxy level. Here's how you can integrate compression into your Hyperlane application.

Using Middleware for Response Compression

Hyperlane's middleware system allows you to intercept responses before they are sent to clients. You can use this to compress response bodies:

use hyperlane::*;

#[response_middleware]
async fn compression_middleware(ctx: &mut Context) -> MiddlewareResult {
    let response = ctx.get_mut_response();
    let body = response.get_body();

    // Check if the response body is compressible
    if should_compress(&body) {
        let compressed = compress_body(&body);
        response.set_body(compressed);
        response.add_header("Content-Encoding", "gzip");
    }

    ctx.next().await
}

fn should_compress(body: &[u8]) -> bool {
    body.len() > 1024 // Only compress responses larger than 1KB
}

fn compress_body(body: &[u8]) -> Vec<u8> {
    // Use flate2 or another compression library
    // This is a simplified example
    body.to_vec()
}

Configuring Compression Based on Content Type

Not all content types benefit from compression. Binary images (JPEG, PNG) are already compressed, and compressing them again wastes CPU cycles. You should compress text-based content types:

const COMPRESSIBLE_TYPES: &[&str] = &[
    "text/html",
    "text/plain",
    "text/css",
    "application/json",
    "application/javascript",
    "application/xml",
    "application/rss+xml",
];

Performance Optimization Strategies

1. Enable Keep-Alive Connections

Hyperlane's performance data shows the dramatic impact of Keep-Alive connections:

Keep-Alive disabled: 51,031 QPS
Keep-Alive enabled: 334,888 QPS

That's a 6.5x improvement simply by reusing connections. Keep-Alive reduces the overhead of TCP handshakes and TLS negotiations for subsequent requests on the same connection.

use hyperlane::*;

#[tokio::main]
async fn main() {
    let server = Server::default();
    // Keep-Alive is managed at the connection level
    // Hyperlane handles this automatically
    server.run().await;
}

2. Optimize Linux Kernel Parameters

For production deployments on Linux, kernel-level tuning can significantly improve throughput:

# Increase the maximum number of TIME_WAIT sockets
net.ipv4.tcp_max_tw_buckets = 20000

# Increase the maximum backlog of pending connections
net.core.somaxconn = 65535

# Increase the maximum number of pending SYN packets
net.ipv4.tcp_max_syn_backlog = 262144

# Increase the file descriptor limit
ulimit -n 1024000

These settings allow Hyperlane to handle more concurrent connections and reduce connection drops under heavy load.

3. Use Native CPU Optimization

When building Hyperlane for production, compile with native CPU targeting:

RUSTFLAGS="-C target-cpu=native -C link-arg=-fuse-ld=lld" cargo run --release

The -C target-cpu=native flag enables CPU-specific instruction sets (like AVX2, SSE4.2) that can accelerate compression, encryption, and other operations. The -C link-arg=-fuse-ld=lld flag uses the faster LLD linker to reduce build times.

4. Configure Server Parameters

Hyperlane provides ServerConfig for fine-tuning server behavior:

use hyperlane::*;

let config = ServerConfig::new()
    .set_address("0.0.0.0:8080")
    .set_nodelay(true)  // Disable Nagle's algorithm for lower latency
    .set_ttl(60);       // Set IP TTL

let server = Server::from(config);
server.run().await;

Setting nodelay to true disables Nagle's algorithm, which buffers small TCP packets to reduce network overhead. For HTTP servers handling many small API responses, disabling Nagle's algorithm can reduce latency.

5. Optimize Request Parsing

Hyperlane's RequestConfig allows you to control resource limits for request parsing:

use hyperlane::*;

let request_config = RequestConfig::new()
    .buffer_size(8192)
    .max_path_size(2048)
    .max_header_count(100)
    .max_body_size(10 * 1024 * 1024) // 10MB
    .read_timeout_ms(30000);

let server = Server::from(request_config);
server.run().await;

Properly configuring these limits prevents resource exhaustion attacks while allowing legitimate requests to be processed efficiently.

Compression at the Reverse Proxy Level

In many production architectures, compression is handled by a reverse proxy like Nginx or Caddy rather than the application server itself. This approach has several advantages:

Separation of concerns: The application server focuses on business logic, while the proxy handles transport optimization.
Caching compressed responses: Proxies can cache compressed responses, avoiding repeated compression.
Better compression algorithms: Reverse proxies often support brotli and zstd, which may not be available in the application layer.

However, for applications that need end-to-end compression control or don't sit behind a reverse proxy, implementing compression in Hyperlane middleware is a viable approach.

Measuring Compression Effectiveness

To evaluate the impact of compression on your application, consider these metrics:

Compression ratio: The ratio of compressed size to original size. A ratio of 0.3 means the compressed data is 30% of the original size.
Compression time: The time spent compressing data. This adds latency to each request.
Decompression time: The time clients spend decompressing data. Modern devices decompress very quickly.
Net bandwidth savings: The total reduction in data transferred.

For JSON APIs, typical compression ratios range from 0.2 to 0.4, meaning 60–80% bandwidth savings. For HTML content, ratios of 0.3 to 0.5 are common.

Combining Compression with Other Optimizations

Compression works best when combined with other optimization techniques:

Response Caching

Use Hyperlane's response headers to enable client-side caching:

use hyperlane::*;

#[route("/api/data")]
async fn get_data(ctx: &mut Context) -> Result<(), RequestError> {
    ctx.get_mut_response()
        .add_header("Cache-Control", "max-age=3600")
        .add_header("Vary", "Accept-Encoding");

    // ... fetch and return data
    Ok(())
}

The Vary: Accept-Encoding header tells caches that the response varies based on the client's Accept-Encoding header, ensuring that compressed and uncompressed versions are cached separately.

Connection Management

Hyperlane provides connection management APIs to control connection lifecycle:

use hyperlane::*;

#[route("/api/stream")]
async fn stream_data(ctx: &mut Context) -> Result<(), RequestError> {
    let stream = ctx.get_stream();

    if stream.is_keep_alive() {
        // Keep-Alive connection: can send multiple responses
        stream.send("First chunk\n").await;
        stream.send("Second chunk\n").await;
    } else {
        // Non-Keep-Alive: send everything at once
        stream.send("First chunk\nSecond chunk\n").await;
    }

    Ok(())
}

Efficient Body Handling

For large responses, consider streaming the response body rather than buffering it entirely in memory:

use hyperlane::*;

#[route("/api/large-data")]
async fn large_data(ctx: &mut Context) -> Result<(), RequestError> {
    let response = ctx.get_mut_response();
    response.set_status_code(200);
    response.add_header("Content-Type", "application/json");
    response.add_header("Content-Encoding", "gzip");

    // Stream large data in chunks
    for chunk in generate_large_data() {
        stream.try_send(&chunk).await;
    }

    stream.flush().await;
    Ok(())
}

Conclusion

HTTP compression is a powerful optimization technique that can significantly reduce bandwidth usage and improve response times for Hyperlane applications. By combining compression with Keep-Alive connections, kernel-level tuning, native CPU optimization, and efficient response handling, you can build web servers that deliver exceptional performance.

Hyperlane's impressive baseline performance — 316,211 QPS in benchmark tests — provides a solid foundation. With compression and the optimization strategies discussed in this article, you can push your application's efficiency even further, delivering faster responses while consuming less bandwidth.

Remember to measure the actual impact of compression on your specific workload. The optimal compression strategy depends on your content types, client capabilities, and performance requirements. Start with gzip for broad compatibility, and consider brotli for even better compression ratios when your clients support it.

WebAssembly Deep Dive: How euv Leverages WASM

tengxgfyrz67s — Fri, 19 Jun 2026 09:29:37 +0000

WebAssembly (WASM) is a binary instruction format that runs in modern web browsers at near-native speed. euv is built from the ground up to target WASM, compiling Rust code into efficient browser-executable modules. This article takes a deep dive into how euv uses WebAssembly under the hood, covering the compilation pipeline, memory management, performance characteristics, and the runtime architecture that makes it all work.

The WASM Compilation Pipeline
Memory Management in WASM
How euv Renders via WASM
Performance Characteristics
The Runtime Architecture
Working with JavaScript from WASM
Conclusion

The WASM Compilation Pipeline

The journey from Rust source code to a running euv application in the browser involves several steps:

Rust Source (.rs)
    ↓ rustc (with wasm32-unknown-unknown target)
WASM Binary (.wasm)
    ↓ wasm-bindgen
JavaScript Glue (.js) + WASM Binary
    ↓ Browser loads via ES module
Running Application

Step 1: Project Configuration

Every euv project starts with the proper Cargo.toml configuration:

[package]
edition = "2024"

[dependencies]
euv = "*"
lombok-macros = "*"

[lib]
crate-type = ["cdylib", "rlib"]

The crate-type = ["cdylib"] entry tells the Rust compiler to produce a dynamic library suitable for WASM. The rlib type allows the crate to also be used as a Rust library (for testing, for example).

Step 2: The Application Entry Point

use euv::*;
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn main() {
    console_error_panic_hook::set_once();
    mount("#app", app);
}

The #[wasm_bindgen] attribute generates JavaScript glue code for the main function. The console_error_panic_hook::set_once() call ensures that Rust panics are logged to the browser console — essential for debugging WASM applications.

Step 3: Building with wasm-pack

wasm-pack build --target web --out-dir www/pkg

The --target web flag produces output that can be loaded directly in the browser using ES modules. After a successful build, the pkg/ directory contains:

my_app_bg.wasm — the compiled WebAssembly binary
my_app.js — the JavaScript glue code
package.json — metadata for the package

Step 4: Loading in the Browser

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>euv app</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module">
      import init, { main } from './pkg/euv_example.js';
      await init();
      main();
    </script>
  </body>
</html>

The init() function loads and instantiates the WASM module, and main() starts the euv application.

Step 5: Development with euv CLI

For a smoother development experience, euv provides a CLI tool:

cargo install euv-cli
euv run --crate-path ./example --www-dir ./www --port 80

The CLI handles building, file watching, hot reloading, and serving. Build modes are controlled via flags:

# Development build (debug info enabled, optimizations disabled)
euv run --crate-path ./example --www-dir ./www --port 80 --dev

# Release build (optimizations enabled, debug info disabled)
euv run --crate-path ./example --www-dir ./www --port 80 --release

# Profiling build (optimizations enabled, debug info enabled)
euv run --crate-path ./example --www-dir ./www --port 80 --profiling

Memory Management in WASM

WebAssembly has a fundamentally different memory model than JavaScript. Understanding this model is key to writing efficient euv applications.

Linear Memory

WASM operates on a contiguous block of memory called "linear memory." This is a resizable ArrayBuffer that the WASM module can read and write. All data structures — strings, objects, arrays — are serialized into this linear memory as bytes.

┌──────────────────────────────────────────────┐
│              Linear Memory                    │
├──────────┬──────────┬──────────┬─────────────┤
│ Strings  │ Objects  │ Arrays   │ Free Space  │
└──────────┴──────────┴──────────┴─────────────┘
              ↑ Stack    ↑ Heap

Rust's Ownership Model in WASM

Rust's ownership model works the same way in WASM as it does natively. When a Rust value goes out of scope, its memory is automatically freed. This is particularly powerful in the WASM context because:

No garbage collector — Unlike JavaScript, there's no GC pause or overhead
Deterministic deallocation — Memory is freed exactly when the value goes out of scope
No memory leaks — The ownership system prevents leaks at compile time (in safe Rust)

fn app() -> VirtualNode {
    // count is allocated when use_signal is called
    let count: Signal<i32> = use_signal(|| 0);
    let count_updater: Signal<i32> = count;

    html! {
        div {
            // count is used here, so it stays alive
            span { count }
            button {
                onclick: move |_event: Event| {
                    let current: i32 = count_updater.get();
                    count_updater.set(current + 1);
                }
                "Increment"
            }
        }
    }
    // When this function returns, local variables are dropped
    // But count lives on because it's captured in the closure
}

Memory and the Virtual DOM

The virtual DOM in euv is a Rust data structure that lives in WASM's linear memory. When the renderer compares the old and new virtual DOM trees, it's doing this comparison entirely within WASM memory — no JavaScript round-trips needed.

// The VirtualNode is a Rust enum stored in WASM memory
enum VirtualNode<T> {
    Element {
        tag: Tag,
        attributes: Vec<AttributeEntry>,
        children: Vec<VirtualNode<T>>,
        key: Option<String>,
        props: Option<T>,
    },
    Text(TextNode),
    Fragment(Vec<VirtualNode<T>>),
    Dynamic(Rc<RefCell<DynamicNode<T>>>),
    Empty,
}

The Dynamic variant is particularly interesting — it uses Rc<RefCell<>> to allow shared mutable access to dynamic nodes that need to re-render when their dependencies change.

Signal Memory Layout

Signals in euv are reference-counted reactive containers:

// Signal<T> internally holds:
// - The current value of type T
// - A set of subscriber callbacks (closures)
// - Reference counting for shared ownership

let count: Signal<i32> = use_signal(|| 0);
// count is a smart pointer (Rc<SignalInner<i32>>)
// SignalInner<i32> { value: 0, subscribers: Vec<...>, ... }

When you clone a signal (let count_updater: Signal<i32> = count;), you're incrementing the reference count, not copying the value. This makes signal cloning essentially free.

How euv Renders via WASM

The Rendering Process

When mount("#app", app) is called, the following happens:

The renderer reads the CSS selector #app (via web-sys)
It calls app() to get the initial VirtualNode tree
It creates real DOM elements matching the virtual tree
It inserts those elements into the #app container

use euv::*;

fn app() -> VirtualNode {
    html! {
        div {
            h1 { "Hello, euv!" }
        }
    }
}

// mount internally:
// 1. Finds #app element via web-sys
// 2. Calls app() to get VirtualNode tree
// 3. Creates DOM elements
// 4. Inserts them into #app
mount("#app", app);

Incremental Rendering

When a signal changes, euv's renderer performs an incremental diff:

let count: Signal<i32> = use_signal(|| 0);

html! {
    div {
        // This becomes a DynamicNode that re-renders when count changes
        span { count }
    }
}

The renderer compares the old and new virtual DOM trees, computing the minimal set of changes needed:

Same tag → Patch only changed attributes and children
Different tag → Replace the entire DOM node
Same text → Skip the update entirely

Keyed Diffing

For list rendering, euv supports keyed diffing to efficiently handle reordering:

struct Item {
    id: String,
    name: String,
}

html! {
    ul {
        for item in { items.get() } {
            li {
                key: item.id
                item.name
            }
        }
    }
}

When all children have a key attribute, the renderer uses a key-based diff algorithm that can reuse existing DOM nodes even when the list order changes. Without keys, it falls back to positional diffing (comparing by index).

Event Delegation

euv's renderer uses global event delegation for bubbling events. Instead of attaching individual event listeners to each element, it registers a single listener on window and dispatches events based on the element's ID:

html! {
    button {
        onclick: move |event: Event| {
            // This handler is stored in a global registry
            // and dispatched by the window-level listener
        }
        "Click me"
    }
}

This dramatically reduces the number of DOM event listeners, improving both memory usage and performance.

Performance Characteristics

Why WASM is Fast

WebAssembly offers several performance advantages over JavaScript:

Near-native speed — WASM instructions map closely to native CPU instructions
No parsing overhead — WASM is a binary format that doesn't need parsing like JavaScript
No GC pauses — Rust's ownership model means no garbage collection
Predictable performance — No JIT warmup or deoptimization

Virtual DOM Diffing Performance

euv's virtual DOM diffing happens entirely in WASM memory, which offers several advantages:

// The diff computation is a pure Rust function
// No JavaScript round-trips during diffing
fn diff(old: &VirtualNode, new: &VirtualNode) -> PatchSet {
    // ... comparison logic ...
}

The only JavaScript interaction happens when patches are applied to the real DOM (via web-sys).

Rendering Optimization

euv includes an important optimization: when a DynamicNode re-renders, the renderer compares the new virtual DOM output with the old one. If they're identical, the DOM patch is skipped entirely:

let count: Signal<i32> = use_signal(|| 0);

html! {
    div {
        // DynamicNode re-renders when count changes
        span { { format!("Count: {}", count.get()) } }
        // But if the formatted string hasn't changed,
        // the DOM update is skipped
    }
}

This is particularly effective for scenarios where signals update frequently but the rendered output doesn't change (e.g., a timer signal that updates every second but the display only shows minutes).

Batch Updates

The batch function groups multiple signal updates into a single DOM update:

use euv::*;

// Multiple set() calls within a batch are coalesced
batch(|| {
    signal1.set(value1);
    signal2.set(value2);
    signal3.set(value3);
});
// Only one DOM update happens after the batch

The watch! macro also uses batching internally:

let celsius: Signal<f64> = use_signal(|| 0.0);
let fahrenheit: Signal<f64> = use_signal(|| 32.0);

watch!(celsius, |celsius_value: f64| {
    fahrenheit.set(celsius_value * 9.0 / 5.0 + 32.0);
});

watch!(fahrenheit, |fahrenheit_value: f64| {
    celsius.set((fahrenheit_value - 32.0) * 5.0 / 9.0);
});

When two signals watch each other, the batch mechanism ensures that cascading set calls within the same frame are merged into a single DOM update, preventing intermediate state flicker.

The Runtime Architecture

Hook System

euv's hook system manages the lifecycle of reactive primitives within dynamic nodes. Each DynamicNode has an associated HookContext that stores:

Signal subscriptions
Cleanup callbacks
Interval handles
Window event listeners

fn timer_tab() -> VirtualNode {
    let elapsed: Signal<i32> = use_signal(|| 0);
    let running: Signal<bool> = use_signal(|| false);
    let handle: Signal<Option<IntervalHandle>> = use_signal(|| None);

    // Register a cleanup callback
    use_cleanup(move || {
        if let Some(h) = handle.get() {
            h.clear();
        }
    });

    // Use watch! to react to signal changes
    watch!(running, |is_running: bool| {
        if is_running {
            let elapsed_signal: Signal<i32> = elapsed;
            let handle_signal: Signal<Option<IntervalHandle>> = handle;
            let new_handle: IntervalHandle = use_interval(1000, move || {
                let current: i32 = elapsed_signal.get();
                elapsed_signal.set(current + 1);
            });
            handle_signal.set(Some(new_handle));
        } else {
            let handle_opt: Option<IntervalHandle> = handle.get();
            if let Some(existing_handle) = handle_opt {
                existing_handle.clear();
            }
            handle.set(None);
        }
    });

    html! {
        div {
            span { { format_time(elapsed.get()) } }
            if { !running.get() } {
                button {
                    onclick: move |_event: Event| { running.set(true); }
                    "Start"
                }
            } else {
                button {
                    onclick: move |_event: Event| { running.set(false); }
                    "Pause"
                }
            }
        }
    }
}

Component Lifecycle

Components in euv are functions that return VirtualNode. The #[component] attribute macro marks them for the html! macro to recognize:

use euv::*;

#[derive(Clone, Default)]
struct MyCardProps {
    title: &'static str,
}

#[component]
pub fn my_card(node: VirtualNode<MyCardProps>) -> VirtualNode {
    let MyCardProps { title, .. }: MyCardProps = node.try_get_props().unwrap_or_default();
    let children: VirtualNode = node.try_get_child_node();
    html! {
        div {
            class: c_card()
            h3 {
                class: c_card_title()
                title
            }
            children
        }
    }
}

The component lifecycle is managed through the virtual DOM:

Creation — When a component tag is encountered in html!, the component function is called
Update — When a parent re-renders, the component function is called again with new props
Cleanup — When a component is removed from the DOM, its associated hooks are cleaned up

The Keep-Alive Pattern

In euv, using match or if/else to switch components destroys the old branch and creates a new one. The Keep-Alive pattern uses CSS display: none/block to preserve component state:

let tab: Signal<String> = use_signal(|| "counter".to_string());

html! {
    div {
        // Tab bar
        div {
            class: c_tab_bar()
            div {
                class: if { tab.get() == "counter" } { c_tab_item_active() } else { c_tab_item_inactive() }
                onclick: move |_event: Event| { tab.set("counter".to_string()); }
                "Counter"
            }
            div {
                class: if { tab.get() == "form" } { c_tab_item_active() } else { c_tab_item_inactive() }
                onclick: move |_event: Event| { tab.set("form".to_string()); }
                "Form"
            }
        }
        // Render all tabs simultaneously, control visibility with display
        div {
            style: { display: if { tab.get() == "counter" } { "block".to_string() } else { "none".to_string() }; }
            { counter_tab() }
        }
        div {
            style: { display: if { tab.get() == "form" } { "block".to_string() } else { "none".to_string() }; }
            { form_tab() }
        }
    }
}

This keeps all DynamicNode instances and their HookContext alive — signals retain values, setInterval continues running, and form inputs preserve their state.

Working with JavaScript from WASM

The js-sys Bridge

When euv needs to interact with JavaScript (e.g., making HTTP requests), it goes through js-sys:

use euv::*;

// fetch is a JavaScript API accessed through js-sys/web-sys
let window: Window = window().expect("no global window exists");
let promise: Promise = window.fetch_with_str("https://httpbin.org/get");
let future: JsFuture = JsFuture::from(promise);

The web-sys Bridge

For browser APIs, euv uses web-sys:

use euv::*;

let win: Window = window().expect("no global window exists");
let location: Location = win.location();
let hash: String = location.hash().unwrap_or_default();
let _ = location.set_hash("#/about");

Type Conversion

Crossing the WASM boundary requires type conversion. euv handles this automatically through several traits:

// IntoNode trait - converts Rust types to VirtualNode
// String, &str, i32, bool, Signal<T>, etc. all implement IntoNode

let count: Signal<i32> = use_signal(|| 0);

html! {
    div {
        // count (Signal<i32>) is converted to VirtualNode via IntoNode
        count
        // String is converted via IntoNode
        "Hello"
        // i32 is converted via IntoNode
        42
    }
}

The IntoReactiveValue trait handles attribute value conversion:

// All of these can be used as attribute values:
html! {
    div {
        data_role: "container"           // &str → AttributeValue::Text
        data_id: "12345"                 // &str → AttributeValue::Text
        aria_label: "Demo section"       // &str → AttributeValue::Text
    }
}

Conclusion

euv's use of WebAssembly is not just a compilation target — it's a fundamental design choice that shapes every aspect of the framework:

Memory safety through Rust's ownership model, with no GC overhead
Near-native performance for virtual DOM diffing and signal computations
Efficient event handling through global delegation
Deterministic resource management through the hook system and cleanup callbacks

The WASM compilation pipeline — from Rust source through wasm-bindgen to browser execution — is streamlined by tools like wasm-pack and the euv CLI. The result is a framework that brings the power of Rust's type system and performance to the browser, while maintaining seamless interoperability with the JavaScript ecosystem through js-sys and web-sys.

Understanding the WASM internals helps you write more efficient euv applications. Key takeaways:

Signal cloning is cheap (reference counting, not deep copy)
Virtual DOM diffing happens entirely in WASM memory
Use batch to group signal updates
Use the Keep-Alive pattern to preserve component state across tab switches
All browser APIs are accessible through use euv::* — no need for direct js-sys or web-sys dependencies

Animation and Transitions in euv

tengxgfyrz67s — Fri, 19 Jun 2026 09:25:34 +0000

Animations are a crucial part of modern web user interfaces. They provide visual feedback, guide user attention, and make applications feel polished and responsive. euv provides a comprehensive animation system that supports CSS transitions, built-in keyframe animations, conditional animations, and custom keyframe injection. This article explores all the animation capabilities available in euv and how to use them effectively.

CSS Transitions

CSS transitions are the simplest way to add animation to your euv components. A CSS transition smoothly interpolates between two property values over a specified duration. You define the transition on an element, and the browser handles the intermediate frames automatically.

In euv, you can apply CSS transitions to any element in your html! template. Transitions work with any animatable CSS property, including opacity, transform, background-color, width, height, and more.

To use a transition, you typically define the following CSS properties on the element:

transition-property: Which CSS property to animate (e.g., opacity, transform, all).
transition-duration: How long the animation takes (e.g., 0.3s).
transition-timing-function: The easing curve (e.g., ease, ease-in-out, linear).
transition-delay: An optional delay before the animation starts.

Transitions are triggered when a CSS property changes — for example, when a class is added or removed, or when a style property is updated via a reactive signal.

Built-in Keyframe Animations

euv ships with a set of pre-built CSS keyframe animations that you can apply to any element. These animations cover common UI patterns and can be used directly without writing any CSS:

euv-spin: A 360-degree rotation animation, useful for loading spinners and refresh indicators.
euv-fade-in: A fade-in from transparent to opaque, great for elements appearing on screen.
euv-scale-in: A scale-up animation from small to full size, ideal for modals and popups.
euv-pulse: A pulsing scale animation, perfect for drawing attention to notifications or alerts.
euv-slide-up: A slide-in from below, commonly used for bottom sheets and toast messages.
euv-slide-left: A slide-in from the right, suitable for side panels and navigation drawers.
euv-fade-in-up: A combined fade-in and slide-up animation, excellent for dropdown menus and tooltips.
euv-progress: A progress bar animation, useful for loading bars and completion indicators.
euv-shimmer: A shimmering highlight effect, often used for skeleton loading placeholders.

To apply any of these animations, simply add the corresponding class to your element. These keyframe animations are defined in euv's built-in CSS and are ready to use out of the box.

Conditional Animations

Conditional animations allow you to trigger animations based on component state. In euv, this is typically achieved by conditionally applying CSS classes or styles based on reactive signals.

For example, you might want an element to fade in when it first appears and fade out when it is removed. By toggling a CSS class based on a signal, you can control when the animation plays:

let shared_text: Signal<String> = use_signal(|| "Type here...".to_string());

In this example, the shared_text signal holds the current state. You can use this signal to conditionally apply animation classes in your html! template. When the signal changes, the class is added or removed, triggering the CSS transition or keyframe animation.

Conditional animations are particularly powerful when combined with the watch! macro, which can observe state changes and trigger side effects:

watch!(celsius, |celsius_value: f64| {
    fahrenheit.set(celsius_value * 9.0 / 5.0 + 32.0);
});

Here, the watch! macro observes the celsius signal and automatically updates the fahrenheit signal. You can extend this pattern to trigger animations — for example, flashing a visual indicator when a value crosses a threshold.

Custom Keyframes with Css::inject_css()

While the built-in animations cover many common use cases, you may need custom animations for specific design requirements. euv provides the Css::inject_css() function for this purpose.

Css::inject_css() allows you to inject arbitrary CSS into the page at runtime, including custom @keyframes definitions. This gives you full control over your animations without leaving the Rust code.

To create a custom animation:

Define your @keyframes CSS using Css::inject_css().
Apply the animation to an element using the animation CSS property or the class! macro.

For example, you could create a custom bounce animation:

// Inject custom keyframes
Css::inject_css("@keyframes custom-bounce {
    0%, 100% { transform: translateY(0); }
    50% { transform: translateY(-20px); }
}");

Then apply it to an element in your template. The injected CSS is added to the document's stylesheet and is available to all elements on the page.

Progress Bar Animation

The euv-progress keyframe animation is specifically designed for progress bar use cases. It creates a smooth, continuous animation that visually indicates progress.

Progress bar animations are commonly used for:

File upload progress: Showing how much of a file has been uploaded.
Loading indicators: Displaying the progress of data fetching or processing.
Multi-step forms: Indicating which step the user is on in a multi-step process.
Task completion: Showing the overall completion percentage of a long-running task.

The euv-progress animation can be combined with reactive signals to create dynamic progress bars that update in real time as data changes.

Animation Best Practices

When working with animations in euv, keep the following best practices in mind:

Use CSS transitions for simple state changes: If you just need to smoothly change a property value (like opacity or color), CSS transitions are the most performant option.
Leverage built-in keyframe animations: Before writing custom CSS, check if one of the built-in animations (euv-spin, euv-fade-in, euv-scale-in, euv-pulse, euv-slide-up, euv-slide-left, euv-fade-in-up, euv-progress, euv-shimmer) meets your needs.
Use conditional animations sparingly: While it is tempting to animate every state change, excessive animations can be distracting. Animate only the changes that provide meaningful feedback to the user.
Prefer transform and opacity: These properties are GPU-accelerated and provide the smoothest animations. Avoid animating properties like width, height, margin, or padding that trigger layout recalculations.
Test on low-end devices: Animations that run smoothly on a high-end desktop may stutter on mobile devices. Always test your animations on target hardware.
Respect user preferences: Some users prefer reduced motion. Consider respecting the prefers-reduced-motion media query by conditionally disabling animations.

Combining Animations with Reactive Signals

The real power of euv's animation system emerges when you combine it with the reactive signal system. By driving CSS classes and styles from signals, you can create animations that respond to user input, data changes, and application state in real time.

Consider this pattern:

let shared_text: Signal<String> = use_signal(|| "Type here...".to_string());

pub fn child_input(text_signal: Signal<String>, count_signal: Signal<i32>) -> VirtualNode {
    html! {
        div {
            input {
                r#type: "text"
                value: text_signal.get()
                oninput: on_input_value(text_signal)
            }
        }
    }
}

The text_signal signal drives the input's value. When the user types, on_input_value updates the signal, which in turn updates any other elements that read from the same signal. You can use this pattern to trigger animations — for example, adding a euv-shimmer class to a skeleton loader while data is being fetched, and switching to euv-fade-in when the data arrives.

Event Handlers for Animations

euv provides event handlers that let you respond to animation lifecycle events:

onanimationstart: Fired when a CSS animation starts.
onanimationend: Fired when a CSS animation completes.
onanimationiteration: Fired when a CSS animation iteration completes (for repeating animations).
ontransitionend: Fired when a CSS transition completes.

These event handlers enable you to chain animations, trigger actions after animations complete, or coordinate multiple animations across different elements.

Summary

euv provides a comprehensive animation system that covers all the common animation needs in modern web development:

CSS transitions for smooth property interpolations.
Built-in keyframe animations (euv-spin, euv-fade-in, euv-scale-in, euv-pulse, euv-slide-up, euv-slide-left, euv-fade-in-up, euv-progress, euv-shimmer) for common UI patterns.
Conditional animations driven by reactive signals for state-dependent visual effects.
Custom keyframes via Css::inject_css() for advanced animation requirements.
Progress bar animations for loading and completion indicators.
Animation event handlers (onanimationstart, ontransitionend, etc.) for lifecycle management.

By combining these animation capabilities with euv's reactive signal system, you can create rich, interactive, and visually appealing user interfaces that respond fluidly to user input and data changes.

Getting Started with euv

tengxgfyrz67s — Fri, 19 Jun 2026 09:24:36 +0000

What is euv?

euv is a modern frontend UI framework built on Rust and WebAssembly (WASM). It brings the performance and type safety of Rust to the browser, enabling developers to build fast, reliable web applications. At its core, euv uses a virtual DOM for efficient UI updates and a reactive signals system for state management — similar in spirit to frameworks like React and Solid, but with the unique advantages of the Rust ecosystem.

Key Features

Rust + WASM: Write your frontend in Rust and compile to WebAssembly for near-native performance in the browser.
Virtual DOM: Efficient diffing and patching of the DOM, minimizing expensive browser operations.
Reactive Signals: A fine-grained reactivity system that automatically tracks dependencies and updates only what's necessary.
Macro-powered DSL: The html! and class! macros provide a familiar, HTML-like syntax directly in Rust code.
Component System: Build reusable, composable UI components with strongly-typed props.
Built-in Animations: Ready-to-use CSS keyframe animations like euv-spin, euv-fade-in, and more.
Browser API Access: First-class support for Window, Document, Storage, Clipboard, Navigator, and other browser APIs.
Async Support: Seamless async operations via spawn_local, with JsFuture, Promise, and Response available through the prelude.

Installation

Getting started with euv is straightforward. Since it's a Rust crate, you add it to your project using Cargo:

cargo add euv

This command adds euv as a dependency to your Cargo.toml. Make sure you already have a WASM-compatible project set up (e.g., using wasm-pack or trunk for building and serving).

Your First euv Application

Let's build the classic "Hello, World!" application in euv. This will introduce the fundamental concepts: the html! macro, the mount function, and the component pattern.

use euv::*;

fn app() -> VirtualNode {
    html! {
        div {
            h1 { "Hello, euv!" }
        }
    }
}

mount("#app", app);

Let's break this down:

use euv::* — This brings all the essential items into scope: the html! macro, the mount function, the VirtualNode type, and many more utilities.
fn app() -> VirtualNode — Every euv application starts with a root component function that returns a VirtualNode. This function describes what the UI should look like.
html! { ... } — The html! macro lets you write HTML-like syntax directly in Rust. Inside the macro, you can nest elements, add text content, and compose your UI declaratively.
mount("#app", app) — This function takes a CSS selector and a component function, then renders the component into the DOM element matching the selector.

Mounting to Different Selectors

The mount function supports several types of CSS selectors:

// Mount to an element with id="app"
mount("#app", app);

// Mount to the <body> element
mount("body", app);

// Mount to an element with class="root"
mount(".root", app);

// Mount to the first <main> element
mount("main", app);

Choose the selector that best fits your project's HTML structure. The most common choice is an ID selector like "#app".

Understanding the Basic Structure

Every euv application follows a consistent pattern:

use euv::*;

// Define your root component
fn app() -> VirtualNode {
    html! {
        div {
            // Your UI goes here
            h1 { "Welcome to euv" }
            p { "Build fast web apps with Rust and WASM." }
        }
    }
}

// Mount the application to the DOM
mount("#app", app);

The html! macro is the heart of euv's templating system. It allows you to write:

Nested elements: div { p { "text" } }
Text content: Just place a string inside curly braces after an element name
Attributes: input { type: "text", placeholder: "Enter name" }
Event handlers: button { onclick: move |event| { /* handler */ } "Click" }
Conditional rendering: if { condition } { /* visible */ } else { "" }
List rendering: for item in { items.get() } { li { item } }

A Slightly More Complex Example

Let's look at a more complete example that demonstrates state and interactivity:

use euv::*;

fn app() -> VirtualNode {
    let count: Signal<i32> = use_signal(|| 0);

    html! {
        div {
            h1 { "My First euv App" }
            p { "The counter will go here" }
            button {
                onclick: move |event: Event| {
                    count.set(count.get() + 1);
                }
                "Increment"
            }
        }
    }
}

mount("#app", app);

In this example:

We create a reactive signal count with an initial value of 0 using use_signal.
The button has an onclick event handler that reads the current value with count.get() and updates it with count.set(...).
When the signal changes, euv automatically re-renders the affected parts of the UI.

Next Steps

Now that you've created your first euv application, here are some topics to explore next:

Reactive Signals: Learn how use_signal, computed!, and watch! power euv's reactivity system.
The Virtual DOM: Understand how VirtualNode works under the hood.
Components: Build reusable UI components with props and children.
Styling: Use the class! macro to define CSS classes and animations.
Event Handling: Master event handling patterns for interactive applications.
Conditional Rendering & Lists: Dynamically render UI based on state.

euv combines the best of Rust's type safety and performance with a modern, declarative UI paradigm. Whether you're building a small interactive widget or a full-featured single-page application, euv provides the tools to do it efficiently and enjoyably.

Happy coding with euv!

Getting Started with euv

tengxgfyrz67s — Fri, 19 Jun 2026 08:44:44 +0000

Getting Started with euv

What is euv?

euv is a modern frontend UI framework built on Rust and WebAssembly (WASM). It brings the performance and type safety of Rust to the browser, enabling developers to build fast, reliable web applications. At its core, euv uses a virtual DOM for efficient UI updates and a reactive signals system for state management â€” similar in spirit to frameworks like React and Solid, but with the unique advantages of the Rust ecosystem.

Key Features

Rust + WASM: Write your frontend in Rust and compile to WebAssembly for near-native performance in the browser.
Virtual DOM: Efficient diffing and patching of the DOM, minimizing expensive browser operations.
Reactive Signals: A fine-grained reactivity system that automatically tracks dependencies and updates only what's necessary.
Macro-powered DSL: The html! and class! macros provide a familiar, HTML-like syntax directly in Rust code.
Component System: Build reusable, composable UI components with strongly-typed props.
Built-in Animations: Ready-to-use CSS keyframe animations like euv-spin, euv-fade-in, and more.
Browser API Access: First-class support for Window, Document, Storage, Clipboard, Navigator, and other browser APIs.
Async Support: Seamless async operations via spawn_local, with JsFuture, Promise, and Response available through the prelude.

Installation

Getting started with euv is straightforward. Since it's a Rust crate, you add it to your project using Cargo:

cargo add euv

This command adds euv as a dependency to your Cargo.toml. Make sure you already have a WASM-compatible project set up (e.g., using wasm-pack or trunk for building and serving).

Your First euv Application

Let's build the classic "Hello, World!" application in euv. This will introduce the fundamental concepts: the html! macro, the mount function, and the component pattern.

use euv::*;

fn app() -> VirtualNode {
    html! {
        div {
            h1 { "Hello, euv!" }
        }
    }
}

mount("#app", app);

Let's break this down:

use euv::* â€” This brings all the essential items into scope: the html! macro, the mount function, the VirtualNode type, and many more utilities.
fn app() -> VirtualNode â€” Every euv application starts with a root component function that returns a VirtualNode. This function describes what the UI should look like.
html! { ... } â€” The html! macro lets you write HTML-like syntax directly in Rust. Inside the macro, you can nest elements, add text content, and compose your UI declaratively.
mount("#app", app) â€” This function takes a CSS selector and a component function, then renders the component into the DOM element matching the selector.

Mounting to Different Selectors

The mount function supports several types of CSS selectors:

// Mount to an element with id="app"
mount("#app", app);

// Mount to the <body> element
mount("body", app);

// Mount to an element with class="root"
mount(".root", app);

// Mount to the first <main> element
mount("main", app);

Choose the selector that best fits your project's HTML structure. The most common choice is an ID selector like "#app".

Understanding the Basic Structure

Every euv application follows a consistent pattern:

use euv::*;

// Define your root component
fn app() -> VirtualNode {
    html! {
        div {
            // Your UI goes here
            h1 { "Welcome to euv" }
            p { "Build fast web apps with Rust and WASM." }
        }
    }
}

// Mount the application to the DOM
mount("#app", app);

The html! macro is the heart of euv's templating system. It allows you to write:

Nested elements: div { p { "text" } }
Text content: Just place a string inside curly braces after an element name
Attributes: input { type: "text", placeholder: "Enter name" }
Event handlers: button { onclick: move |event| { /* handler */ } "Click" }
Conditional rendering: if { condition } { /* visible */ } else { "" }
List rendering: for item in { items.get() } { li { item } }

A Slightly More Complex Example

Let's look at a more complete example that demonstrates state and interactivity:

use euv::*;

fn app() -> VirtualNode {
    let count: Signal<i32> = use_signal(|| 0);

    html! {
        div {
            h1 { "My First euv App" }
            p { "The counter will go here" }
            button {
                onclick: move |event: Event| {
                    count.set(count.get() + 1);
                }
                "Increment"
            }
        }
    }
}

mount("#app", app);

In this example:

We create a reactive signal count with an initial value of 0 using use_signal.
The button has an onclick event handler that reads the current value with count.get() and updates it with count.set(...).
When the signal changes, euv automatically re-renders the affected parts of the UI.

Next Steps

Now that you've created your first euv application, here are some topics to explore next:

Reactive Signals: Learn how use_signal, computed!, and watch! power euv's reactivity system.
The Virtual DOM: Understand how VirtualNode works under the hood.
Components: Build reusable UI components with props and children.
Styling: Use the class! macro to define CSS classes and animations.
Event Handling: Master event handling patterns for interactive applications.
Conditional Rendering & Lists: Dynamically render UI based on state.

Happy coding with euv!

Getting Started with Hyperlane

tengxgfyrz67s — Fri, 19 Jun 2026 08:39:39 +0000

DEV Community: tengxgfyrz67s

构建组件

组件简介

定义组件

Props 结构体

组件函数

使用组件

组件嵌套

向组件传递子节点

Props Down / Callback Up

共享信号实现双向绑定

使用 watch! 实现跨组件响应式绑定

Keep-Alive 模式

总结

HTTP Compression and Optimization

Why Compression Matters

Understanding Compression Algorithms

gzip

deflate

brotli

Integrating Compression with Hyperlane

Using Middleware for Response Compression

Configuring Compression Based on Content Type

Performance Optimization Strategies

1. Enable Keep-Alive Connections

2. Optimize Linux Kernel Parameters

3. Use Native CPU Optimization

4. Configure Server Parameters

5. Optimize Request Parsing

Compression at the Reverse Proxy Level

Measuring Compression Effectiveness

Combining Compression with Other Optimizations

Response Caching

Connection Management

Efficient Body Handling

Conclusion

WebAssembly Deep Dive: How euv Leverages WASM

Table of Contents

The WASM Compilation Pipeline

Step 1: Project Configuration

Step 2: The Application Entry Point

Step 3: Building with wasm-pack

Step 4: Loading in the Browser

Step 5: Development with euv CLI

Memory Management in WASM

Linear Memory

Rust's Ownership Model in WASM

Memory and the Virtual DOM

Signal Memory Layout

How euv Renders via WASM

The Rendering Process

Incremental Rendering

Keyed Diffing

Event Delegation

Performance Characteristics

Why WASM is Fast

Virtual DOM Diffing Performance

Rendering Optimization

Batch Updates

The Runtime Architecture

Hook System

Component Lifecycle

The Keep-Alive Pattern

Working with JavaScript from WASM

The js-sys Bridge

The web-sys Bridge

Type Conversion

Conclusion

Animation and Transitions in euv

CSS Transitions

Built-in Keyframe Animations

Conditional Animations

Custom Keyframes with Css::inject_css()

Progress Bar Animation

Animation Best Practices

Combining Animations with Reactive Signals

Event Handlers for Animations

Summary

Getting Started with euv

What is euv?