Entendendo o Modelo Mental de Snippets

A Evolução dos Slots para Snippets

No Svelte 4, a composição de componentes dependia de slots (<slot>), um padrão emprestado dos Web Components. Embora funcional, os slots introduziram vários pontos problemáticos que afetavam tanto a experiência do desenvolvedor quanto a manutenibilidade do código:

As Limitações dos Slots:

Problemas de fluxo de dados unidirecional: Passar dados do filho para o pai exigia callbacks de props ou bindings complexos
Sintaxe verbosa para slots nomeados: <svelte:fragment slot="header"> parecia pesado para casos de uso simples
Detecção de slots apenas em tempo de execução: O objeto $$slots só estava disponível em tempo de execução, limitando a capacidade do TypeScript de detectar erros em tempo de compilação
Sem reutilização: Os slots não podiam ser extraídos e reutilizados em diferentes componentes — eles estavam fortemente acoplados ao seu componente
Fluxo de dados pouco claro: A natureza implícita do conteúdo dos slots tornava difícil rastrear de onde o conteúdo vinha e quais dados estavam disponíveis

A Filosofia dos Snippets

O Svelte 5 introduz os snippets — uma mudança de paradigma que trata a marcação reutilizável como valores de primeira classe. Isso não é apenas açúcar sintático; é uma reformulação fundamental da composição de componentes baseada nos seguintes princípios:

O Que Torna os Snippets Diferentes:

Funções, não buracos: Snippets são construções semelhantes a funções que você invoca explicitamente, não projeções de conteúdo implícitas
Explícito é melhor que implícito: O fluxo de dados é visível — você pode ver exatamente quais dados entram e quais saem
Reutilizáveis e combináveis: Snippets podem ser passados como props, armazenados em variáveis e reutilizados entre componentes como qualquer outro valor
Type-safe por padrão: O TypeScript pode verificar as assinaturas dos snippets em tempo de compilação, capturando erros antes da execução
Controle programático: Você decide quando, onde e quantas vezes um snippet é renderizado — controle total sobre o ciclo de vida de renderização

Este tutorial se concentra em definir snippets: sua sintaxe, parâmetros, regras de escopo e como exportá-los para reutilização. Para padrões de renderização e técnicas avançadas de composição, consulte o artigo complementar sobre @render.

O Conceito Central: Marcação como Valores

Pense em um snippet como uma função de template. Assim como você define uma função JavaScript para encapsular lógica, você define um snippet para encapsular a estrutura de marcação. A diferença crítica em relação à marcação comum: definição ≠ execução.

Definindo Sem Renderizar

Quando você escreve um snippet, está criando um template reutilizável, não adicionando elementos imediatamente ao DOM. Isso é análogo a como definir uma função não a executa:

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

O que está acontecendo aqui? Isso cria um snippet chamado greeting que, quando invocado, produzirá um elemento de parágrafo. Mas observe: nada aparece no DOM ainda. O snippet é definido, mas não executado — semelhante a como definir uma função não executa seu 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 que isso importa: Essa separação permite que você defina padrões de marcação uma vez e os reutilize várias vezes, condicionalmente ou em contextos diferentes — sem duplicar a definição.

Renderização Explícita

Para realmente renderizar o conteúdo do snippet no DOM, você deve invocá-lo explicitamente usando a diretiva @render:

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

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

Por que essa separação importa: Este modelo de renderização explícita fornece controle preciso sobre:

Quando a marcação é renderizada (renderização condicional baseada em estado)
Onde ela aparece na árvore de componentes (flexibilidade de layout)
Quantas vezes ela é renderizada (iteração sem duplicação)
Quais dados ela recebe a cada vez (parametrização)

A percepção chave: Snippets separam a definição (qual marcação criar) da renderização (quando e onde inseri-la no DOM). Essa separação é o que permite os poderosos padrões de composição que você explorará ao longo deste guia.

Por Que os Snippets Importam: A Crise de Manutenibilidade

O Custo da Duplicação de Código

Quando o mesmo padrão de marcação aparece em vários lugares, você enfrenta uma crise de manutenção: cada atualização exige encontrar e alterar cada ocorrência. Perder uma delas introduz inconsistência. Isso não é apenas sobre economizar pressionamentos de tecla — é sobre reduzir a carga cognitiva e prevenir bugs.

O Princípio DRY em Ação

Considere este padrão comum do Svelte 4 onde a mesma marcação aparece em diferentes contextos condicionais:

<!-- 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}

Os problemas com essa abordagem:

Duplicação: O bloco <figure> aparece duas vezes com estrutura idêntica
Fragilidade: Alterar a estrutura da imagem requer atualizar ambas as ramificações
Propenso a erros: Fácil de atualizar uma ramificação e esquecer a outra, causando inconsistências visuais
Legibilidade: A lógica real (se deve envolver em um link) fica obscurecida pela marcação repetitiva
Escalabilidade: Adicionar uma terceira condição significa triplicar a marcação

Com snippets, a mesma lógica se torna:

<!-- 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}

O que melhorou:

Fonte única da verdade: A estrutura da figura é definida apenas uma vez no topo
Propagação de alterações: Atualizações na figura se aplicam automaticamente em todos os lugares onde ela é renderizada
Intenção clara: A lógica condicional agora é sobre envolver, não recriar a marcação
Testabilidade: Você pode testar a estrutura da figura independentemente do seu contexto de uso
Escalabilidade: Adicionar mais condições significa apenas adicionar mais chamadas {@render figure(image)}

Impacto no mundo real

