Entendiendo el modelo mental de los Snippets

La evolución de los Slots a los Snippets

En Svelte 4, la composición de componentes dependía de los slots (<slot>), un patrón tomado de los Web Components. Si bien era funcional, los slots introdujeron varios puntos de dolor que afectaban tanto la experiencia del desarrollador como la mantenibilidad del código:

Las limitaciones de los Slots:

Problemas de flujo de datos unidireccional: Pasar datos del hijo al padre requería callbacks de props o bindings complejos
Sintaxis verbosa para slots nombrados: <svelte:fragment slot="header"> resultaba pesado para casos de uso simples
Detección de slots solo en tiempo de ejecución: El objeto $$slots solo estaba disponible en tiempo de ejecución, limitando la capacidad de TypeScript para detectar errores en tiempo de compilación
Sin reutilización: Los slots no podían extraerse y reutilizarse en diferentes componentes—estaban estrechamente acoplados a su componente
Flujo de datos poco claro: La naturaleza implícita del contenido de los slots dificultaba rastrear de dónde venía el contenido y qué datos estaban disponibles

La filosofía de los Snippets

Svelte 5 introduce los snippets — un cambio de paradigma que trata el marcado reutilizable como valores de primera clase. Esto no es solo azúcar sintáctico; es una reformulación fundamental de la composición de componentes basada en estos principios:

Qué hace diferentes a los Snippets:

Funciones, no agujeros: Los snippets son construcciones similares a funciones que se invocan explícitamente, no proyecciones de contenido implícitas
Lo explícito es mejor que lo implícito: El flujo de datos es visible—puedes ver exactamente qué datos entran y qué sale
Reutilizables y componibles: Los snippets pueden pasarse como props, almacenarse en variables y reutilizarse entre componentes como cualquier otro valor
Type-safe por defecto: TypeScript puede verificar las firmas de los snippets en tiempo de compilación, detectando errores antes del tiempo de ejecución
Control programático: Tú decides cuándo, dónde y cuántas veces se renderiza un snippet—control total sobre el ciclo de vida del renderizado

Este tutorial se enfoca en definir snippets: su sintaxis, parámetros, reglas de alcance y cómo exportarlos para su reutilización. Para patrones de renderizado y técnicas avanzadas de composición, consulta el artículo complementario sobre @render.

El concepto central: Marcado como valores

Piensa en un snippet como una función de plantilla. Así como defines una función de JavaScript para encapsular lógica, defines un snippet para encapsular estructura de marcado. La diferencia crítica respecto al marcado regular: definición ≠ ejecución.

Definir sin renderizar

Cuando escribes un snippet, estás creando una plantilla reutilizable, no agregando elementos al DOM de inmediato. Esto es análogo a cómo definir una función no la ejecuta:

