Debugging with {@debug} in Svelte - Deep Dive

Overview - Debugging with {@debug}

What is it?

In Svelte, {@debug} is a special tag that helps you see the current values of variables while your app runs. It shows these values right in the browser console automatically. This makes it easier to find mistakes or understand how your app changes over time without adding extra code.

Why it matters

Without {@debug}, developers often add many manual console.log statements to check variable values, which can clutter code and slow down debugging. {@debug} simplifies this by showing variable states clearly and temporarily, helping you fix problems faster and write better apps.

Where it fits

Before learning {@debug}, you should know basic Svelte syntax and how to create reactive variables. After mastering {@debug}, you can explore more advanced debugging tools like browser DevTools and Svelte DevTools extensions.

Mental Model

Core Idea

The {@debug} tag automatically logs the current values of specified variables to the browser console whenever they change, making debugging simple and clear.

Think of it like...

It's like having a smart assistant who quietly watches your work and tells you exactly what your tools are doing at every step, without you having to ask or write notes yourself.

┌─────────────┐
│ Svelte App  │
│             │
│ {@debug x}  │───▶ Logs 'x' value to console
│ {@debug y}  │───▶ Logs 'y' value to console
└─────────────┘

Browser Console:
  x = 42
  y = 'hello'

Updates automatically when x or y changes

Build-Up - 7 Steps

1

Foundation

What is {@debug} in Svelte

Concept: Introduce the {@debug} tag as a built-in Svelte feature for debugging variables.

In Svelte, you can write {@debug variableName} inside your component. This tells Svelte to watch that variable and print its value to the browser console whenever it changes. You don't need to write console.log yourself.

Result

When you run your app and the variable changes, its value appears in the console automatically.

Understanding that {@debug} is a simple, automatic way to watch variables helps you debug without cluttering your code.

2

Foundation

How to use {@debug} with multiple variables

Concept: Learn that {@debug} can watch one or more variables at once.

You can write {@debug x, y, z} to watch several variables together. Svelte will log all their current values in one message whenever any of them changes.

Result

Console shows all specified variables and their values grouped together, making it easier to see related data.

Knowing you can debug multiple variables at once saves time and helps track how variables relate.

3

Intermediate

When does {@debug} log variable values

🤔Before reading on: Do you think {@debug} logs values only when variables change, or every time the component renders? Commit to your answer.

Concept: Understand the timing of {@debug} logs in relation to variable changes and component updates.

Svelte runs {@debug} after reactive updates, so it logs variable values only when those variables change, not on every render. This means you see relevant updates without noise.

Result

Console logs appear only when watched variables actually change, keeping output clean and meaningful.

Knowing when {@debug} triggers helps you trust its output and avoid confusion from unnecessary logs.

4

Intermediate

Using {@debug} with reactive statements

🤔Before reading on: Will {@debug} show values inside reactive statements ($:) immediately or only after the statement runs? Commit to your answer.

Concept: Learn how {@debug} interacts with Svelte's reactive declarations and updates.

When you use {@debug} with variables updated by reactive statements, it logs their new values after the reactive code runs. This helps you see the effect of reactive logic in real time.

Result

Console shows updated variable values reflecting reactive computations as they happen.

Understanding this timing clarifies how reactive data flows and helps debug complex state changes.

5

Intermediate

Limitations of {@debug} in production

Concept: Recognize that {@debug} is meant for development and not for production use.

The {@debug} tag only works during development builds. It does not appear or log anything in production builds, so it won't affect your live app's performance or security.

Result

You can safely use {@debug} without worrying about leaving debug logs in your final app.

Knowing this prevents accidental debug leaks and encourages using {@debug} freely during development.

6

Advanced

How {@debug} integrates with Svelte's reactivity

🤔Before reading on: Do you think {@debug} is a separate logging tool or deeply integrated into Svelte's reactive system? Commit to your answer.

Concept: Explore how {@debug} hooks into Svelte's reactive update cycle to log variable states efficiently.

Internally, {@debug} is compiled into code that runs after reactive updates. It accesses the latest variable values and sends them to the console. This tight integration means it only logs when needed, without extra overhead.

Result

Debug logs are accurate, timely, and efficient, reflecting the true state of variables after updates.

Understanding this integration explains why {@debug} is more reliable and cleaner than manual logging.

7

Expert

Surprising behavior with complex expressions

🤔Before reading on: Will {@debug} accept expressions like x + y or only simple variable names? Commit to your answer.

Concept: Discover that {@debug} only accepts variable names, not arbitrary expressions, and what that means for debugging.

You cannot use {@debug x + y} because it expects variable names to watch. To debug expressions, you must assign them to variables first. This design keeps {@debug} simple and focused on state, not calculations.

Result

Trying to debug expressions directly causes errors; assigning expressions to variables first is the correct approach.