Em uma aplicação de produção com centenas de componentes, esse padrão previne classes inteiras de bugs. Quando você precisa adicionar lazy loading às imagens, atualizar o formato do texto alternativo ou mudar o estilo da legenda, você altera uma vez em vez de procurar em vários arquivos.

Parâmetros de Snippets: Renderização Orientada a Dados

O Poder da Parametrização

Snippets sem parâmetros são úteis, mas os snippets parametrizados desbloqueiam todo o poder da marcação reutilizável. Ao aceitar parâmetros, os snippets se tornam templates adaptáveis que podem renderizar dados diferentes mantendo uma estrutura consistente.

Passando Dados para a Marcação

Pense nos parâmetros de snippets como argumentos de função: eles definem quais dados o snippet precisa para fazer seu trabalho. Isso cria um contrato claro entre a definição do snippet e seu uso.

Parâmetros Básicos

Múltiplos Valores Discretos

Use múltiplos parâmetros quando precisar passar partes de dados distintas e não 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 que isso funciona bem:

Contrato claro: Você vê imediatamente que este snippet precisa de três partes de dados
Segurança de tipos: O TypeScript pode verificar se você está passando o número e os tipos corretos de argumentos
Flexibilidade: Cada chamada de renderização pode fornecer dados completamente diferentes

Quando usar este padrão:

Quando os dados existem naturalmente como variáveis separadas
Quando você quer ser explícito sobre quais dados são necessários
Quando o número de parâmetros é pequeno (≤5 é uma boa regra)

Valores Padrão de Parâmetros

Aprimoramento Progressivo

Os parâmetros podem ter valores padrão, implementando um padrão de aprimoramento progressivo onde casos de uso mais simples funcionam com 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 -->

O que está acontecendo aqui:

Primeira chamada: Apenas text é fornecido; variant e size usam seus valores padrão
Segunda chamada: text e variant são fornecidos; size usa seu valor padrão
Terceira chamada: Todos os parâmetros são fornecidos explicitamente

Quando usar valores padrão:

Quando você tem um caso comum que deve ser fácil (como estilo padrão)
Quando os parâmetros representam aprimoramentos progressivos em vez de dados essenciais
Quando você quer evoluir sua API sem quebrar usos existentes

Dica de design: Ordene os parâmetros do mais para o menos provável de ser personalizado. Isso permite que os usuários forneçam menos argumentos para casos comuns.

Desestruturação de Parâmetros

APIs Baseadas em Objetos

Para estruturas de dados complexas ou quando você tem muitos parâmetros relacionados, a desestruturação fornece uma sintaxe mais limpa e fácil de manter:

{#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 que a desestruturação se destaca aqui:

Autodocumentada: A declaração do snippet mostra exatamente quais campos do produto ela usa
Flexível: Objetos de produto podem ter campos adicionais que o snippet ignora
Amigável à refatoração: Adicionar novos campos ao produto não quebra o snippet
Legível no ponto de chamada: {@render productItem(product)} é mais claro do que {@render productItem(product.name, product.price, product.inStock, product.imageUrl)}

Quando usar desestruturação:

Quando os dados existem naturalmente como um objeto (como itens de um array)
Quando você precisa de mais de 3-4 parâmetros
Quando os parâmetros formam uma unidade coesa (propriedades de produto, dados de usuário, objeto de configuração)
Quando você quer extrair apenas campos específicos de um objeto maior

Combinando desestruturação com valores padrão:

{#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}

Isso combina a clareza da desestruturação com a flexibilidade dos valores padrão—produtos sem os campos inStock, imageUrl ou rating ainda serão renderizados corretamente.

Limitação Crítica

Sem Parâmetros Rest

Ao contrário das funções JavaScript, snippets não podem usar parâmetros rest (...rest) para capturar listas de argumentos de comprimento variável:

<!-- 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 que essa limitação existe: O Svelte compila snippets em funções de renderização otimizadas em tempo de build. Parâmetros rest exigiriam manipulação de argumentos em tempo de execução, o que conflita com o modelo de otimização em tempo de compilação do Svelte.

Alternativas quando você precisa de argumentos variáveis:

Passe um array: Passe explicitamente uma coleção como um único parâmetro
Desestruturação com campos conhecidos: Use desestruturação de objetos para campos conhecidos
Múltiplos snippets: Crie snippets diferentes para aridades diferentes (embora isso raramente seja necessário na prática)

Escopo e Visibilidade de Snippets: Regras de Escopo Léxico

Entendendo o Escopo de Snippets

Snippets seguem as regras de escopo léxico do JavaScript, o que significa que sua visibilidade é determinada por onde eles são definidos na estrutura do seu componente, não onde são renderizados. Isso é ao mesmo tempo poderoso (permitindo closures sobre o estado do componente) e algo que você precisa entender para evitar confusões.

Acessando o Estado do Componente

Closure Reativa sobre Variáveis do Script

Snippets podem acessar variáveis do bloco <script> ao redor, criando uma closure reativa. Quando essas variáveis mudam, todas as instâncias renderizadas do snippet atualizam automaticamente:

<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>

O que está acontecendo aqui:

O snippet hello "fecha sobre" currentTheme e message do escopo pai
Quando currentTheme muda (via clique no botão), ambos os snippets renderizados atualizam automaticamente
Cada chamada @render vê o valor atual de currentTheme—essa é a reatividade refinada do Svelte em ação

Por que isso importa:

Fonte única de verdade: O estado do tema vive em um único lugar, mas afeta todas as renderizações do snippet
Sem prop drilling: Snippets podem acessar o estado do componente sem precisar passá-lo como parâmetros
Atualizações automáticas: A reatividade funciona através da fronteira do snippet—sem necessidade de assinaturas manuais

Quando usar closure vs parâmetros:

Use closure para estado global do componente (tema, sessão do usuário, feature flags)
Use parâmetros para dados que variam por renderização (itens de lista, IDs, conteúdo específico)

Acessando Variáveis de Loop: Closures por Iteração

Snippets definidos dentro de loops podem acessar as variáveis de iteração do loop, criando uma closure separada para cada iteração:

{#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}

O que faz isso funcionar:

Cada iteração cria um novo snippet categoryHeader com sua própria closure
O snippet da primeira iteração fecha sobre category[0] e categoryIndex = 0
O snippet da segunda iteração fecha sobre category[1] e categoryIndex = 1
Cada snippet é independente—alterar um não afeta os outros

Casos de uso práticos:

Cabeçalhos/rodapés repetidos: Renderize o mesmo conteúdo no topo e na parte inferior de uma seção
Renderização condicional: Mostre/oculte elementos repetidos com base nos dados da iteração
Formatação consistente: Aplique o mesmo estilo a diferentes partes de um item

Regras de Visibilidade: Escopo Léxico na Prática

Snippets seguem um padrão de visibilidade previsível baseado na estrutura do DOM. Entender essas regras previne erros de "snippet não definido" e ajuda você a estruturar seus componentes de forma eficaz.

O Que Pode Ver Seu Snippet

Snippets são visíveis para:

Eles mesmos (permitindo recursão para estruturas de árvore)
Elementos irmãos no mesmo nível de aninhamento
Filhos desses irmãos (descendentes na árvore do DOM)

O Que Não Pode Ver Seu Snippet

Eles NÃO são visíveis para:

Elementos pai (escopos externos/contendo)
Elementos em ramos diferentes da árvore do DOM
Outros snippets no mesmo nível (a menos que você os passe como parâmetros)

Exemplo Visual de Escopo

<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 que essas regras existem:

Prevenir colisões de nomes: Ramos diferentes podem ter snippets com o mesmo nome
Modelo mental claro: A visibilidade segue a estrutura da árvore do DOM
Encapsulamento: Detalhes de implementação internos (snippets aninhados) não vazam para escopos externos

Implicações Práticas

1. Snippets no Nível Superior para Reutilização Global

Quando um snippet é necessário em vários lugares de um componente, defina-o no nível 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 com Escopo para Lógica Localizada

Quando um snippet é relevante apenas dentro de um condicional ou loop específico, defina-o lá para manter o namespace limpo:

{#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 Escopo

Quando um snippet precisa ser usado em múltiplos ramos de um condicional, defina-o em um nível ancestral comum:

<!-- 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}

Não:

<!-- 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

A recursão é uma técnica poderosa para renderizar estruturas de dados hierárquicas de profundidade desconhecida. Snippets do Svelte suportam recursão, permitindo que você defina snippets que chamam a si mesmos ou uns aos outros para lidar com dados aninhados de forma elegante.

Quando a Recursão Faz Sentido

A recursão em snippets resolve um problema específico: renderizar dados de profundidade desconhecida. Quando você tem estruturas em árvore, comentários aninhados, sistemas de arquivos ou qualquer dado hierárquico em que você não sabe quantos níveis de profundidade existem, snippets recursivos são a solução.

Casos de uso comuns:

Árvores de arquivos/pastas (profundidade desconhecida até o tempo de execução)
Threads de comentários com respostas aninhadas
Organogramas
Hierarquias de categorias (ex.: categorias de e-commerce)
Visualizadores de árvores JSON/XML
Sistemas de menus com aninhamento ilimitado

Entendendo a Recursão em Snippets

Padrões de Auto-Referência

Snippets podem referenciar a si mesmos, assim como funções JavaScript. A chave está em entender o caso base (quando parar) e o caso recursivo (quando continuar).

Recursão Básica: Exemplo de Contagem Regressiva

{#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! -->

Como funciona:

Chamada inicial: countdown(5) renderiza "5..." e então chama countdown(4)
Segunda chamada: countdown(4) renderiza "4..." e então chama countdown(3)
Continua: Cada chamada renderiza seu número e faz uma chamada menor
Caso base: Quando n chega a 0, renderiza "🚀 Liftoff!" e para

Conceito crítico: O caso base evita loops infinitos. Sem {#if n > 0}, o snippet chamaria a si mesmo para sempre, eventualmente causando um estouro de pilha (stack overflow).

Snippets Mutuamente Recursivos

Snippets também podem chamar uns aos outros em um padrão 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)}

O que é diferente aqui:

countdown não contém diretamente o emoji do foguete
Em vez disso, ele delega para blastoff quando termina
Isso separa as responsabilidades: lógica de contagem vs exibição final

Quando usar recursão mútua:

Quando estados diferentes requerem lógicas de renderização diferentes
Para manter snippets individuais focados e com uma única responsabilidade
Quando você quiser reutilizar sub-snippets de forma independente

Exemplo Prático:

Estrutura de Árvore de Arquivos

Sistemas de arquivos são o exemplo canônico de dados recursivos — pastas contêm arquivos e outras pastas, que contêm arquivos e pastas, ad infinitum.

Estrutura de Dados de Exemplo

<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: O 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)}

Como o fluxo de recursão funciona:

Início: Renderiza treeNode(fileTree, 0) → "project" na profundidade 0
Primeiro nível: Itera pelos filhos do projeto
- Renderiza treeNode(src, 1) → - src na profundidade 1
- Renderiza treeNode(package.json, 1) → - package.json (para, é um arquivo)
- Renderiza treeNode(README.md, 1) → - README.md (para, é um arquivo)
Segundo nível: Ao renderizar src, itera pelos seus filhos
- Renderiza treeNode(components, 2) → - components na profundidade 2
- Renderiza treeNode(App.svelte, 2) → - App.svelte (para)
- Renderiza treeNode(main.js, 2) → - main.js (para)
Terceiro nível: Ao renderizar components, itera pelos seus filhos
- Renderiza treeNode(Button.svelte, 3) → - Button.svelte (para)
- Renderiza treeNode(Card.svelte, 3) → - Card.svelte (para)

Características principais desse padrão:

Rastreamento de profundidade: O parâmetro depth cria o recuo adequado
Terminação automática: Arquivos (sem filhos) encerram a recursão naturalmente
Profundidade desconhecida: Funciona para qualquer número de níveis de aninhamento
Renderização uniforme: Cada nó é renderizado de forma consistente, independentemente da profundidade

Avançado

Vamos aprimorar a árvore de arquivos com funcionalidade de expandir/recolher:

Árvore Colapsável Interativa

<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)}