{#snippet greeting()}
	<p>Hello, welcome to our application!</p>
{/snippet}

¿Qué está pasando aquí? Esto crea un snippet llamado greeting que, cuando se invoca, producirá un elemento párrafo. Pero nota: nada aparece en el DOM todavía. El snippet está definido pero no ejecutado—similar a cómo definir una función no ejecuta su código:

// JavaScript function - defined but not executed
function greet() {
	return 'Hello, welcome!'
}

// Svelte snippet - defined but not rendered
{#snippet greeting()}
	<p>Hello, welcome to our application!</p>
{/snippet}

Por qué esto importa: Esta separación te permite definir patrones de marcado una vez y reutilizarlos múltiples veces, condicionalmente o en diferentes contextos—sin duplicar la definición.

Renderizado explícito

Para realmente renderizar el contenido del snippet en el DOM, debes invocarlo explícitamente usando la directiva @render:

{#snippet greeting()}
	<p>Hello, welcome to our application!</p>
{/snippet}

<!-- NOW the paragraph appears in the DOM -->
{@render greeting()}

Por qué importa esta separación: Este modelo de renderizado explícito te da control preciso sobre:

Cuándo se renderiza el marcado (renderizado condicional basado en el estado)
Dónde aparece en el árbol de componentes (flexibilidad de disposición)
Cuántas veces se renderiza (iteración sin duplicación)
Qué datos recibe cada vez (parametrización)

La idea clave: Los snippets separan la definición (qué marcado crear) del renderizado (cuándo y dónde insertarlo en el DOM). Esta separación es lo que habilita los poderosos patrones de composición que explorarás a lo largo de esta guía.

Por qué importan los Snippets: La crisis de mantenibilidad

El costo de la duplicación de código

Cuando el mismo patrón de marcado aparece en múltiples lugares, enfrentas una crisis de mantenimiento: cada actualización requiere encontrar y cambiar cada ocurrencia. Si omites una, has introducido una inconsistencia. Esto no se trata solo de ahorrar pulsaciones de teclas—se trata de reducir la carga cognitiva y prevenir errores.

El principio DRY en acción

Considera este patrón común de Svelte 4 donde el mismo marcado aparece en diferentes contextos condicionales:

<!-- Svelte 4: Repetitive, error-prone -->
{#each images as image}
	{#if image.href}
		<a href={image.href}>
			<figure>
				<img src={image.src} alt={image.caption} width={image.width} height={image.height} />
				<figcaption>{image.caption}</figcaption>
			</figure>
		</a>
	{:else}
		<figure>
			<img src={image.src} alt={image.caption} width={image.width} height={image.height} />
			<figcaption>{image.caption}</figcaption>
		</figure>
	{/if}
{/each}

Los problemas con este enfoque:

Duplicación: El bloque <figure> aparece dos veces con estructura idéntica
Fragilidad: Cambiar la estructura de la imagen requiere actualizar ambas ramas
Propenso a errores: Es fácil actualizar una rama y olvidar la otra, causando inconsistencias visuales
Legibilidad: La lógica real (si envolver en un enlace) queda oscurecida por el marcado repetitivo
Escalabilidad: Agregar una tercera condición significa triplicar el marcado

Con snippets, la misma lógica se convierte en:

<!-- Svelte 5: DRY and maintainable -->
{#snippet figure(image)}
	<figure>
		<img src={image.src} alt={image.caption} width={image.width} height={image.height} />
		<figcaption>{image.caption}</figcaption>
	</figure>
{/snippet}

{#each images as image}
	{#if image.href}
		<a href={image.href}>
			{@render figure(image)}
		</a>
	{:else}
		{@render figure(image)}
	{/if}
{/each}

Qué mejoró:

Fuente única de verdad: La estructura del figure se define una sola vez al inicio
Propagación de cambios: Las actualizaciones al figure se aplican automáticamente en todos los lugares donde se renderiza
Intención clara: La lógica condicional ahora es sobre el envoltorio, no sobre recrear el marcado
Testabilidad: Puedes probar la estructura del figure independientemente de su contexto de uso
Escalabilidad: Agregar más condiciones solo agrega más llamadas {@render figure(image)}

Impacto en el mundo real

En una aplicación de producción con cientos de componentes, este patrón previene clases enteras de errores. Cuando necesitas agregar carga diferida a las imágenes, actualizar el formato del texto alternativo o cambiar el estilo del pie de foto, lo cambias una vez en lugar de buscarlo en múltiples archivos.

Parámetros de Snippet: Renderizado basado en datos

El poder de la parametrización

Los snippets sin parámetros son útiles, pero los snippets parametrizados desbloquean todo el poder del marcado reutilizable. Al aceptar parámetros, los snippets se convierten en plantillas adaptables que pueden renderizar diferentes datos manteniendo una estructura consistente.

Pasar datos al marcado

Piensa en los parámetros de un snippet como argumentos de función: definen qué datos necesita el snippet para hacer su trabajo. Esto crea un contrato claro entre la definición del snippet y su uso.

Parámetros básicos

Múltiples valores discretos

Usa múltiples parámetros cuando necesitas pasar piezas de datos distintas y no relacionadas:

{#snippet userCard(name, role, avatar)}
	<div class="user-card">
		<img src={avatar} alt="{name}'s avatar" />
		<h3>{name}</h3>
		<span class="role">{role}</span>
	</div>
{/snippet}

{@render userCard('Alice', 'Developer', '/avatars/alice.jpg')}
{@render userCard('Bob', 'Designer', '/avatars/bob.jpg')}

Por qué esto funciona bien:

Contrato claro: De inmediato ves que este snippet necesita tres piezas de datos
Type safety: TypeScript puede verificar que estás pasando el número y tipos correctos de argumentos
Flexibilidad: Cada llamada de renderizado puede proporcionar datos completamente diferentes

Cuándo usar este patrón:

Cuando los datos existen naturalmente como variables separadas
Cuando quieres ser explícito sobre qué datos son requeridos
Cuando el número de parámetros es pequeño (≤5 es una buena regla)

Valores predeterminados de parámetros

Mejora progresiva

Los parámetros pueden tener valores predeterminados, implementando un patrón de mejora progresiva donde los casos de uso más simples funcionan con código mínimo:

{#snippet badge(text, variant = 'default', size = 'medium')}
	<span class="badge badge-{variant} badge-{size}">
		{text}
	</span>
{/snippet}

{@render badge('New')}
<!-- Equivalent to: badge('New', 'default', 'medium') -->

{@render badge('Sale', 'danger')}
<!-- Equivalent to: badge('Sale', 'danger', 'medium') -->

{@render badge('Featured', 'success', 'large')}
<!-- All parameters explicit -->

Qué está pasando aquí:

Primera llamada: Solo se proporciona text; variant y size usan sus valores predeterminados
Segunda llamada: Se proporcionan text y variant; size usa su valor predeterminado
Tercera llamada: Todos los parámetros se proporcionan explícitamente

Cuándo usar valores predeterminados:

Cuando tienes un caso común que debería ser fácil (como el estilo predeterminado)
Cuando los parámetros representan mejoras progresivas en lugar de datos esenciales
Cuando quieres evolucionar tu API sin romper los usos existentes

Consejo de diseño: Ordena los parámetros de más a menos probable de ser personalizados. Esto permite a los usuarios proporcionar menos argumentos para los casos comunes.

Parámetros con Desestructuración

APIs Basadas en Objetos

Para estructuras de datos complejas o cuando tienes muchos parámetros relacionados, la desestructuración proporciona una sintaxis más limpia y fácil de mantener:

{#snippet productItem({ name, price, inStock, imageUrl })}
	<article class="product" class:out-of-stock={!inStock}>
		<img src={imageUrl} alt={name} />
		<h3>{name}</h3>
		<p class="price">${price.toFixed(2)}</p>
		{#if !inStock}
			<span class="badge">Out of Stock</span>
		{/if}
	</article>
{/snippet}

{#each products as product}
	{@render productItem(product)}
{/each}

Por qué la desestructuración brilla aquí:

Autodocumentada: La declaración del snippet muestra exactamente qué campos del producto utiliza
Flexible: Los objetos de producto pueden tener campos adicionales que el snippet ignora
Amigable para refactorización: Agregar nuevos campos al producto no rompe el snippet
Legible en el sitio de llamada: {@render productItem(product)} es más claro que {@render productItem(product.name, product.price, product.inStock, product.imageUrl)}

Cuándo usar desestructuración:

Cuando los datos existen naturalmente como un objeto (como elementos de un arreglo)
Cuando necesitas más de 3-4 parámetros
Cuando los parámetros forman una unidad cohesiva (propiedades de producto, datos de usuario, objeto de configuración)
Cuando quieres extraer solo campos específicos de un objeto más grande

Combinando desestructuración con valores por defecto:

{#snippet productCard({
	name,
	price,
	inStock = true,
	imageUrl = '/placeholder.jpg',
	rating = null
})}
	<article class="product-card">
		<img src={imageUrl} alt={name} />
		<h2>{name}</h2>
		<p class="price">${price}</p>

		{#if rating}
			<div class="rating">★ {rating}/5</div>
		{/if}

		{#if !inStock}
			<span class="badge">Out of Stock</span>
		{/if}
	</article>
{/snippet}

Esto combina la claridad de la desestructuración con la flexibilidad de los valores por defecto—los productos sin campos inStock, imageUrl o rating seguirán renderizándose correctamente.

Limitación Crítica

Sin Parámetros Rest

A diferencia de las funciones de JavaScript, los snippets no pueden usar parámetros rest (...rest) para capturar listas de argumentos de longitud variable:

<!-- AVOID: This will NOT work - compiler error -->
{#snippet example(first, ...others)}
	<p>First: {first}</p>
	<p>Others: {others.length} more items</p>
{/snippet}

<!-- PREFERRED Instead, pass an array explicitly -->
{#snippet example(first, others)}
	<p>First: {first}</p>
	<p>Others: {others.length} more items</p>
{/snippet}

{@render example('Alice', ['Bob', 'Charlie', 'Diana'])}

Por qué existe esta limitación: Svelte compila los snippets en funciones de renderizado optimizadas en tiempo de compilación. Los parámetros rest requerirían manipulación de argumentos en tiempo de ejecución, lo cual entra en conflicto con el modelo de optimización en tiempo de compilación de Svelte.

Soluciones alternativas cuando necesitas argumentos variables:

Pasar un arreglo: Pasa explícitamente una colección como un único parámetro
Desestructuración con campos conocidos: Usa desestructuración de objetos para campos conocidos
Múltiples snippets: Crea diferentes snippets para distintas aridades (aunque esto raramente es necesario en la práctica)

Alcance y Visibilidad de Snippets: Reglas de Alcance Léxico

Entendiendo el Alcance de los Snippets

Los snippets siguen las reglas de alcance léxico de JavaScript, lo que significa que su visibilidad está determinada por dónde están definidos en la estructura de tu componente, no por dónde se renderizan. Esto es tanto poderoso (habilitando closures sobre el estado del componente) como algo que necesitas entender para evitar confusiones.

Accediendo al Estado del Componente

Closure Reactivo sobre Variables del Script

Los snippets pueden acceder a variables del bloque <script> circundante, creando un closure reactivo. Cuando estas variables cambian, todas las instancias renderizadas del snippet se actualizan automáticamente:

<script>
	let { message = "it's great to see you!" } = $props()
	let currentTheme = $state('light')

	function toggleTheme() {
		currentTheme = currentTheme === 'light' ? 'dark' : 'light'
	}
</script>

{#snippet hello(name)}
	<p class="theme-{currentTheme}">
		Hello {name}! {message}
	</p>
{/snippet}

{@render hello('Alice')}
{@render hello('Bob')}

<button onclick={toggleTheme}>Toggle Theme</button>

Lo que está sucediendo aquí:

El snippet hello "cierra sobre" currentTheme y message del alcance padre
Cuando currentTheme cambia (mediante el clic del botón), ambos snippets renderizados se actualizan automáticamente
Cada llamada a @render ve el valor actual de currentTheme—esta es la reactividad de grano fino de Svelte en acción

Por qué esto importa:

Fuente única de verdad: El estado del tema vive en un solo lugar pero afecta todos los renders del snippet
Sin prop drilling: Los snippets pueden acceder al estado del componente sin necesidad de pasarlo como parámetros
Actualizaciones automáticas: La reactividad funciona a través del límite del snippet—no se necesitan suscripciones manuales

Cuándo usar closure vs parámetros:

Usa closure para el estado global del componente (tema, sesión de usuario, feature flags)
Usa parámetros para datos que varían por render (elementos de lista, IDs, contenido específico)

Accediendo a Variables de Bucle: Closures por Iteración

Los snippets definidos dentro de bucles pueden acceder a las variables de iteración del bucle, creando un closure separado para cada iteración:

{#each categories as category, categoryIndex}
	{#snippet categoryHeader()}
		<h2>
			Category #{categoryIndex + 1}: {category.name}
			<span class="count">({category.items.length} items)</span>
		</h2>
	{/snippet}

	<section>
		{@render categoryHeader()}
		{#each category.items as item}
			<p>{item}</p>
		{/each}

		<!-- Can render the header again with the same category -->
		{@render categoryHeader()}
	</section>
{/each}

Lo que hace que esto funcione:

Cada iteración crea un nuevo snippet categoryHeader con su propio closure
El snippet de la primera iteración cierra sobre category[0] y categoryIndex = 0
El snippet de la segunda iteración cierra sobre category[1] y categoryIndex = 1
Cada snippet es independiente—cambiar uno no afecta a los demás

Casos de uso prácticos:

Encabezados/pies repetidos: Renderiza el mismo contenido en la parte superior e inferior de una sección
Renderizado condicional: Muestra u oculta elementos repetidos según los datos de la iteración
Formato consistente: Aplica el mismo estilo a diferentes partes de un elemento

Reglas de Visibilidad: Alcance Léxico en Práctica

Los snippets siguen un patrón de visibilidad predecible basado en la estructura del DOM. Entender estas reglas previene errores de "snippet no definido" y te ayuda a estructurar tus componentes de manera efectiva.

Qué Puede Ver tu Snippet

Los snippets son visibles para:

Ellos mismos (habilitando recursión para estructuras de árbol)
Elementos hermanos en el mismo nivel de anidación
Hijos de esos hermanos (descendientes en el árbol del DOM)

Qué No Puede Ver tu Snippet

NO son visibles para:

Elementos padre (alcances externos/contenedores)
Elementos en diferentes ramas del árbol del DOM
Otros snippets en el mismo nivel (a menos que los pases como parámetros)

Ejemplo Visual de Alcance

<div class="outer">
	{#snippet outer()}
		<p>I'm the outer snippet</p>

		{#snippet inner()}
			<span>I'm nested inside outer</span>
		{/snippet}

		<!-- PREFERRED: WORKS - inner is visible here (sibling + child scope) -->
		{@render inner()}
	{/snippet}

	<!-- PREFERRED: WORKS - outer is visible here (same level scope) -->
	{@render outer()}

	<!-- AVOID: ERROR - inner is not visible here (parent can't see child's snippet) -->
	{@render inner()}
</div>

<!-- AVOID: ERROR - outer is not visible here (outside the div) -->
{@render outer()}

Por qué existen estas reglas:

Prevenir colisiones de nombres: Diferentes ramas pueden tener snippets con el mismo nombre
Modelo mental claro: La visibilidad sigue la estructura del árbol del DOM
Encapsulación: Los detalles de implementación internos (snippets anidados) no se filtran a los alcances externos

Implicaciones Prácticas

1. Snippets de Nivel Superior para Reutilización Global

Cuando un snippet se necesita en múltiples lugares de un componente, defínelo en el nivel superior:

<!-- Available everywhere in this component -->
{#snippet formatPrice(amount)}
	<span class="price">${amount.toFixed(2)}</span>
{/snippet}

<div class="products">
	{#each products as product}
		<div class="product">
			{@render formatPrice(product.price)}
		</div>
	{/each}
</div>

<div class="cart">
	<p>Total: {@render formatPrice(cartTotal)}</p>
</div>

2. Snippets con Alcance para Lógica Localizada

Cuando un snippet solo es relevante dentro de un condicional o bucle específico, defínelo allí para mantener el espacio de nombres limpio:

{#if showUserProfile}
	{#snippet profileField(label, value)}
		<div class="field">
			<span class="label">{label}:</span>
			<span class="value">{value}</span>
		</div>
	{/snippet}

	<div class="user-profile">
		{@render profileField('Name', user.name)}
		{@render profileField('Email', user.email)}
		{@render profileField('Role', user.role)}
	</div>
{/if}

<!-- profileField is not accessible here - keeps the namespace clean -->

3. Evitando Problemas de Alcance

Cuando un snippet necesita ser utilizado en múltiples ramas de un condicional, defínelo en un nivel ancestro común:

<!-- PREFERRED Define at common ancestor level -->
{#snippet statusBadge(status)}
	<span class="badge badge-{status}">{status}</span>
{/snippet}

{#if condition}
	<div>{@render statusBadge('active')}</div>
{:else}
	<div>{@render statusBadge('inactive')}</div>
{/if}

No así:

<!-- AVOID: Don't define in one branch and try to use in another -->
{#if condition}
	{#snippet statusBadge(status)}
		<span class="badge badge-{status}">{status}</span>
	{/snippet}
	<div>{@render statusBadge('active')}</div>
{:else}
	<!-- ERROR: statusBadge is not defined here -->
	<div>{@render statusBadge('inactive')}</div>
{/if}

Snippets Recursivos

La recursión es una técnica poderosa para renderizar estructuras de datos jerárquicas de profundidad desconocida. Los snippets de Svelte soportan la recursión, permitiéndote definir snippets que se llaman a sí mismos o entre sí para manejar datos anidados de manera elegante.

Cuándo Tiene Sentido la Recursión

La recursión en snippets resuelve un problema específico: renderizar datos de profundidad desconocida. Cuando tienes estructuras de árbol, comentarios anidados, sistemas de archivos o cualquier dato jerárquico donde no sabes cuántos niveles de profundidad tiene, los snippets recursivos son tu solución.

Casos de uso comunes:

Árboles de archivos/carpetas (profundidad desconocida hasta el tiempo de ejecución)
Hilos de comentarios con respuestas anidadas
Organigramas
Jerarquías de categorías (p. ej., categorías de e-commerce)
Visualizadores de árboles JSON/XML
Sistemas de menús con anidamiento ilimitado

Entendiendo la Recursión en Snippets

Patrones de Auto-referencia

Los snippets pueden referenciarse a sí mismos, al igual que las funciones de JavaScript. La clave está en entender el caso base (cuándo detenerse) y el caso recursivo (cuándo continuar).

Recursión Básica: Ejemplo de Cuenta Regresiva

{#snippet countdown(n)}
	{#if n > 0}
		<!-- Recursive case: continue counting -->
		<span>{n}...</span>
		{@render countdown(n - 1)}
	{:else}
		<!-- Base case: stop recursion -->
		<span>🚀 Liftoff!</span>
	{/if}
{/snippet}

{@render countdown(5)}
<!-- Renders: 5... 4... 3... 2... 1... 🚀 Liftoff! -->

Cómo funciona:

Llamada inicial: countdown(5) renderiza "5..." y luego llama a countdown(4)
Segunda llamada: countdown(4) renderiza "4..." y luego llama a countdown(3)
Continúa: Cada llamada renderiza su número y hace una llamada más pequeña
Caso base: Cuando n llega a 0, renderiza "🚀 Liftoff!" y se detiene

Concepto crítico: El caso base previene los bucles infinitos. Sin {#if n > 0}, el snippet se llamaría a sí mismo indefinidamente, causando eventualmente un desbordamiento de pila.

Snippets Mutuamente Recursivos

Los snippets también pueden llamarse entre sí en un patrón mutuamente recursivo:

{#snippet blastoff()}
	<span class="rocket">🚀</span>
{/snippet}

{#snippet countdown(n)}
	{#if n > 0}
		<span class="number">{n}...</span>
		{@render countdown(n - 1)}
	{:else}
		{@render blastoff()}
	{/if}
{/snippet}

{@render countdown(10)}

Qué es diferente aquí:

countdown no contiene directamente el emoji del cohete
En cambio, delega a blastoff cuando termina
Esto separa responsabilidades: lógica de conteo vs visualización final

Cuándo usar recursión mutua:

Cuando diferentes estados requieren lógica de renderizado diferente
Para mantener cada snippet enfocado y con un único propósito
Cuando quieres reutilizar sub-snippets de forma independiente

Ejemplo Práctico:

Estructura de Árbol de Archivos

Los sistemas de archivos son el ejemplo canónico de datos recursivos: las carpetas contienen archivos y otras carpetas, que contienen archivos y carpetas, ad infinitum.

Estructura de Datos de Ejemplo

<script>
	let fileTree = $state({
		name: 'project',
		type: 'folder',
		children: [
			{
				name: 'src',
				type: 'folder',
				children: [
					{
						name: 'components',
						type: 'folder',
						children: [
							{ name: 'Button.svelte', type: 'file' },
							{ name: 'Card.svelte', type: 'file' }
						]
					},
					{ name: 'App.svelte', type: 'file' },
					{ name: 'main.js', type: 'file' }
				]
			},
			{ name: 'package.json', type: 'file' },
			{ name: 'README.md', type: 'file' }
		]
	})
</script>

Uso: El Renderizador Recursivo

{#snippet treeNode(node, depth = 0)}
	<div class="tree-node" style="padding-left: {depth * 20}px">
		{#if node.type === 'folder'}
			<!-- Folder case: show icon, name, then recursively show children -->
			<span class="folder"> {node.name}</span>

			{#if node.children}
				{#each node.children as child}
					<!-- RECURSION: render each child as a treeNode -->
					{@render treeNode(child, depth + 1)}
				{/each}
			{/if}
		{:else}
			<!-- Base case: files don't have children, stop recursing -->
			<span class="file">{node.name}</span>
		{/if}
	</div>
{/snippet}

{@render treeNode(fileTree)}

Cómo fluye la recursión:

Inicio: Renderiza treeNode(fileTree, 0) → "project" en profundidad 0
Primer nivel: Itera sobre los hijos de project
- Renderiza treeNode(src, 1) → - src en profundidad 1
- Renderiza treeNode(package.json, 1) → - package.json (se detiene, es un archivo)
- Renderiza treeNode(README.md, 1) → - README.md (se detiene, es un archivo)
Segundo nivel: Al renderizar src, itera sobre sus hijos
- Renderiza treeNode(components, 2) → - components en profundidad 2
- Renderiza treeNode(App.svelte, 2) → - App.svelte (se detiene)
- Renderiza treeNode(main.js, 2) → - main.js (se detiene)
Tercer nivel: Al renderizar components, itera sobre sus hijos
- Renderiza treeNode(Button.svelte, 3) → - Button.svelte (se detiene)
- Renderiza treeNode(Card.svelte, 3) → - Card.svelte (se detiene)

Características clave de este patrón:

Seguimiento de profundidad: El parámetro depth crea la sangría adecuada
Terminación automática: Los archivos (sin hijos) terminan la recursión de forma natural
Profundidad desconocida: Funciona para cualquier número de niveles de anidamiento
Renderizado uniforme: Cada nodo se renderiza de forma consistente sin importar la profundidad

Avanzado

Vamos a mejorar el árbol de archivos con funcionalidad de expandir/contraer:

Árbol Interactivo Colapsable

<script>
	let expandedFolders = $state(new Set(['project', 'src']))

	function toggleFolder(folderName) {
		if (expandedFolders.has(folderName)) {
			expandedFolders.delete(folderName)
		} else {
			expandedFolders.add(folderName)
		}
		expandedFolders = expandedFolders // Trigger reactivity
	}

	let fileTree = $state({
		name: 'project',
		type: 'folder',
		children: [
			/* ... same as above ... */
		]
	})
</script>

{#snippet treeNode(node, depth = 0)}
	<div class="tree-node" style="padding-left: {depth * 20}px">
		{#if node.type === 'folder'}
			<button class="folder-toggle" onclick={() => toggleFolder(node.name)}>
				{expandedFolders.has(node.name) ? 'expanded' : 'collapsed'}
				{node.name}
			</button>

			{#if expandedFolders.has(node.name) && node.children}
				{#each node.children as child}
					{@render treeNode(child, depth + 1)}
				{/each}
			{/if}
		{:else}
			<span class="file">{node.name}</span>
		{/if}
	</div>
{/snippet}

{@render treeNode(fileTree)}

Qué cambió:

Seguimiento de estado: El Set expandedFolders rastrea qué carpetas están abiertas
Función de alternancia: El manejador de clic agrega/elimina carpetas del Set
Renderizado condicional: Solo muestra los hijos si la carpeta está expandida
Variación de ícono: Muestra un emoji diferente para el estado expandido/contraído

Por qué esto es poderoso:

La recursión maneja anidamiento arbitrariamente profundo
La gestión de estado es plana (Set de nombres de carpetas), no anidada
Cada nodo puede expandirse/contraerse de forma independiente
Agregar nuevos archivos/carpetas no requiere ningún cambio en el código

Buenas Prácticas de Recursión

1. Siempre Ten un Caso Base

<!-- AVOID: DANGEROUS - No base case, infinite recursion -->
{#snippet infinite(n)}
	<p>{n}</p>
	{@render infinite(n + 1)}
{/snippet}

<!-- PREFERRED SAFE: Clear base case stops recursion -->
{#snippet safe(n)}
	{#if n > 0}
		<p>{n}</p>
		{@render safe(n - 1)}
	{/if}
{/snippet}

2. Controla la Profundidad para Prevenir Desbordamiento de Pila

Para datos provistos por el usuario, agrega una profundidad máxima:

{#snippet treeNode(node, depth = 0, maxDepth = 20)}
	{#if depth >= maxDepth}
		<span class="truncated">... (max depth reached)</span>
	{:else if node.type === 'folder'}
		<!-- normal folder rendering -->
		{#each node.children as child}
			{@render treeNode(child, depth + 1, maxDepth)}
		{/each}
	{:else}
		<!-- file rendering -->
	{/if}
{/snippet}

3. Considera el Rendimiento para Árboles Grandes

Para árboles muy grandes (miles de nodos), considera:

Virtualización: Solo renderiza los nodos visibles
Carga diferida: Obtén los hijos bajo demanda
Paginación: Limita los hijos mostrados por nivel

Pasar Snippets a Componentes: Inversión de Control

El Poder de la Delegación de Renderizado

Pasar snippets a componentes implementa la inversión de control: en lugar de que el componente dicte exactamente cómo luce el contenido, delega las decisiones de renderizado de vuelta al padre. Esto crea componentes flexibles y reutilizables que se adaptan a diferentes casos de uso sin modificaciones.

El problema tradicional:

<!-- Rigid: Table component controls ALL rendering -->
<Table data={fruits} />

El componente Table tiene codificada la forma en que lucen los encabezados y las filas. ¿Quieres estilos personalizados? Estás atascado. ¿Necesitas agregar una columna? Modifica el componente.

La solución con snippets:

<!-- Flexible: Parent controls rendering, Table provides structure -->
<Table data={fruits} {header} {row} />

La Table provee la estructura (table, bucles, diseño) mientras el padre provee el contenido (encabezados, formato de celdas). Esta separación de responsabilidades es poderosa. Aquí hay dos formas principales de pasar snippets como props.

1. Props de Snippet Explícitas

Define snippets en el padre y pásalos como props explícitas al componente hijo:

<!-- Parent: +page.svelte -->
<script>
	import Table from './Table.svelte'
	const fruits = [
		{ name: 'apples', qty: 5, price: 2, organic: true },
		{ name: 'bananas', qty: 10, price: 1, organic: false }
	]
</script>

{#snippet header()}
	<th>Fruit</th>
	<th>Quantity</th>
	<th>Price</th>
	<th>Organic</th>
{/snippet}

{#snippet row(item)}
	<td>{item.name}</td>
	<td>{item.qty}</td>
	<td>${item.price.toFixed(2)}</td>
	<td>{item.organic ? '✓' : '✗'}</td>
{/snippet}

<!-- Pass snippets as props, just like data -->
<Table data={fruits} {header} {row} />

<!-- Child: Table.svelte -->
<script>
	let { data, header, row } = $props()
</script>

<table>
	<thead>
		<tr>{@render header()}</tr>
	</thead>
	<tbody>
		{#each data as item}
			<tr>{@render row(item)}</tr>
		{/each}
	</tbody>
</table>

Qué está sucediendo aquí:

El padre controla el contenido: El padre define exactamente qué contienen los encabezados y las celdas de las filas
El hijo controla la estructura: El hijo maneja el contenedor de la tabla, thead/tbody e iteración
Interfaz clara: La API de props de Table (data, header, row) documenta lo que necesita
Componente reutilizable: La misma Table puede renderizar productos, usuarios, pedidos—cualquier cosa

Cuándo usar props explícitas:

Cuando los snippets se definen separados de su uso
Cuando quieres reutilizar snippets en múltiples componentes
Cuando la relación entre snippets y componente debe ser explícita
Para componentes complejos donde documentar la API es importante

2. Props de Snippet Implícitas

Los snippets definidos directamente dentro de las etiquetas de un componente se convierten automáticamente en props de ese componente:

<Table data={fruits}>
	{#snippet header()}
		<th>Fruit</th>
		<th>Quantity</th>
		<th>Price</th>
		<th>Organic</th>
	{/snippet}

	{#snippet row(item)}
		<td>{item.name}</td>
		<td>{item.qty}</td>
		<td>${item.price.toFixed(2)}</td>
		<td>{item.organic ? '✓' : '✗'}</td>
	{/snippet}
</Table>

Esto es semánticamente idéntico a la versión explícita. El compilador lo transforma en:

<!-- Compiler transformation (conceptual) -->
{#snippet header()}...{/snippet}
{#snippet row(item)}...{/snippet}
<Table data={fruits} {header} {row} />

Cuándo usar props implícitos:

Cuando los snippets solo se usan con esta instancia de componente específica
Para una sintaxis más limpia y declarativa que muestra el contenido junto al componente
Cuando la relación padre-hijo es obvia por el contexto
Para componentes que siguen el patrón "el componente envuelve el contenido"

Elegir entre explícito e implícito:

<!-- PREFERRED Explicit: When reusing snippets -->
{#snippet userRow(user)}
	<td>{user.name}</td>
	<td>{user.email}</td>
{/snippet}

<Table data={activeUsers} row={userRow} />
<Table data={inactiveUsers} row={userRow} />

<!-- PREFERRED Implicit: When snippets are specific to this instance -->
<UserTable data={users}>
	{#snippet row(user)}
		<td>{user.name}</td>
		<td>{user.email}</td>
		<td><button>Edit</button></td>
	{/snippet}
</UserTable>

El Snippet Implícito `children`

Cada componente puede aceptar una prop de snippet especial llamada children, que representa el slot de contenido por defecto. Esto te permite pasar contenido arbitrario a un componente sin nombrar el snippet explícitamente.

Componente Button

<!-- Button.svelte -->
<script>
	// children is now a snippet prop, just like any other
	let { children } = $props()
</script>

<button>
	{@render children()}
</button>

Cuando colocas cualquier contenido dentro de las etiquetas de un componente (sin un snippet con nombre), ese contenido se convierte automáticamente en el snippet children.

<!-- Parent usage -->
<Button>Click me!</Button>

Lo que hace el compilador conceptualmente:

{#snippet children()}
	Click me!
{/snippet}

<Button {children} />

Por qué children es especial:

Slot de contenido por defecto: Cada componente puede aceptar contenido sin nombrarlo
Mejora progresiva: Los componentes simples funcionan sin nombres de snippet explícitos
Patrón familiar: Refleja cómo los elementos HTML aceptan contenido
Compatible con versiones anteriores: Similar a cómo funcionaban los slots, facilitando la migración

Combinar Snippets con Nombre y Children

Puedes combinar children con snippets con nombre para diseños complejos:

<!-- Parent -->
<Card>
	{#snippet header()}
		<h2>Product Details</h2>
	{/snippet}

	{#snippet footer()}
		<button>Buy Now</button>
	{/snippet}

	<!-- This content becomes the children snippet -->
	<p>Amazing product description...</p>
	<ul>
		<li>Feature 1</li>
		<li>Feature 2</li>
	</ul>
</Card>

<!-- Card.svelte -->
<script>
	let { children, header, footer } = $props()
</script>

<article class="card">
	{#if header}
		<div class="card-header">
			{@render header()}
		</div>
	{/if}

	<div class="card-body">
		{@render children()}
	</div>

	{#if footer}
		<div class="card-footer">
			{@render footer()}
		</div>
	{/if}
</article>

El resultado:

<article class="card">
	<div class="card-header">
		<h2>Product Details</h2>
	</div>

	<div class="card-body">
		<p>Amazing product description...</p>
		<ul>
			<li>Feature 1</li>
			<li>Feature 2</li>
		</ul>
	</div>

	<div class="card-footer">
		<button>Buy Now</button>
	</div>
</article>

Patrones de Diseño de API de Componentes

1. Snippets Requeridos vs Opcionales

Diseña APIs de componentes que comuniquen claramente qué es requerido:

<!-- Table.svelte -->
<script>
	// row is required, header/footer are optional
	let { data, row, header, footer } = $props()
</script>

<table>
	{#if header}
		<thead><tr>{@render header()}</tr></thead>
	{/if}

	<tbody>
		{#each data as item}
			<tr>{@render row(item)}</tr>
		{/each}
	</tbody>

	{#if footer}
		<tfoot><tr>{@render footer()}</tr></tfoot>
	{/if}
</table>

Uso:

<!-- Minimal: just required snippets -->
<Table data={items}>
	{#snippet row(item)}
		<td>{item.name}</td>
	{/snippet}
</Table>

<!-- Full: all optional snippets provided -->
<Table data={items}>
	{#snippet header()}
		<th>Name</th>
	{/snippet}
	{#snippet row(item)}
		<td>{item.name}</td>
	{/snippet}
	{#snippet footer()}
		<th>Total: {items.length}</th>
	{/snippet}
</Table>

2. Parámetros de Snippet para Contexto

Pasa datos contextuales a los snippets para que puedan tomar decisiones de renderizado informadas:

<!-- List.svelte -->
<script>
	let { items, item } = $props()
</script>

<ul>
	{#each items as currentItem, index}
		<li>
			{@render item(currentItem, {
				index,
				isFirst: index === 0,
				isLast: index === items.length - 1
			})}
		</li>
	{/each}
</ul>

Uso:

<List items={products}>
	{#snippet item(product, { index, isFirst, isLast })}
		<div class:featured={isFirst}>
			{index + 1}. {product.name}
			{#if isLast}
				<span class="badge">Last item!</span>
			{/if}
		</div>
	{/snippet}
</List>

Por qué pasar contexto:

Los snippets pueden acceder a información de posición (primero, último, índice)
El padre no necesita calcular estos datos
El componente encapsula la lógica de iteración
Los snippets se mantienen enfocados en el renderizado

Para patrones de renderizado más avanzados, manejo opcional de snippets y selección dinámica de snippets, consulta el artículo complementario sobre {@render ...}.

Integración con TypeScript: APIs de Componentes con Tipos Seguros

¿Por qué tipar los Snippets?

En JavaScript, los snippets son flexibles pero propensos a errores—puedes pasar el número incorrecto de argumentos, tipos incorrectos u olvidar snippets requeridos por completo. TypeScript transforma los snippets de suposiciones en tiempo de ejecución a garantías en tiempo de compilación.

Beneficios de tipar snippets:

Autocompletado en el IDE: Ve qué snippets espera un componente y qué parámetros necesitan
Errores en tiempo de compilación: Detecta snippets faltantes o parámetros incorrectos antes de ejecutar el código
Seguridad al refactorizar: Renombra parámetros o cambia tipos con confianza
APIs autodocumentadas: Los tipos sirven como documentación siempre actualizada

El Tipo `Snippet`

Svelte 5 proporciona el tipo Snippet del paquete 'svelte'. Este tipo representa un snippet con tipos de parámetros opcionales.

Tipado Básico de Snippets

Para snippets sin parámetros, usa Snippet directamente:

<script lang="ts">
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet // Required snippet, no parameters
		title: string
	}

	let { children, title }: Props = $props()
</script>

<div class="container">
	<h1>{title}</h1>
	{@render children()}
</div>

Lo que esto logra:

Verificación de requerido: TypeScript da error si el padre no proporciona children
Sin parámetros forzados: TypeScript da error si llamas children(someArg)
Contrato claro: Cualquiera que use este componente sabe que debe proporcionar un snippet children

Tipar Snippets con Parámetros

Los parámetros de snippets se tipan como una tupla (lista ordenada de tipos):

<script lang="ts">
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet // No parameters
		row: Snippet<[string]> // One parameter: string
		cell: Snippet<[string, number]> // Two parameters: string, number
	}

	let { children, row, cell }: Props = $props()
</script>

<div>
	{@render children()}
	{@render row('Alice')}
	{@render cell('Name', 42)}
</div>

Seguridad de tipos en acción:

<!-- PREFERRED Correct usage -->
<MyComponent>
	{#snippet children()}
		<p>Default content</p>
	{/snippet}

	{#snippet row(name)}
		<div>{name}</div>
	{/snippet}

	{#snippet cell(label, value)}
		<span>{label}: {value}</span>
	{/snippet}
</MyComponent>

<!-- AVOID: TypeScript errors -->
<MyComponent>
	<!-- Error: row requires one parameter -->
	{#snippet row()}
		<div>Missing parameter!</div>
	{/snippet}

	<!-- Error: cell requires two parameters -->
	{#snippet cell(label)}
		<span>{label}</span>
	{/snippet}
</MyComponent>

¿Por qué tuplas? Las tuplas preservan el orden de los parámetros y los tipos individuales, a diferencia de los arrays que tienen un único tipo de elemento.

Avanzado: Snippets Genéricos para Seguridad de Tipos

Los genéricos aseguran la consistencia de tipos entre los datos y los snippets que renderizan esos datos. Esto previene errores sutiles donde la forma de los datos no coincide con lo que el snippet espera.

Ejemplo de Tabla Genérica

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		data: T[] // Array of generic type T
		row: Snippet<[T]> // Snippet receives items of type T
	}

	let { data, row }: Props = $props()
</script>

<table>
	<tbody>
		{#each data as item}
			<tr>{@render row(item)}</tr>
		{/each}
	</tbody>
</table>

Cómo funciona esto:

<!-- Usage with Product[] -->
<script lang="ts">
	interface Product {
		name: string
		price: number
		inStock: boolean
	}

	const products: Product[] = [{ name: 'Apple', price: 1.99, inStock: true }]
</script>

<!-- TypeScript infers T = Product -->
<Table data={products}>
	{#snippet row(product)}
		<!-- TypeScript knows 'product' is type Product -->
		<td>{product.name}</td>
		<td>${product.price.toFixed(2)}</td>
		<td>{product.inStock ? '✓' : '✗'}</td>
	{/snippet}
</Table>

Lo que TypeScript garantiza:

data es un Product[]
row recibe un parámetro Product
Si intentas acceder a product.unknownField, TypeScript genera un error
Si cambias products a un tipo diferente, el snippet debe coincidir

Genérico con múltiples snippets:

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		data: T[]
		header: Snippet
		row: Snippet<[T, number]> // Item + index
		footer?: Snippet<[number]> // Optional, receives total count
	}

	let { data, header, row, footer }: Props = $props()
</script>

<table>
	<thead><tr>{@render header()}</tr></thead>
	<tbody>
		{#each data as item, index}
			<tr>{@render row(item, index)}</tr>
		{/each}
	</tbody>
	{#if footer}
		<tfoot><tr>{@render footer(data.length)}</tr></tfoot>
	{/if}
</table>

Genérico con Restricciones

A veces necesitas asegurarte de que el tipo genérico tenga propiedades específicas:

<script lang="ts" generics="T extends { id: string | number }">
	import type { Snippet } from 'svelte'

	interface Props {
		items: T[]
		item: Snippet<[T]>
		onDelete?: (id: T['id']) => void
	}

	let { items, item, onDelete }: Props = $props()
</script>

<ul>
	{#each items as currentItem}
		<li>
			{@render item(currentItem)}
			{#if onDelete}
				<button onclick={() => onDelete(currentItem.id)}>Delete</button>
			{/if}
		</li>
	{/each}
</ul>

La restricción extends { id: string | number } garantiza:

Cada elemento en items debe tener una propiedad id
El id debe ser una cadena de texto o un número
TypeScript genera errores en tiempo de compilación si pasas elementos sin id

Props de Snippets Opcionales

Marca los snippets como opcionales usando el operador ? de TypeScript:

<script lang="ts">
	import type { Snippet } from 'svelte'

	interface Props {
		children: Snippet // Required
		header?: Snippet // Optional, no params
		footer?: Snippet<[string]> // Optional, with param
		row?: Snippet<[number, string]> // Optional, multiple params
	}

	let { children, header, footer, row }: Props = $props()
</script>

<div class="card">
	{#if header}
		<div class="header">{@render header()}</div>
	{/if}

	<div class="body">{@render children()}</div>

	{#if footer}
		<div class="footer">{@render footer('Default footer text')}</div>
	{/if}
</div>

Uso en el componente padre:

<!-- PREFERRED Valid: Only required snippets provided -->
<Card>
	{#snippet children()}
		<p>Main content</p>
	{/snippet}
</Card>

<!-- PREFERRED Valid: Optional snippets added -->
<Card>
	{#snippet header()}
		<h2>Title</h2>
	{/snippet}

	{#snippet children()}
		<p>Main content</p>
	{/snippet}

	{#snippet footer(text)}
		<p>{text}</p>
	{/snippet}
</Card>

<!-- AVOID: Error - Missing required 'children' snippet -->
<Card>
	{#snippet header()}
		<h2>Title</h2>
	{/snippet}
</Card>

Patrones de Tipado para Casos de Uso Comunes

Patrón 1: Datos + Snippet de Renderizado

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		data: T[]
		render: Snippet<[T]>
	}

	let { data, render }: Props = $props()
</script>

{#each data as item}
	{@render render(item)}
{/each}

Patrón 2: Children Opcionales con Fallback

<script lang="ts">
	import type { Snippet } from 'svelte'

	interface Props {
		children?: Snippet
	}

	let { children }: Props = $props()
</script>

{#if children}
	{@render children()}
{:else}
	<p>Default fallback content</p>
{/if}

Patrón 3: Múltiples Snippets Relacionados

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		items: T[]
		itemHeader?: Snippet<[T]>
		itemBody: Snippet<[T]>
		itemFooter?: Snippet<[T]>
	}

	let { items, itemHeader, itemBody, itemFooter }: Props = $props()
</script>

{#each items as item}
	<article>
		{#if itemHeader}
			<header>{@render itemHeader(item)}</header>
		{/if}
		<main>{@render itemBody(item)}</main>
		{#if itemFooter}
			<footer>{@render itemFooter(item)}</footer>
		{/if}
	</article>
{/each}

Buenas Prácticas de Seguridad de Tipos

Siempre tipifica las APIs públicas de los componentes: Incluso si tu proyecto no aplica tipado estricto en todas partes, tipifica las props de los componentes que otros desarrolladores vayan a usar
Usa genéricos para componentes basados en datos: Cuando los componentes iteran sobre datos y los pasan a snippets, usa genéricos para mantener la seguridad de tipos
Sé explícito con los snippets opcionales: Usa ? para los opcionales y omítelo para los requeridos—esto hace que el contrato de la API sea claro
Documenta la semántica de los parámetros: Usa comentarios JSDoc para explicar qué representan los parámetros de los snippets:

<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		data: T[]
		/**
		 * Renders a single row.
		 * @param item - The data item for this row
		 * @param index - Zero-based row index
		 * @param isSelected - Whether this row is currently selected
		 */
		row: Snippet<[item: T, index: number, isSelected: boolean]>
	}
</script>

Exportar Snippets

Los snippets no están limitados al componente donde se definen. Svelte 5 te permite exportar snippets para que puedan reutilizarse en toda tu aplicación o incluso publicarse como parte de una biblioteca de plantillas.

Construyendo Bibliotecas de Plantillas Reutilizables

Al exportar snippets, puedes crear bibliotecas de plantillas de interfaz de usuario reutilizables, helpers de formateo o primitivas de diseño. Estas bibliotecas pueden compartirse en todo tu proyecto o incluso publicarse para que otros las usen, haciendo tu código más modular y fácil de mantener. Este enfoque es ideal para sistemas de diseño, patrones de interfaz de usuario compartidos, o cualquier situación en la que quieras estandarizar el marcado y la lógica.

El Problema: Localidad de los Snippets

Por defecto, los snippets tienen alcance de componente — solo existen dentro del componente donde están definidos. Esto funciona muy bien para patrones de marcado locales al componente, pero ¿qué pasa con la lógica de formateo que necesitas en muchos componentes?

Antes de Svelte 5.5.0, tenías dos opciones poco satisfactorias:

Duplicar el snippet en cada componente que lo necesite (violación del principio DRY)
Crear un componente auxiliar (solución pesada para marcado simple)

A partir de Svelte 5.5.0, puedes exportar snippets desde scripts de módulo, haciéndolos importables como cualquier otro valor de módulo.

Definiendo Snippets Exportables

Para exportar snippets, defínelos en un bloque <script module> y usa una declaración export que liste los nombres de los snippets.

<!-- Snippets.svelte -->
<script module>
	// List snippet names to export
	export { formattedPrice, stockBadge, userAvatar }
</script>

{#snippet formattedPrice(amount, currency = 'USD')}
	<span class="price">
		{new Intl.NumberFormat('en-US', {
			style: 'currency',
			currency
		}).format(amount)}
	</span>
{/snippet}

{#snippet stockBadge(quantity)}
	{#if quantity === 0}
		<span class="badge badge-danger">Out of Stock</span>
	{:else if quantity < 10}
		<span class="badge badge-warning">Low Stock ({quantity})</span>
	{:else}
		<span class="badge badge-success">In Stock</span>
	{/if}
{/snippet}

{#snippet userAvatar(url, name, size = 'medium')}
	<img src={url} alt="{name}'s avatar" class="avatar avatar-{size}" />
{/snippet}

Requisitos clave:

Los snippets deben ser de nivel superior (no anidados dentro de {#if}, {#each}, etc.)
La declaración export debe estar en un bloque <script module>
Solo exportas los nombres de los snippets, no sus definiciones completas

Importando y Usando Snippets Exportados

Los snippets exportados pueden importarse en cualquier componente usando la sintaxis estándar de módulos ES:

<!-- ProductCard.svelte -->
<script>
	import { formattedPrice, stockBadge } from './Snippets.svelte'

	let { product } = $props()
</script>

<article class="product-card">
	<h3>{product.name}</h3>

	<div class="pricing">
		{@render formattedPrice(product.price)}
		{#if product.salePrice}
			<del>{@render formattedPrice(product.originalPrice)}</del>
		{/if}
	</div>

	<div class="stock">
		{@render stockBadge(product.stockQuantity)}
	</div>
</article>

Lo que esto logra:

Consistencia: El formato de precios se ve idéntico en toda la aplicación
Mantenibilidad: Actualiza formattedPrice una vez y los cambios se propagan a todos lados
Reutilización: Importa solo lo que necesitas por componente
Facilidad de pruebas: Las bibliotecas de snippets pueden probarse de forma independiente

Cuándo Exportar Snippets

Buenos candidatos para exportar:

Utilidades de formateo: Fechas, monedas, números de teléfono
Patrones comunes de interfaz de usuario: Badges, avatares, indicadores de estado
Elementos de marca: Componentes estilizados específicos de la empresa
Patrones de accesibilidad: Combinaciones de icono + texto, helpers de marcado semántico

No recomendados para exportar:

Diseños específicos de componentes: Snippets vinculados a la estructura de un único componente
Snippets con estado: Aquellos que dependen del estado del componente (ver limitaciones más abajo)
Bloques de marcado grandes: Considera un componente completo en su lugar

Limitación Crítica

Existen limitaciones importantes que debes entender al exportar snippets desde scripts de módulo.

Sin Acceso al Estado de Instancia

Los snippets exportados no pueden referenciar variables de bloques <script> de instancia—solo pueden acceder a constantes a nivel de módulo y a sus propios parámetros.

Por qué existe esta limitación: Los scripts de módulo se ejecutan una vez cuando el módulo se carga, no por instancia de componente. El estado de instancia no existe en ese momento.

<script module>
	export { broken }
</script>

<!-- AVOID: This will NOT work -->
<script>
	let themeColor = $state('blue') // Instance state
</script>

{#snippet broken()}
	<!-- ERROR: themeColor doesn't exist in module scope -->
	<div style="color: {themeColor}">This will cause a compilation error!</div>
{/snippet}

Por qué falla:

themeColor es estado de instancia—existe por separado para cada instancia del componente
Los snippets de módulo se comparten entre todas las instancias—no pueden tener comportamiento específico por instancia
El snippet intenta acceder a algo que no existe en su ámbito

Enfoque correcto

Usar constantes de módulo

Al escribir snippets exportables, siempre usa constantes o funciones de nivel de módulo para cualquier valor compartido o helper. Estas se definen en el bloque <script module> y están disponibles para todos los snippets exportados desde el módulo. Esto garantiza que tus snippets sean autocontenidos, predecibles y seguros de usar en cualquier componente—sin depender del estado específico de la instancia.

Por ejemplo:

<script module>
	// THEME_COLOR is a module-level constant - exists once, shared by all imports
	const THEME_COLOR = 'blue'
	// Export the snippet
	export { working }
</script>

<!-- define "working" snippet with use of module level variable  -->
{#snippet working()}
	<div style="color: {THEME_COLOR}">This works because THEME_COLOR is module-scoped</div>
{/snippet}

Pasar el estado como parámetros (alternativa)

Si tu snippet necesita trabajar con datos dinámicos o específicos de la instancia, la mejor práctica es pasar esos datos como parámetros. Esto mantiene el snippet flexible y desacoplado del estado de cualquier componente en particular. Al hacer que todos los valores requeridos sean parámetros explícitos, te aseguras de que el snippet pueda reutilizarse en cualquier contexto, con cualquier dato.

En el siguiente ejemplo, definimos un snippet que acepta un parámetro color, permitiendo que el componente padre controle el color de forma dinámica:

<script module>
	export { themeableDiv }
</script>

<!-- snippet accepting a color parameter -->
{#snippet themeableDiv(content, color)}
	<div style="color: {color}">
		{content}
	</div>
{/snippet}

Uso:

<script>
	import { themeableDiv } from './Snippets.svelte'
	// Instance state defining the theme color
	let themeColor = $state('blue')
</script>

<!-- use themeColor as snippet argument -->
{@render themeableDiv('Hello world', themeColor)}

Organización de Bibliotecas de Snippets

Al construir bibliotecas de snippets, la organización es clave. Aquí hay algunos patrones comunes para estructurar las exportaciones de snippets.

1. Bibliotecas por Dominio Específico

Uno de los patrones es agrupar snippets relacionados en archivos por dominio específico. Es especialmente útil para utilidades de formato o elementos de UI comunes. Esta agrupación lógica mejora la mantenibilidad y la claridad.

src/lib/snippets/
├── formatting.svelte      # Date, currency, number formatting
├── badges.svelte          # Status badges, notifications
├── user-ui.svelte         # Avatars, user cards, profile elements
└── icons.svelte           # Icon + label combinations

luego puedes importar solo lo que necesitas:

<!-- formatting.svelte -->
<script module>
	export { formatDate, formatCurrency, formatPercentage }
</script>

{#snippet formatDate(date, format = 'short')}
	<time datetime={date.toISOString()}>
		{date.toLocaleDateString('en-US', { dateStyle: format })}
	</time>
{/snippet}

{#snippet formatCurrency(amount, currency = 'USD')}
	<span class="currency">
		{new Intl.NumberFormat('en-US', { style: 'currency', currency }).format(amount)}
	</span>
{/snippet}

{#snippet formatPercentage(value, decimals = 0)}
	<span class="percentage">
		{(value * 100).toFixed(decimals)}%
	</span>
{/snippet}

2.: Componentes UI con Temas

Otro patrón es crear bibliotecas de snippets de UI con temas. Es útil para sistemas de diseño o elementos con marca que necesitan un estilo consistente en toda la app.

<!-- badges.svelte -->
<script module>
	const BADGE_VARIANTS = {
		success: { color: '#059669', bg: '#d1fae5' },
		warning: { color: '#d97706', bg: '#fef3c7' },
		danger: { color: '#dc2626', bg: '#fee2e2' },
		info: { color: '#2563eb', bg: '#dbeafe' }
	}

	export { badge, statusBadge }
</script>

{#snippet badge(text, variant = 'info')}
	{@const theme = BADGE_VARIANTS[variant]}
	<span
		class="badge"
		style="
			color: {theme.color}; 
			background: {theme.bg};
			padding: 0.25rem 0.75rem;
			border-radius: 9999px;
			font-size: 0.875rem;
		"
	>
		{text}
	</span>
{/snippet}

{#snippet statusBadge(status)}
	{#if status === 'active'}
		{@render badge('Active', 'success')}
	{:else if status === 'pending'}
		{@render badge('Pending', 'warning')}
	{:else if status === 'error'}
		{@render badge('Error', 'danger')}
	{:else}
		{@render badge(status, 'info')}
	{/if}
{/snippet}

Uso en toda la aplicación:

<!-- OrderList.svelte -->
<script>
	import { statusBadge } from '$lib/snippets/badges.svelte'
	let { orders } = $props()
</script>

{#each orders as order}
	<div class="order">
		<span>Order #{order.id}</span>
		{@render statusBadge(order.status)}
	</div>
{/each}

Versionado y Evolución

A medida que crecen las bibliotecas de snippets, puede ser necesario evolucionar sus APIs. Un patrón común es versionar los archivos de snippets, permitiendo que múltiples versiones coexistan.

<!-- snippets/v1/formatting.svelte -->
<script module>
	export { formatPrice }
</script>

{#snippet formatPrice(amount)}
	<!-- Legacy implementation -->
{/snippet}

<!-- snippets/v2/formatting.svelte -->
<script module>
	export { formatPrice }
</script>

{#snippet formatPrice(amount, options = {})}
	<!-- Enhanced implementation with more options -->
{/snippet}

Esto permite una migración gradual a medida que se mejoran las implementaciones de snippets.

Buenas Prácticas: Diseñando con Snippets

Al diseñar componentes que aprovechan los snippets, seguir buenas prácticas garantiza que el código se mantenga mantenible, reutilizable y claro. Aquí hay principios clave para guiarte.

1. Nombra los Snippets de Forma Descriptiva

Los nombres de los snippets deben comunicar qué renderizan, no solo que son snippets. Los buenos nombres sirven como documentación en línea.

<!-- AVOID: Vague, non-descriptive naming -->
{#snippet item(data)}
	<div>{data.name}</div>
{/snippet}

{#snippet thing(x)}
	<span>{x}</span>
{/snippet}

{#snippet fn(a, b)}
	<p>{a} - {b}</p>
{/snippet}

<!-- PREFERRED Descriptive, self-documenting naming -->
{#snippet productCard(product)}
	<article class="product">
		<h3>{product.name}</h3>
		<p>${product.price}</p>
	</article>
{/snippet}

{#snippet userAvatar(user)}
	<img src={user.avatar} alt="{user.name}'s avatar" />
{/snippet}

{#snippet dateRange(startDate, endDate)}
	<time>{startDate}</time> – <time>{endDate}</time>
{/snippet}

Convenciones de nombres:

Usa sustantivos para renderizar entidades: userCard, productTile, commentThread
Usa verbos + sustantivos para acciones/formato: formatDate, renderStatus, showError
Sé específico: compactUserCard es mejor que userCard2
Utiliza el lenguaje del dominio: Si tu equipo los llama "listings," usa listingCard, no itemCard

2. Mantén los Snippets Enfocados

Cada snippet debe tener un propósito claro. Los snippets grandes con múltiples responsabilidades se vuelven difíciles de mantener y reutilizar.

Anti-patrón: God Snippet

<!-- AVOID: Too much responsibility in one snippet -->
{#snippet userSection(user)}
	<div class="user-section">
		<!-- Avatar -->
		<img src={user.avatar} alt={user.name} />

		<!-- Bio -->
		<div class="bio">
			<h2>{user.name}</h2>
			<p>{user.bio}</p>
		</div>

		<!-- Stats -->
		<div class="stats">
			<div>Posts: {user.postCount}</div>
			<div>Followers: {user.followers}</div>
			<div>Following: {user.following}</div>
		</div>

		<!-- Actions -->
		<div class="actions">
			<button>Follow</button>
			<button>Message</button>
			<button>Share</button>
		</div>
	</div>
{/snippet}

Problema: Este snippet hace demasiado. ¿Qué pasa si necesitas solo el avatar en otro lugar? ¿O si quieres reordenar las secciones? Tendrías que duplicar o crear una variante.

Mejor: Snippets Descompuestos y Enfocados

<!-- PREFERRED Each snippet has one clear purpose -->
{#snippet userAvatar(user, size = 'medium')}
	<img
		src={user.avatar}
		alt="{user.name}'s avatar"
		class="avatar avatar-{size}"
	/>
{/snippet}

{#snippet userBio(user)}
	<div class="bio">
		<h2>{user.name}</h2>
		<p>{user.bio}</p>
	</div>
{/snippet}

{#snippet userStats(user)}
	<div class="stats">
		<div class="stat">
			<span class="label">Posts</span>
			<span class="value">{user.postCount}</span>
		</div>
		<div class="stat">
			<span class="label">Followers</span>
			<span class="value">{user.followers}</span>
		</div>
		<div class="stat">
			<span class="label">Following</span>
			<span class="value">{user.following}</span>
		</div>
	</div>
{/snippet}

{#snippet userActions(user, onFollow, onMessage)}
	<div class="actions">
		<button onclick={onFollow}>Follow</button>
		<button onclick={onMessage}>Message</button>
		<button>Share</button>
	</div>
{/snippet}

{#snippet userProfile(user, actions = {}})}
	<div class="user-profile">
		{@render userAvatar(user, 'large')}
		{@render userBio(user)}
		{@render userStats(user)}
		{@render userActions(user, actions.onFollow, actions.onMessage)}
	</div>
{/snippet}

Beneficios de la descomposición:

Reutilizabilidad: Usa userAvatar en comentarios, listados, encabezados
Testabilidad: Prueba el renderizado del avatar de forma independiente
Flexibilidad: Reordena secciones cambiando userProfile
Mantenibilidad: Cambia el estilo del avatar en un solo lugar
Composición: Crea variantes como compactUserProfile usando piezas existentes

3. Tipifica las APIs de tus Componentes

Para cualquier componente que otros desarrolladores vayan a usar, siempre proporciona tipos TypeScript para los props de los snippets. Esto transforma la API de tu componente de documentación que podría estar desactualizada a contratos que se hacen cumplir.

Sin tipos:

<!-- Table.svelte -->
<script>
	let { data, row, header, footer } = $props()
</script>

<!-- Users must guess:
     - What types do these snippets accept?
     - Which are required?
     - What parameters do they receive?
-->

Con tipos:

<!-- Table.svelte -->
<script lang="ts" generics="T">
	import type { Snippet } from 'svelte'

	interface Props {
		/** Array of data items to display */
		data: T[]
		/** Required: renders table header */
		header: Snippet
		/** Required: renders a single row */
		row: Snippet<[item: T, index: number]>
		/** Optional: renders table footer */
		footer?: Snippet<[totalCount: number]>
	}

	let { data, row, header, footer }: Props = $props()
</script>

<table>
	<thead><tr>{@render header()}</tr></thead>
	<tbody>
		{#each data as item, index}
			<tr>{@render row(item, index)}</tr>
		{/each}
	</tbody>
	{#if footer}
		<tfoot><tr>{@render footer(data.length)}</tr></tfoot>
	{/if}
</table>

Lo que esto logra:

Autocompletado del IDE: Los desarrolladores ven los tipos de parámetros mientras escriben
Errores en tiempo de compilación: Los snippets requeridos faltantes se detectan antes de ejecutar
Autodocumentación: Los comentarios JSDoc aparecen en los tooltips del IDE
Seguridad al refactorizar: Renombra parámetros con confianza

4. Considera la Granularidad de los Snippets

Encontrar el nivel correcto de abstracción es un arte. Demasiado granular y tendrás una sopa de snippets. Demasiado grueso y pierdes reutilizabilidad.

Demasiado granular:

<!-- AVOID: Over-abstracted -->
{#snippet text(content)}
	<span>{content}</span>
{/snippet}

{#snippet bold(content)}
	<strong>{content}</strong>
{/snippet}

{#snippet italic(content)}
	<em>{content}</em>
{/snippet}

<!-- This is just making HTML harder to read -->
<p>
	{@render text('Hello ')}
	{@render bold('world')}
	{@render text('!')}
</p>

Justo lo necesario:

<!-- PREFERRED Meaningful abstraction -->
{#snippet formattedMessage(type, text)}
	{#if type === 'success'}
		<div class="message success">
			<span class="icon">✓</span>
			<span class="text">{text}</span>
		</div>
	{:else if type === 'error'}
		<div class="message error">
			<span class="icon">✗</span>
			<span class="text">{text}</span>
		</div>
	{:else}
		<div class="message info">
			<span class="icon">ℹ</span>
			<span class="text">{text}</span>
		</div>
	{/if}
{/snippet}

<!-- Much more useful -->
{@render formattedMessage('success', 'Profile saved!')}
{@render formattedMessage('error', 'Network error occurred')}

Preguntas para hacerse:

¿Este snippet se reutilizará más de dos veces?
¿Encapsula lógica o estilos significativos?
¿Extraerlo haría el código más claro u más oscuro?

5. Usa Snippets para Complejidad Condicional

Cuando la lógica condicional hace que tu plantilla sea difícil de leer, extráela en snippets:

Antes:

<!-- AVOID: Complex conditional logic inline -->
<div class="product">
	{#if product.onSale}
		<div class="price">
			<span class="original">${product.originalPrice}</span>
			<span class="sale">${product.salePrice}</span>
			<span class="savings">Save ${product.originalPrice - product.salePrice}!</span>
		</div>
	{:else if product.comingSoon}
		<div class="price">
			<span class="coming-soon">Coming Soon</span>
			<span class="notify">
				<button>Notify Me</button>
			</span>
		</div>
	{:else if product.outOfStock}
		<div class="price">
			<span class="out-of-stock">Out of Stock</span>
			<span class="price-value">${product.price}</span>
		</div>
	{:else}
		<div class="price">
			<span class="price-value">${product.price}</span>
		</div>
	{/if}
</div>

Después:

<!-- PREFERRED Cleaner with snippets -->
{#snippet salePrice(product)}
	<div class="price price-sale">
		<span class="original">${product.originalPrice}</span>
		<span class="sale">${product.salePrice}</span>
		<span class="savings">Save ${product.originalPrice - product.salePrice}!</span>
	</div>
{/snippet}

{#snippet comingSoonPrice()}
	<div class="price price-coming-soon">
		<span class="status">Coming Soon</span>
		<button class="notify-button">Notify Me</button>
	</div>
{/snippet}

{#snippet outOfStockPrice(product)}
	<div class="price price-out-of-stock">
		<span class="status">Out of Stock</span>
		<span class="value">${product.price}</span>
	</div>
{/snippet}

{#snippet regularPrice(product)}
	<div class="price price-regular">
		<span class="value">${product.price}</span>
	</div>
{/snippet}

<div class="product">
	{#if product.onSale}
		{@render salePrice(product)}
	{:else if product.comingSoon}
		{@render comingSoonPrice()}
	{:else if product.outOfStock}
		{@render outOfStockPrice(product)}
	{:else}
		{@render regularPrice(product)}
	{/if}
</div>

Beneficios:

Legibilidad: La plantilla principal muestra el árbol de decisiones con claridad
Mantenibilidad: Cada variante de precio está aislada y es fácil de actualizar
Testabilidad: Prueba cada variante de visualización de precio de forma independiente
Reutilizabilidad: Usa los snippets de precio en otros lugares (p. ej., carrito, resultados de búsqueda)

6. Documenta los Snippets Complejos

Para snippets con comportamiento no obvio, agrega comentarios JSDoc:

/** * Renders a user card with avatar, name, and optional bio. * * @param user - The user object to
display * @param showBio - Whether to show the user's bio (default: true) * @param size - Card size
variant: 'compact' | 'normal' | 'expanded' * * @example * {@render userCard(currentUser)}
* {@render userCard(currentUser, false, 'compact')}
*/

{#snippet userCard(user, showBio = true, size = 'normal')}
	<article class="user-card user-card-{size}">
		<img src={user.avatar} alt={user.name} />
		<h3>{user.name}</h3>
		{#if showBio && user.bio}
			<p class="bio">{user.bio}</p>
		{/if}
	</article>
{/snippet}

Los tooltips del IDE mostrarán esta documentación cuando se use el snippet.

Errores Comunes y Cómo Evitarlos

Si bien los snippets son poderosos, hay errores comunes que los desarrolladores cometen al usarlos. Entender estas trampas te ayuda a evitar bugs y confusiones.

1. Confusión de Alcance

El Problema: Intentar usar un snippet fuera de su alcance léxico produce errores de "snippet no definido".

<!-- AVOID: ERROR - Snippet used outside its scope -->
{#if userLoggedIn}
	{#snippet userGreeting()}
		<p>Welcome back, {username}!</p>
	{/snippet}

	<div class="header">
		{@render userGreeting()}
	</div>
{:else}
	<!-- ERROR: userGreeting is not defined here! -->
	<div class="header">
		{@render userGreeting()}
	</div>
{/if}

Por qué falla: El snippet userGreeting está definido dentro del bloque if, por lo que solo existe dentro de ese bloque. La rama else no puede verlo.

Solución 1: Definir en el Ancestro Común

<!-- PREFERRED Define snippet before the conditional -->
{#snippet userGreeting()}
	<p>Welcome back, {username}!</p>
{/snippet}

{#if userLoggedIn}
	<div class="header">
		{@render userGreeting()}
	</div>
{:else}
	<div class="header">
		{@render userGreeting()}
	</div>
{/if}

Solución 2: Usar Snippets Diferentes

A veces en realidad quieres contenido diferente en cada rama:

<!-- PREFERRED Different snippets for different cases -->
{#if userLoggedIn}
	{#snippet loggedInHeader()}
		<p>Welcome back, {username}!</p>
	{/snippet}

	<div class="header">
		{@render loggedInHeader()}
	</div>
{:else}
	{#snippet guestHeader()}
		<p>Welcome, guest!</p>
	{/snippet}

	<div class="header">
		{@render guestHeader()}
	</div>
{/if}

Solución 3: Pasar Datos en Lugar de Duplicar

<!-- PREFERRED Single snippet, different data -->
{#snippet header(isLoggedIn, name)}
	{#if isLoggedIn}
		<p>Welcome back, {name}!</p>
	{:else}
		<p>Welcome, guest!</p>
	{/if}
{/snippet}

<div class="header">
	{@render header(userLoggedIn, username)}
</div>

2. Confundir la Definición con el Renderizado

El Problema: Esperar que un snippet se renderice solo por definirlo.

<!-- AVOID: Nothing appears in the DOM! -->
{#snippet greeting()}
	<p>Hello, world!</p>
{/snippet}

<!-- Where's my paragraph? I defined it above! -->

Por qué falla: La definición de un snippet es como la definición de una función—crea una plantilla pero no la ejecuta. Debes renderizarla explícitamente.

Solución:

<!-- PREFERRED Define AND render -->
{#snippet greeting()}
	<p>Hello, world!</p>
{/snippet}

<!-- NOW it appears -->
{@render greeting()}

Modelo mental: Piensa en {#snippet} como function y en {@render} como llamar a esa función.

3. Olvidar el Encadenamiento Opcional para Snippets Opcionales

El Problema: Intentar renderizar un snippet opcional sin verificar si existe causa errores en tiempo de ejecución.

<!-- Component.svelte -->
<script>
	let { header, children } = $props()
</script>

<!-- AVOID: Runtime error if header is undefined! -->
<div>
	{@render header()}
	{@render children()}
</div>

Qué ocurre: Si el padre no proporciona header, header() intenta llamar a undefined → error en tiempo de ejecución.

Solución 1: Encadenamiento Opcional (Recomendado)

<!-- PREFERRED Safe: renders nothing if header is undefined -->
<div>
	{@render header?.()}
	{@render children()}
</div>

Solución 2: Condicional Explícito

<!-- PREFERRED Also safe, with optional fallback -->
<div>
	{#if header}
		{@render header()}
	{:else}
		<h2>Default Header</h2>
	{/if}
	{@render children()}
</div>

Cuándo usar cada uno:

Encadenamiento opcional: Cuando quieres que no haya salida si falta el snippet
Condicional: Cuando quieres contenido de respaldo

4. Pasar Número o Tipo de Argumentos Incorrecto

El Problema: El snippet espera parámetros pero no los recibe (o recibe tipos incorrectos).

{#snippet userCard(name, email, avatar)}
	<div class="user-card">
		<img src={avatar} alt={name} />
		<h3>{name}</h3>
		<p>{email}</p>
	</div>
{/snippet}

<!-- AVOID: Missing parameters! -->
{@render userCard()}

<!-- AVOID: Wrong number of parameters! -->
{@render userCard('Alice')}

<!-- PREFERRED Correct usage -->
{@render userCard('Alice', 'alice@example.com', '/avatars/alice.jpg')}

Sin TypeScript: Estos errores solo aparecen en tiempo de ejecución (o producen valores undefined silenciosamente).

Solución: Agregar Tipos de TypeScript

<script lang="ts">
	import type { Snippet } from 'svelte'

	interface Props {
		user: Snippet<[name: string, email: string, avatar: string]>
	}

	let { user }: Props = $props()
</script>

<!-- TypeScript now catches parameter mismatches at compile time! -->

5. Modificar los Parámetros del Snippet

El Problema: Intentar reasignar parámetros del snippet dentro del snippet.

<!-- AVOID: Parameters are read-only! -->
{#snippet incrementer(count)}
	<button onclick={() => count++}>
		Count: {count}
	</button>
{/snippet}

Por qué falla: Los parámetros del snippet son inmutables—se pasan por valor, no por referencia. Modificarlos no tiene efecto en la fuente.

Solución: Usar Estado o Callbacks

<script>
	let count = $state(0)

	function increment() {
		count++
	}
</script>

<!-- PREFERRED Snippet doesn't modify parameters, calls parent function -->
{#snippet counter(currentCount, onIncrement)}
	<button onclick={onIncrement}>
		Count: {currentCount}
	</button>
{/snippet}

{@render counter(count, increment)}

O usar $state directamente:

<script>
	let count = $state(0)
</script>

<!-- PREFERRED Snippet closes over $state, which IS mutable -->
{#snippet counter()}
	<button onclick={() => count++}>
		Count: {count}
	</button>
{/snippet}

{@render counter()}

6. Recursión Infinita

El Problema: Los snippets recursivos sin un caso base adecuado causan desbordamiento de pila.

<!-- AVOID: DANGER - Infinite recursion! -->
{#snippet countdown(n)}
	<span>{n}...</span>
	{@render countdown(n - 1)}
{/snippet}

{@render countdown(5)}
<!-- Crashes: 5... 4... 3... 2... 1... 0... -1... -2... -3... (forever) -->

Por qué falla: No hay condición de parada—el snippet sigue llamándose a sí mismo indefinidamente.

Solución: Siempre Tener un Caso Base

<!-- PREFERRED SAFE: Stops at 0 -->
{#snippet countdown(n)}
	{#if n > 0}
		<span>{n}...</span>
		{@render countdown(n - 1)}
	{:else}
		<span>🚀</span>
	{/if}
{/snippet}

{@render countdown(5)}
<!-- Renders: 5... 4... 3... 2... 1... 🚀 -->

Para datos generados por el usuario, agrega límite de profundidad:

{#snippet treeNode(node, depth = 0, maxDepth = 10)}
	{#if depth >= maxDepth}
		<span class="truncated">... (max depth)</span>
	{:else if node.children}
		<div>
			{node.name}
			{#each node.children as child}
				{@render treeNode(child, depth + 1, maxDepth)}
			{/each}
		</div>
	{:else}
		<div>{node.name}</div>
	{/if}
{/snippet}

7. Usar Snippets en Exceso

El Problema: Crear snippets para cosas que deberían ser simplemente HTML o componentes.

<!-- AVOID: Over-engineered: These don't need to be snippets -->
{#snippet paragraph(text)}
	<p>{text}</p>
{/snippet}

{#snippet heading(text)}
	<h2>{text}</h2>
{/snippet}

{#snippet link(href, text)}
	<a {href}>{text}</a>
{/snippet}

<!-- Just write HTML! -->
<p>This is simpler.</p>
<h2>So is this.</h2>
<a href="/about">And this.</a>

Cuándo NO usar snippets:

Markup simple de un solo uso
Elementos HTML básicos sin lógica especial
Cosas que quedarían más claras como HTML en línea

Cuándo SÍ usar snippets:

Patrones repetidos (2 o más veces)
Renderizado condicional complejo
Markup que necesita ser personalizado por componentes padre
Lógica de renderizado que podrías extraer a una librería compartida

8. Acceder a Propiedades Inexistentes de un Snippet

El Problema: Tratar los snippets como objetos con propiedades.

<!-- AVOID: Snippets are not objects! -->
{#snippet user(data)}
	<p>{data.name}</p>
{/snippet}

<!-- ERROR: Can't access .name, .params, etc. -->
<p>Snippet name: {user.name}</p>

Por qué falla: Los snippets son funciones de renderizado compiladas, no objetos en tiempo de ejecución con propiedades accesibles.

Solución: Los snippets son para renderizar, no para introspección. Si necesitas metadatos, guárdalos por separado:

<script>
	const userSnippetMeta = {
		name: 'user',
		description: 'Renders user information'
	}
</script>

{#snippet user(data)}
	<p>{data.name}</p>
{/snippet}

<!-- Use metadata separately -->
<p>Snippet: {userSnippetMeta.name}</p>
{@render user(currentUser)}

Referencia Rápida

<!-- DEFINING SNIPPETS -->
{#snippet name()}...{/snippet}                   <!-- No parameters -->
{#snippet name(param)}...{/snippet}              <!-- One parameter -->
{#snippet name(a, b, c)}...{/snippet}            <!-- Multiple parameters -->
{#snippet name(param = default)}...{/snippet}   <!-- Default value -->
{#snippet name({ x, y })}...{/snippet}           <!-- Destructured -->

<!-- TYPING (TypeScript) -->
import type { Snippet } from 'svelte';
children: Snippet                                 <!-- No params -->
row: Snippet<[Item]>                              <!-- One param -->
cell: Snippet<[Item, number]>                     <!-- Multiple params -->
header?: Snippet                                  <!-- Optional -->

<!-- EXPORTING (Svelte 5.5.0+) -->
<script module>
	export { snippetName }
</script>

Conclusión

El bloque {#snippet} transforma fundamentalmente cómo pensamos sobre la composición de componentes en Svelte. Al tratar los fragmentos de UI como valores de primera clase que pueden definirse, pasarse e invocarse de manera programática, los snippets habilitan patrones arquitectónicos que antes eran difíciles o imposibles con el sistema basado en slots. Desde la proyección de contenido simple hasta estructuras recursivas complejas, desde APIs de bibliotecas de componentes hasta patrones de composición avanzados, los snippets proporcionan los bloques de construcción primitivos para sistemas de componentes flexibles y mantenibles.

Dominar los snippets requiere comprender sus reglas de alcance, patrones de parámetros e integración con el sistema reactivo de Svelte. La capacidad de definir snippets en línea, pasarlos como props, exportarlos desde componentes y componerlos de forma recursiva abre nuevas posibilidades para el diseño de APIs de componentes. Ya sea que estés construyendo sistemas de diseño con renderizado basado en variantes, implementando componentes de árbol recursivos o creando sistemas de layout flexibles con múltiples slots de contenido, los snippets proporcionan la base para expresar patrones de composición complejos con claridad y seguridad de tipos.

Puntos Clave

{#snippet} define fragmentos de plantilla reutilizables con parámetros, actuando como funciones a nivel de plantilla que pueden pasarse como props, almacenarse en variables o exportarse desde componentes
Los parámetros de snippet permiten el paso de datos con la sintaxis {#snippet card({ title, description })}, recibiendo argumentos cuando se invocan mediante {@render card({ title: 'Hello', description: 'World' })}
El alcance sigue reglas léxicas - los snippets acceden a las variables de su alcance de definición, no del alcance de llamada, lo que permite closures sobre el estado del componente
Múltiples snippets proporcionan APIs de componentes flexibles - los componentes aceptan múltiples props de snippet para encabezados, pies de página y áreas de contenido, habilitando layouts personalizables sin prop drilling
Los snippets recursivos requieren casos base para evitar bucles infinitos: {#if condition}{@render self(recursiveData)}{/if} garantiza la terminación
Seguridad de tipos con TypeScript usando el tipo Snippet del paquete svelte: let { header }: { header: Snippet<[string]> } = $props() para parámetros con verificación de tipos
Exportar snippets para uso externo listando sus nombres en una declaración export { snippetName } dentro de un bloque <script module>, haciéndolos importables en toda la aplicación como cualquier otra exportación de módulo
Los snippets son reactivos - se vuelven a renderizar automáticamente cuando cambia cualquier estado reactivo sobre el que tienen closure, igual que las expresiones de plantilla regulares; el renderizado siempre está sincronizado con el estado actual

Ver También

Documentación oficial de Svelte 5 - {#snippet}
$props() - Sistema de props de componentes, incluyendo props de snippet
TypeScript con Svelte - Definiciones de snippets con seguridad de tipos
Patrones de Composición de Componentes - Diseño avanzado de APIs de componentes
$derived - Computaciones reactivas para la lógica de selección de snippets

Entendiendo el modelo mental de los Snippets

La evolución de los Slots a los Snippets

La filosofía de los Snippets

El concepto central: Marcado como valores

Definir sin renderizar

Renderizado explícito

Por qué importan los Snippets: La crisis de mantenibilidad

El costo de la duplicación de código

El principio DRY en acción

Impacto en el mundo real

Parámetros de Snippet: Renderizado basado en datos

El poder de la parametrización

Pasar datos al marcado

Parámetros básicos

Múltiples valores discretos

Valores predeterminados de parámetros

Mejora progresiva

Parámetros con Desestructuración

APIs Basadas en Objetos

Limitación Crítica

Sin Parámetros Rest

Alcance y Visibilidad de Snippets: Reglas de Alcance Léxico

Entendiendo el Alcance de los Snippets

Accediendo al Estado del Componente

Closure Reactivo sobre Variables del Script

Accediendo a Variables de Bucle: Closures por Iteración

Reglas de Visibilidad: Alcance Léxico en Práctica

Qué Puede Ver tu Snippet

Qué No Puede Ver tu Snippet

Ejemplo Visual de Alcance

Implicaciones Prácticas

1. Snippets de Nivel Superior para Reutilización Global

2. Snippets con Alcance para Lógica Localizada

3. Evitando Problemas de Alcance

Snippets Recursivos

Cuándo Tiene Sentido la Recursión

Entendiendo la Recursión en Snippets

Patrones de Auto-referencia

Recursión Básica: Ejemplo de Cuenta Regresiva

Snippets Mutuamente Recursivos

Ejemplo Práctico:

Estructura de Árbol de Archivos

Avanzado

Árbol Interactivo Colapsable

Buenas Prácticas de Recursión

1. Siempre Ten un Caso Base

2. Controla la Profundidad para Prevenir Desbordamiento de Pila

3. Considera el Rendimiento para Árboles Grandes

Pasar Snippets a Componentes: Inversión de Control

El Poder de la Delegación de Renderizado

1. Props de Snippet Explícitas

2. Props de Snippet Implícitas

El Snippet Implícito children

Combinar Snippets con Nombre y Children

Patrones de Diseño de API de Componentes

1. Snippets Requeridos vs Opcionales

2. Parámetros de Snippet para Contexto

Integración con TypeScript: APIs de Componentes con Tipos Seguros

¿Por qué tipar los Snippets?

El Tipo Snippet

Tipado Básico de Snippets

Tipar Snippets con Parámetros

Avanzado: Snippets Genéricos para Seguridad de Tipos

Ejemplo de Tabla Genérica

Genérico con Restricciones

Props de Snippets Opcionales

Patrones de Tipado para Casos de Uso Comunes

Patrón 1: Datos + Snippet de Renderizado

Patrón 2: Children Opcionales con Fallback

Patrón 3: Múltiples Snippets Relacionados

Buenas Prácticas de Seguridad de Tipos

Exportar Snippets

Construyendo Bibliotecas de Plantillas Reutilizables

El Problema: Localidad de los Snippets

Definiendo Snippets Exportables

Importando y Usando Snippets Exportados

Cuándo Exportar Snippets

Limitación Crítica

Sin Acceso al Estado de Instancia

Enfoque correcto

El Snippet Implícito `children`

El Tipo `Snippet`