Knowing this prevents confusion and errors, guiding you to structure your code for effective debugging.

Under the Hood

The {@debug} tag is compiled by Svelte into JavaScript code that runs after the component's reactive updates. It accesses the current values of the specified variables and calls console.log with their names and values. This happens only when those variables change, leveraging Svelte's reactive system to avoid unnecessary logs.

Why designed this way?

Svelte's design favors compile-time transformations for efficiency. {@debug} was built as a compile-time feature to integrate tightly with reactivity, avoiding runtime overhead and manual logging clutter. Alternatives like manual console.log are less efficient and more error-prone.

┌─────────────────────────────┐
│ Svelte Compiler             │
│                             │
│  Parses {@debug x, y}       │
│  ↓                          │
│  Generates JS code:          │
│  After reactive updates:     │
│  console.log('x', x, 'y', y)│
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Browser Runtime             │
│                             │
│  Reactive variables update  │
│  → {@debug} logs values     │
│  → Console shows output     │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does {@debug} log variable values even if they never change? Commit to yes or no.

Common Belief: Some think {@debug} logs variable values every time the component renders, regardless of changes.

Reality: In truth, {@debug} logs only when the watched variables change, not on every render.

Why it matters: Believing it logs every render can cause confusion and lead to ignoring useful debug output.

Quick: Can you use {@debug} with any JavaScript expression like x + y? Commit to yes or no.

Common Belief: Many assume {@debug} can debug any expression directly inside the tag.

Reality: Actually, {@debug} only accepts variable names, not expressions. Expressions must be assigned to variables first.

Why it matters: Trying to debug expressions directly causes errors and wastes time troubleshooting.

Quick: Does {@debug} output appear in production builds? Commit to yes or no.

Common Belief: Some believe {@debug} logs remain active in production apps.

Reality: The {@debug} tag is stripped out during production builds and produces no output.

Why it matters: Misunderstanding this might cause unnecessary worry about debug logs leaking in live apps.

Quick: Is {@debug} a replacement for all debugging tools? Commit to yes or no.

Common Belief: Some think {@debug} replaces browser DevTools and other debugging methods completely.

Reality: While helpful, {@debug} is a simple tool best used alongside other debugging techniques.

Why it matters: Relying only on {@debug} limits your ability to diagnose complex issues.

Expert Zone

1

Using {@debug} inside nested components only logs variables local to that component, so understanding component boundaries is key.

2

When multiple {@debug} tags watch overlapping variables, Svelte logs each tag's variables separately, which can cause repeated logs.

3

{@debug} does not track variables declared inside functions or blocks; it only watches top-level reactive variables.

When NOT to use

Avoid {@debug} when debugging complex asynchronous flows or deeply nested state changes; use browser DevTools breakpoints or Svelte DevTools instead for better control and inspection.

Production Patterns

Developers use {@debug} during development to quickly check reactive state changes without cluttering code. In production, they rely on error tracking tools and performance profilers, removing all {@debug} tags automatically.

Connections

Reactive Programming

Builds-on

Understanding {@debug} deepens your grasp of reactive programming by showing how variable changes trigger updates and side effects.

Browser Developer Tools

Complementary

{@debug} works alongside browser DevTools by providing automatic logs, while DevTools offer breakpoints and step-through debugging for complex issues.

Scientific Experiment Logging

Similar pattern

Just like scientists log measurements at key moments to understand experiments, {@debug} logs variable states at important update points to understand app behavior.

Common Pitfalls

#1 Expecting {@debug} to log expressions directly.

Wrong approach:

{@debug x + y}

Correct approach:

let sum = x + y;
{@debug sum}

Root cause:

Misunderstanding that {@debug} only accepts variable names, not arbitrary expressions.

#2 Leaving {@debug} tags in production code.

Wrong approach:

Using {@debug} in code deployed to production without removal.

Correct approach:

Use {@debug} only in development; production builds automatically remove these tags.

Root cause:

Not knowing that Svelte strips {@debug} in production, or forgetting to build properly.

#3 Using {@debug} inside functions or blocks expecting logs.

Wrong approach:

function test() { let a = 1; {@debug a} }

Correct approach:

Declare 'a' at component top-level and use {@debug a} there.

Root cause:

Not realizing {@debug} watches only top-level reactive variables, not local function variables.

Key Takeaways

The {@debug} tag in Svelte automatically logs variable values to the console when they change, simplifying debugging.

It only accepts variable names, not expressions, and works by integrating with Svelte's reactive update cycle.

{@debug} logs appear only during development and are removed in production builds, keeping live apps clean.

Using {@debug} helps you understand how your app's state changes over time without cluttering your code with manual logs.

For complex debugging needs, {@debug} complements but does not replace other tools like browser DevTools and Svelte DevTools.