O que mudou:

Rastreamento de estado: O Set expandedFolders rastreia quais pastas estão abertas
Função de alternância: O manipulador de clique adiciona/remove pastas do Set
Renderização condicional: Exibe os filhos somente se a pasta estiver expandida
Variação de ícone: Exibe emojis diferentes para o estado expandido/recolhido

Por que isso é poderoso:

A recursão lida com aninhamento arbitrariamente profundo
O gerenciamento de estado é plano (Set de nomes de pastas), não aninhado
Cada nó pode expandir/recolher de forma independente
Adicionar novos arquivos/pastas não exige nenhuma alteração no código

Boas Práticas de Recursão

1. Sempre Tenha um 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. Rastreie a Profundidade para Evitar Estouro de Pilha

Para dados fornecidos pelo usuário, adicione uma profundidade 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. Considere o Desempenho para Árvores Grandes

Para árvores muito grandes (milhares de nós), considere:

Virtualização: Renderize apenas os nós visíveis
Carregamento sob demanda: Busque os filhos conforme necessário
Paginação: Limite o número de filhos exibidos por nível

Passando Snippets para Componentes: Inversão de Controle

O Poder da Delegação de Renderização

Passar snippets para componentes implementa inversão de controle — em vez de o componente ditar exatamente como o conteúdo se parece, ele delega as decisões de renderização de volta ao componente pai. Isso cria componentes flexíveis e reutilizáveis que se adaptam a diferentes casos de uso sem modificação.

O problema tradicional:

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

O componente Table define de forma fixa como cabeçalhos e linhas se parecem. Quer um estilo personalizado? Você está preso. Precisa adicionar uma coluna? Modifique o componente.

A solução com snippets:

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

O Table fornece a estrutura (tabela, loops, layout) enquanto o pai fornece o conteúdo (cabeçalhos, formatação de células). Essa separação de responsabilidades é poderosa. Aqui estão duas formas principais de passar snippets como props.

1. Props de Snippet Explícitas

Defina snippets no pai e passe-os como props explícitas para o componente filho:

<!-- 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>

O que está acontecendo aqui:

O pai controla o conteúdo: O pai define exatamente o que os cabeçalhos e as células das linhas contêm
O filho controla a estrutura: O filho gerencia o wrapper da tabela, thead/tbody e a iteração
Interface clara: A API de props do Table (data, header, row) documenta o que ele precisa
Componente reutilizável: O mesmo Table pode renderizar produtos, usuários, pedidos — qualquer coisa

Quando usar props explícitas:

Quando snippets são definidos separadamente do uso
Quando você quiser reutilizar snippets em múltiplos componentes
Quando o relacionamento entre snippets e o componente deve ser explícito
Para componentes complexos onde documentar a API é importante

2. Props de Snippet Implícitas

Snippets definidos diretamente dentro de tags de componentes automaticamente se tornam props nesse 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>

Isso é semanticamente idêntico à versão explícita. O compilador transforma isso em:

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

Quando usar props implícitas:

Quando snippets são usados apenas com esta instância específica do componente
Para uma sintaxe mais limpa e declarativa que mostra o conteúdo junto com o componente
Quando a relação pai-filho é óbvia pelo contexto
Para componentes que seguem o padrão "componente envolve conteúdo"

Escolhendo 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>

O Snippet Implícito `children`

Todo componente pode aceitar uma prop de snippet especial chamada children, representando o slot de conteúdo padrão. Isso permite que você passe conteúdo arbitrário para um componente sem nomear explicitamente o snippet.

Componente Button

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

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

Quando você coloca qualquer conteúdo dentro das tags de um componente (sem um snippet nomeado), esse conteúdo automaticamente se torna o snippet children.

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

O que o compilador faz conceitualmente:

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

<Button {children} />

Por que children é especial:

Slot de conteúdo padrão: Todo componente pode aceitar conteúdo sem nomeá-lo
Aprimoramento progressivo: Componentes simples funcionam sem nomes de snippet explícitos
Padrão familiar: Espelha a forma como elementos HTML aceitam conteúdo
Compatibilidade retroativa: Semelhante ao funcionamento dos slots, facilitando a migração

Combinando Snippets Nomeados e Children

Você pode combinar children com snippets nomeados para layouts complexos:

<!-- 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>

O 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>

Padrões de Design de API de Componentes

1. Snippets Obrigatórios vs Opcionais

Projete APIs de componentes que comuniquem claramente o que é obrigatório:

<!-- 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

Passe dados contextuais para snippets para que possam tomar decisões de renderização 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 que passar contexto:

