English for Leptos Developers

Leptos brings fine-grained reactivity vocabulary from the SolidJS world into Rust, so a developer with a React or Vue background needs to relearn how state updates propagate, and a Rust backend developer needs new frontend-specific terms.

Key Vocabulary

Signal — a reactive value created with create_signal, consisting of a getter and setter, that automatically notifies any part of the UI reading it when the value changes. “Wrap that counter in a signal instead of a plain i32 — otherwise the view never re-renders when it changes.”

Fine-grained reactivity — Leptos’s update model where only the specific DOM nodes depending on a changed signal re-render, rather than diffing an entire component tree like virtual-DOM frameworks. “Because of fine-grained reactivity, updating this one signal only touches the text node it’s bound to — the rest of the component doesn’t re-run at all.”

Resource — an async data source tied to reactive inputs, automatically refetched when those inputs change, and integrated with Suspense for loading states. “Turn that manual fetch call into a resource — it’ll refetch automatically when the signal it depends on changes, and Suspense handles the loading state.”

Server function — a function annotated with #[server] that runs only on the server but can be called directly from client-side code, with Leptos generating the network call behind the scenes. “Move that database query into a server function instead of exposing a separate REST endpoint — the client can call it like a normal async function.”

Hydration — the process of attaching interactivity to server-rendered HTML on the client, so the page is visible immediately but becomes fully interactive once Leptos’s client-side code runs. “The button looks right but doesn’t respond to clicks yet — that’s expected until hydration finishes.”

Common Phrases

• “Is this value a signal, or is it a plain variable that won’t trigger a re-render?”
• “Should this be a resource, or is a one-off async call enough here?”
• “Can we move this logic into a server function instead of standing up a separate API route?”
• “Is the flash of unstyled content happening before or after hydration completes?”
• “Does fine-grained reactivity actually help here, or are we over-signaling a value that never changes independently?”

Example Sentences

Debugging a reactivity issue: “The UI isn’t updating because this was read once outside a reactive context — wrap the read in a closure so Leptos can track it as a dependency.”

Explaining an architecture choice: “We used a server function for the database call so the query logic stays server-side, but the client can still call it with normal Rust async syntax.”

Reviewing a pull request: “This should be a resource, not a signal populated manually in an effect — it’ll handle refetching and loading state for us.”

Professional Tips

• Say signal precisely when describing reactive state — calling it “a variable” in a review makes it unclear whether the UI will actually respond to changes.
• Reference fine-grained reactivity when explaining why only part of a page updates — it distinguishes Leptos’s model from virtual-DOM re-rendering and shows you understand the performance story.
• Use server function rather than “backend endpoint” when the code is defined with #[server] — it’s a specific mechanism, not a generic API call.
• Mention hydration explicitly when debugging “works after refresh but not on load” bugs — it’s almost always a hydration-timing issue.

Practice Exercise

1. Explain the difference between a signal and a plain variable in terms of UI updates.
2. Describe what a resource does that a manual async fetch inside an effect wouldn’t.
3. Write a sentence explaining what a server function is and why it’s convenient compared to a separate API route.