Snippets podem acessar informações de posição (primeiro, último, índice)
O pai não precisa calcular esses dados
O componente encapsula a lógica de iteração
Snippets permanecem focados na renderização

Para padrões de renderização mais avançados, tratamento opcional de snippets e seleção dinâmica de snippets, consulte o artigo complementar sobre {@render ...}.

Integração com TypeScript: APIs de Componentes com Tipagem Segura

Por Que Tipar Snippets?

Em JavaScript, snippets são flexíveis, mas propensos a erros — você pode passar o número errado de argumentos, tipos incorretos ou esquecer snippets obrigatórios completamente. O TypeScript transforma snippets de suposições em tempo de execução em garantias em tempo de compilação.

Benefícios de tipar snippets:

Autocomplete na IDE: Veja quais snippets um componente espera e quais parâmetros eles precisam
Erros em tempo de compilação: Detecte snippets ausentes ou parâmetros incorretos antes de executar o código
Segurança na refatoração: Renomeie parâmetros ou altere tipos com confiança
APIs autodocumentadas: Os tipos servem como documentação sempre atualizada

O Tipo `Snippet`

O Svelte 5 fornece o tipo Snippet do pacote 'svelte'. Esse tipo representa um snippet com tipos de parâmetros opcionais.

Tipagem Básica de Snippets

Para snippets sem parâmetros, use Snippet diretamente:

<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>

O que isso realiza:

Verificação de obrigatoriedade: TypeScript emite erro se o pai não fornecer children
Sem parâmetros obrigatórios: TypeScript emite erro se você chamar children(someArg)
Contrato claro: Qualquer pessoa que use este componente sabe que deve fornecer um snippet children

Tipando Snippets com Parâmetros

Os parâmetros de snippet são tipados como uma 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>

Tipagem segura em ação:

<!-- 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 que tuplas? Tuplas preservam a ordem dos parâmetros e os tipos individuais, ao contrário de arrays, que possuem um único tipo de elemento.

Avançado: Snippets Genéricos para Tipagem Segura

Genéricos garantem consistência de tipos entre dados e os snippets que renderizam esses dados. Isso previne bugs sutis onde a estrutura dos dados não corresponde ao que o snippet espera.

Exemplo de Tabela 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>

Como isso funciona:

<!-- 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>

O que o TypeScript garante:

data é um Product[]
row recebe um parâmetro Product
Se você tentar acessar product.unknownField, o TypeScript gera um erro
Se você alterar products para um tipo diferente, o snippet deve corresponder

Genérico com múltiplos 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 com Restrições

Às vezes você precisa garantir que o tipo genérico tenha propriedades 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>

A restrição extends { id: string | number } garante:

Cada item em items deve ter uma propriedade id
O id deve ser uma string ou número
O TypeScript gera erros em tempo de compilação se você passar itens sem id

Props de Snippet Opcionais

Marque snippets como opcionais usando o operador ? do 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 no componente pai:

<!-- 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>

Padrões de Tipagem para Casos de Uso Comuns

Padrão 1: Snippet de Dados + Renderização

<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}

Padrão 2: Children Opcionais com 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}

Padrão 3: Múltiplos 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}

Boas Práticas de Segurança de Tipos

Sempre tipo as APIs públicas de componentes: Mesmo que seu projeto não imponha tipagem estrita em todo lugar, defina tipos para props de componentes que outros desenvolvedores utilizarão
Use genéricos para componentes orientados a dados: Quando componentes iteram sobre dados e os passam para snippets, use genéricos para manter a segurança de tipos
Seja explícito sobre snippets opcionais: Use ? para opcionais e omita para obrigatórios — isso torna o contrato da API claro
Documente a semântica dos parâmetros: Use comentários JSDoc para explicar o que os parâmetros de snippet representam:

<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>

Exportando Snippets

Os snippets não estão limitados ao componente onde são definidos. O Svelte 5 permite exportar snippets para que possam ser reutilizados em toda a sua aplicação ou até mesmo publicados como parte de uma biblioteca de templates.

Construindo Bibliotecas de Templates Reutilizáveis

Ao exportar snippets, você pode criar bibliotecas de templates de UI reutilizáveis, helpers de formatação ou primitivos de design. Essas bibliotecas podem ser compartilhadas em todo o seu projeto ou até mesmo publicadas para uso de outras pessoas, tornando sua base de código mais modular e sustentável. Essa abordagem é ideal para sistemas de design, padrões de UI compartilhados ou qualquer situação em que você queira padronizar marcação e lógica.

O Problema: Localidade dos Snippets

Por padrão, snippets têm escopo de componente — eles existem apenas dentro do componente onde são definidos. Isso funciona muito bem para padrões de marcação locais ao componente, mas e quanto à lógica de formatação necessária em muitos componentes?

Antes do Svelte 5.5.0, você tinha duas opções insatisfatórias:

Duplicar o snippet em cada componente que precisasse dele (violação do princípio DRY)
Criar um componente auxiliar (solução pesada para uma marcação simples)

A partir do Svelte 5.5.0, você pode exportar snippets de scripts de módulo, tornando-os importáveis como qualquer outro valor de módulo.

Definindo Snippets Exportáveis

Para exportar snippets, defina-os em um bloco <script module> e use uma instrução export listando os nomes dos 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 principais:

Os snippets devem ser de nível superior (não aninhados dentro de {#if}, {#each}, etc.)
A instrução export deve estar em um bloco <script module>
Você exporta apenas os nomes dos snippets, não suas definições completas

Importando e Usando Snippets Exportados

Snippets exportados podem ser importados em qualquer componente usando a sintaxe padrão 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>

O que isso alcança:

Consistência: A formatação de preços fica idêntica em toda a aplicação
Manutenibilidade: Atualize formattedPrice uma vez e as mudanças se propagam em todos os lugares
Reutilizabilidade: Importe apenas o que você precisa por componente
Testabilidade: Bibliotecas de snippets podem ser testadas de forma independente

Quando Exportar Snippets

Bons candidatos para exportação:

Utilitários de formatação: Datas, moedas, números de telefone
Padrões comuns de UI: Badges, avatares, indicadores de status
Elementos de marca: Componentes estilizados específicos da empresa
Padrões de acessibilidade: Combinações de ícone + texto, helpers de marcação semântica

Não recomendado para exportação:

Layouts específicos de componentes: Snippets vinculados à estrutura de um único componente
Snippets com estado: Aqueles que dependem do estado do componente (veja as limitações abaixo)
Blocos grandes de marcação: Considere um componente completo em vez disso

Limitação Crítica

Existem limitações importantes a entender ao exportar snippets de scripts de módulo.

Sem Acesso ao Estado da Instância

Snippets exportados não podem referenciar variáveis de blocos <script> de instância — eles só podem acessar constantes de nível de módulo e seus próprios parâmetros.

Por que essa limitação existe: Scripts de módulo são executados uma vez quando o módulo é carregado, não por instância de componente. O estado da instância não existe nesse 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 que falha:

themeColor é estado de instância — ele existe separadamente para cada instância de componente
Snippets de módulo são compartilhados entre todas as instâncias — eles não podem ter comportamento específico de instância
O snippet tenta acessar algo que não existe em seu escopo

Abordagem correta

Use constantes de módulo

Ao escrever snippets exportáveis, sempre use constantes ou funções de nível de módulo para quaisquer valores compartilhados ou helpers. Estes são definidos no bloco <script module> e estão disponíveis para todos os snippets exportados do módulo. Isso garante que seus snippets sejam autocontidos, previsíveis e seguros para uso em qualquer componente — sem depender de estado específico de instância.

Por exemplo:

<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}

Passe o estado como parâmetros (alternativa)

Se o seu snippet precisar trabalhar com dados dinâmicos ou específicos de instância, a melhor prática é passar esses dados como parâmetros. Isso mantém o snippet flexível e desacoplado do estado de qualquer componente específico. Ao tornar todos os valores necessários parâmetros explícitos, você garante que o snippet possa ser reutilizado em qualquer contexto, com quaisquer dados.

No exemplo a seguir, definimos um snippet que aceita um parâmetro color, permitindo que o componente pai controle a cor dinamicamente:

<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)}

Organizando Bibliotecas de Snippets

Ao construir bibliotecas de snippets, a organização é fundamental. Aqui estão alguns padrões comuns para estruturar suas exportações de snippets.

1. Bibliotecas por Domínio

Um dos padrões é agrupar snippets relacionados em arquivos específicos por domínio. É especialmente útil para utilitários de formatação ou elementos de UI comuns. Esse agrupamento lógico melhora a manutenibilidade e a clareza.

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

então você pode importar apenas o que precisa:

<!-- 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 de UI com Tema

Outro padrão é criar bibliotecas de snippets de UI com tema. É útil para sistemas de design ou elementos com identidade visual que precisam de estilização consistente em toda a aplicação.

<!-- 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 em toda a aplicação:

<!-- 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}

Versionamento e Evolução

À medida que suas bibliotecas de snippets crescem, pode ser necessário evoluir suas APIs. Um padrão comum é versionar seus arquivos de snippets, permitindo que múltiplas versões coexistam.

<!-- 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}

Isso permite uma migração gradual à medida que você melhora as implementações dos snippets.

Boas Práticas: Projetando com Snippets

Ao projetar componentes que utilizam snippets, seguir boas práticas garante que seu código permaneça manutenível, reutilizável e claro. Aqui estão os princípios-chave para orientá-lo.

1. Nomeie Snippets de Forma Descritiva

Os nomes dos snippets devem comunicar o que eles renderizam, não apenas que são snippets. Bons nomes servem como documentação inline.

<!-- 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}

Convenções de nomenclatura:

Use substantivos para renderização de entidades: userCard, productTile, commentThread
Use verbos + substantivos para ações/formatação: formatDate, renderStatus, showError
Seja específico: compactUserCard é melhor que userCard2
Use a linguagem do domínio: Se sua equipe os chama de "listings," use listingCard, não itemCard

2. Mantenha os Snippets Focados

Cada snippet deve ter um propósito claro. Snippets grandes, com múltiplas responsabilidades, tornam-se difíceis de manter e reutilizar.

Anti-padrão: 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 faz coisas demais. E se você precisar apenas do avatar em outro lugar? Ou quiser reordenar as seções? Você precisaria duplicar ou criar uma variante.

Melhor: Snippets Decompostos e Focados

<!-- 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}

Benefícios da decomposição:

Reutilizabilidade: Use userAvatar em comentários, listagens, cabeçalhos
Testabilidade: Teste a renderização do avatar de forma independente
Flexibilidade: Reordene as seções alterando userProfile
Manutenibilidade: Altere o estilo do avatar em um único lugar
Composição: Crie variantes como compactUserProfile usando peças existentes

3. Tipar as APIs dos Componentes

Para qualquer componente que outros desenvolvedores utilizarão, sempre forneça tipos TypeScript para as props dos snippets. Isso transforma a API do seu componente de documentação que pode estar desatualizada em contratos impostos.

Sem 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?
-->

Com 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>

O que isso alcança:

Autocomplete na IDE: Desenvolvedores veem os tipos dos parâmetros enquanto digitam
Erros em tempo de compilação: Snippets obrigatórios ausentes são detectados antes da execução
Autodocumentação: Comentários JSDoc aparecem nos tooltips da IDE
Segurança na refatoração: Renomeie parâmetros com confiança

4. Considere a Granularidade dos Snippets

Encontrar o nível certo de abstração é uma arte. Granularidade excessiva resulta em uma sopa de snippets. Granularidade insuficiente faz você perder reutilizabilidade.

Granularidade excessiva:

<!-- 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>

Na medida certa:

<!-- 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')}

Perguntas a fazer:

Este snippet será reutilizado mais de duas vezes?
Ele encapsula estilização ou lógica significativas?
Extraí-lo tornaria o código mais claro ou mais obscuro?

5. Use Snippets para Complexidade Condicional

Quando a lógica condicional torna seu template difícil de ler, extraia-a em 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>

Depois:

<!-- 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>

Benefícios:

Legibilidade: O template principal mostra a árvore de decisão com clareza
Manutenibilidade: Cada variante de preço é isolada e fácil de atualizar
Testabilidade: Teste cada variante de exibição de preço de forma independente
Reutilizabilidade: Use os snippets de preço em outros lugares (ex.: carrinho, resultados de busca)

6. Documente Snippets Complexos

Para snippets com comportamento não óbvio, adicione comentários 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}

Dicas da IDE mostrarão esta documentação ao usar o snippet.

Erros Comuns e Como Evitá-los

Embora os snippets sejam poderosos, há erros comuns que os desenvolvedores cometem ao usá-los. Entender essas armadilhas ajuda a evitar bugs e confusões.

1. Confusão de Escopo

O Problema: Tentar usar um snippet fora do seu escopo léxico resulta em erros de "snippet não 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 que falha: O snippet userGreeting é definido dentro do bloco if, portanto só existe dentro desse bloco. O branch else não consegue vê-lo.

Solução 1: Definir no Ancestral Comum

<!-- 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}

Solução 2: Usar Snippets Diferentes

Às vezes você realmente quer conteúdo diferente em cada branch:

<!-- 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}

Solução 3: Passar Dados em Vez 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 Definição com Renderização

O Problema: Esperar que um snippet seja renderizado apenas por ser definido.

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

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

Por que falha: A definição de um snippet é como a definição de uma função — ela cria um template, mas não o executa. Você deve renderizá-lo explicitamente.

Solução:

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

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

Modelo mental: Pense em {#snippet} como function e em {@render} como chamar essa função.

3. Esquecer o Optional Chaining para Snippets Opcionais

O Problema: Tentar renderizar um snippet opcional sem verificar se ele existe causa erros em tempo de execução.

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

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

O que acontece: Se o pai não fornecer header, header() tenta chamar undefined → erro em tempo de execução.

Solução 1: Optional Chaining (Recomendado)

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

Solução 2: Condicional Explícito

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

Quando usar cada um:

Optional chaining: Quando você não quer saída alguma se o snippet estiver ausente
Condicional: Quando você quer conteúdo de fallback

4. Passar Número ou Tipo Errado de Argumentos

O Problema: O snippet espera parâmetros, mas não os recebe (ou recebe tipos errados).

{#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')}

Sem TypeScript: Esses erros só aparecem em tempo de execução (ou produzem valores undefined silenciosamente).

Solução: Adicionar Tipos 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 Parâmetros do Snippet

O Problema: Tentar reatribuir parâmetros do snippet dentro do snippet.

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

Por que falha: Os parâmetros do snippet são imutáveis — eles são passados por valor, não por referência. Modificá-los não tem efeito na origem.

Solução: Usar State ou 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)}

Ou use $state diretamente:

<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. Recursão Infinita

O Problema: Snippets recursivos sem um caso base adequado causam estouro de pilha.

<!-- 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 que falha: Não há condição de parada — o snippet continua chamando a si mesmo indefinidamente.

Solução: Sempre Ter um 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 dados gerados pelo usuário, adicione limite de profundidade:

{#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. Uso Excessivo de Snippets

O Problema: Criar snippets para coisas que deveriam ser apenas HTML ou 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>

Quando NÃO usar snippets:

Marcação simples e pontual
Elementos HTML básicos sem lógica especial
Coisas que ficariam mais claras como HTML inline

Quando USAR snippets:

Padrões repetidos (2 ou mais vezes)
Renderização condicional complexa
Marcação que precisa ser personalizada por componentes pai
Lógica de renderização que você pode extrair para uma biblioteca compartilhada

8. Acessar Propriedades Inexistentes de Snippets

O Problema: Tratar snippets como objetos com propriedades.

<!-- 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 que falha: Os snippets são funções de renderização compiladas, não objetos em tempo de execução com propriedades acessíveis.

Solução: Snippets são para renderização, não para introspecção. Se você precisar de metadados, armazene-os separadamente:

<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)}

Referência 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>

Conclusão

O bloco {#snippet} transforma fundamentalmente a forma como pensamos sobre composição de componentes no Svelte. Ao tratar fragmentos de UI como valores de primeira classe que podem ser definidos, passados e invocados programaticamente, os snippets habilitam padrões arquiteturais que antes eram complicados ou impossíveis com o sistema baseado em slots. De projeção simples de conteúdo a estruturas recursivas complexas, de APIs de bibliotecas de componentes a padrões avançados de composição, os snippets fornecem os blocos de construção primitivos para sistemas de componentes flexíveis e de fácil manutenção.

Dominar snippets requer compreensão de suas regras de escopo, padrões de parâmetros e integração com o sistema reativo do Svelte. A capacidade de definir snippets inline, passá-los como props, exportá-los de componentes e compô-los recursivamente abre novas possibilidades para o design de APIs de componentes. Seja construindo sistemas de design com renderização baseada em variantes, implementando componentes de árvore recursivos ou criando sistemas de layout flexíveis com múltiplos slots de conteúdo, os snippets fornecem a base para expressar padrões complexos de composição com clareza e segurança de tipos.

Principais Conclusões

{#snippet} define fragmentos de template reutilizáveis com parâmetros, atuando como funções no nível do template que podem ser passadas como props, armazenadas em variáveis ou exportadas de componentes
Os parâmetros de snippet permitem passagem de dados com a sintaxe {#snippet card({ title, description })}, recebendo argumentos quando invocados via {@render card({ title: 'Hello', description: 'World' })}
O escopo segue regras léxicas - snippets acessam variáveis do escopo onde foram definidos, não do escopo de chamada, permitindo closures sobre o estado do componente
Múltiplos snippets fornecem APIs de componentes flexíveis - componentes aceitam múltiplas props de snippet para cabeçalhos, rodapés e áreas de conteúdo, habilitando layouts personalizáveis sem prop drilling
Snippets recursivos requerem casos base para evitar loops infinitos: {#if condition}{@render self(recursiveData)}{/if} garante a terminação
Segurança de tipos com TypeScript usando o tipo Snippet do pacote svelte: let { header }: { header: Snippet<[string]> } = $props() para parâmetros com verificação de tipos
Exporte snippets para uso externo listando seus nomes em uma declaração export { snippetName } dentro de um bloco <script module>, tornando-os importáveis em toda a sua aplicação como qualquer outra exportação de módulo
Snippets são reativos - eles são re-renderizados automaticamente quando qualquer estado reativo sobre o qual têm closure muda, assim como expressões de template regulares; a renderização está sempre sincronizada com o estado atual

Veja Também

Documentação Oficial do Svelte 5 - {#snippet}
$props() - Sistema de props de componentes incluindo props de snippet
TypeScript com Svelte - Definições de snippet com segurança de tipos
Padrões de Composição de Componentes - Design avançado de API de componentes
$derived - Computações reativas para lógica de seleção de snippets

Entendendo o Modelo Mental de Snippets

A Evolução dos Slots para Snippets

A Filosofia dos Snippets

O Conceito Central: Marcação como Valores

Definindo Sem Renderizar

Renderização Explícita

Por Que os Snippets Importam: A Crise de Manutenibilidade

O Custo da Duplicação de Código

O Princípio DRY em Ação

Impacto no mundo real

Parâmetros de Snippets: Renderização Orientada a Dados

O Poder da Parametrização

Passando Dados para a Marcação

Parâmetros Básicos

Múltiplos Valores Discretos

Valores Padrão de Parâmetros

Aprimoramento Progressivo

Desestruturação de Parâmetros

APIs Baseadas em Objetos

Limitação Crítica

Sem Parâmetros Rest

Escopo e Visibilidade de Snippets: Regras de Escopo Léxico

Entendendo o Escopo de Snippets

Acessando o Estado do Componente

Closure Reativa sobre Variáveis do Script

Acessando Variáveis de Loop: Closures por Iteração

Regras de Visibilidade: Escopo Léxico na Prática

O Que Pode Ver Seu Snippet

O Que Não Pode Ver Seu Snippet

Exemplo Visual de Escopo

Implicações Práticas

1. Snippets no Nível Superior para Reutilização Global

2. Snippets com Escopo para Lógica Localizada

3. Evitando Problemas de Escopo

Snippets Recursivos

Quando a Recursão Faz Sentido

Entendendo a Recursão em Snippets

Padrões de Auto-Referência

Recursão Básica: Exemplo de Contagem Regressiva

Snippets Mutuamente Recursivos

Exemplo Prático:

Estrutura de Árvore de Arquivos

Avançado

Árvore Colapsável Interativa

Boas Práticas de Recursão

1. Sempre Tenha um Caso Base

2. Rastreie a Profundidade para Evitar Estouro de Pilha

3. Considere o Desempenho para Árvores Grandes

Passando Snippets para Componentes: Inversão de Controle

O Poder da Delegação de Renderização

1. Props de Snippet Explícitas

2. Props de Snippet Implícitas

O Snippet Implícito children

Combinando Snippets Nomeados e Children

Padrões de Design de API de Componentes

1. Snippets Obrigatórios vs Opcionais

2. Parâmetros de Snippet para Contexto

Integração com TypeScript: APIs de Componentes com Tipagem Segura

Por Que Tipar Snippets?

O Tipo Snippet

Tipagem Básica de Snippets

Tipando Snippets com Parâmetros

Avançado: Snippets Genéricos para Tipagem Segura

Exemplo de Tabela Genérica

Genérico com Restrições

Props de Snippet Opcionais

Padrões de Tipagem para Casos de Uso Comuns

Padrão 1: Snippet de Dados + Renderização

Padrão 2: Children Opcionais com Fallback

Padrão 3: Múltiplos Snippets Relacionados

Boas Práticas de Segurança de Tipos

Exportando Snippets

Construindo Bibliotecas de Templates Reutilizáveis

O Problema: Localidade dos Snippets

Definindo Snippets Exportáveis

Importando e Usando Snippets Exportados

Quando Exportar Snippets

Limitação Crítica

Sem Acesso ao Estado da Instância

Abordagem correta

O Snippet Implícito `children`

O Tipo `Snippet`