O Problema da Complexidade

Aplicações foram entregues em React que se tornaram impossíveis de manter, apps Vue onde o fluxo de dados era opaco, e apps Angular onde implementar uma funcionalidade simples levava uma semana porque os efeitos colaterais eram impossíveis de rastrear.

Todo projeto começou simples—mas a complexidade sempre encontrou seu caminho.

O problema não era o framework em si; era que os frameworks permitiam que a complexidade se infiltrasse silenciosamente. Nada impedia adicionar mais uma store global. Nada avisava quando um componente dependia de dezessete partes diferentes do estado. Nada forçava a considerar onde os dados viviam ou como fluíam.

O Svelte 5 é diferente—não porque seja "mágico", mas porque é opinativo de formas que tornam a simplicidade o caminho padrão.

Esta série se concentra em construir sistemas que permaneçam calmos—não apenas no começo, mas após seis meses, um ano, ou mesmo quando os membros da equipe mudam.

O Que CALM Significa

CALM é ao mesmo tempo um acrônimo e uma promessa:

- **Contained (Contido):** Cada parte do estado tem um único proprietário explícito.
- **Automatic (Automático):** A reatividade acontece sem configuração manual.
- **Local:** O estado vive o mais próximo possível de onde é usado.
- **Minimal (Mínimo):** Cada dependência, abstração e funcionalidade deve justificar seu lugar.

Juntos, esses princípios definem um modelo mental que é fácil de entender, previne complexidade acidental, permite modificar funcionalidades com confiança e garante a manutenibilidade a longo prazo

`Contained:` Propriedade Que Você Consegue Ver

O estado pertence a um lugar específico. Não "em algum lugar no app." Não "em uma store que qualquer coisa pode acessar." O estado deve sempre ter um lar claro. Um lugar para o qual você possa apontar.

+---------------------+
|  +page.server.ts    |
|   (authoritative)   |
+----------+----------+
           |
           v data flows down
+---------------------+
|   +page.svelte      |
|  $state (UI only)   |
+----------+----------+
           |
           v props
+---------------------+
|  Child Components   |
|  (read via props)   |
+---------------------+

One owner, many readers, controlled mutation

No Svelte 5 com SvelteKit, o estado é contido por padrão:

Estado de rota vive em funções load e componentes de página
Estado de componente vive no componente que precisa dele
Estado global é raro e existe apenas quando explicitamente necessário

<!-- Component with contained state -->
<script>
	let isOpen = $state(false)
</script>

<button onclick={() => (isOpen = !isOpen)}> Toggle </button>
{#if isOpen}
	<div class="dropdown">...</div>
{/if}

A propriedade agora é explícita e rastreável. Remover um componente remove seu estado. Novos desenvolvedores conseguem entendê-lo olhando para uma única pasta.

Quando você olha para um componente, deve ser capaz de responder: "De onde vêm esses dados?" Se a resposta for "eu teria que verificar cinco arquivos diferentes," algo deu errado.

Estado contido significa:

Você pode entender um componente lendo-o
Você pode deletar uma rota sem quebrar partes distantes do app
Você pode integrar um novo desenvolvedor mostrando a ele uma única pasta

`Automatic:` Reatividade Sem Esforço

A reatividade deve ser automática. Você não deveria precisar se lembrar de chamar setState. Você não deveria precisar envolver coisas em useMemo para evitar re-renderizações. Você não deveria precisar pensar em arrays de dependências.

    $state            $derived             UI
+--------------+   +--------------+   +--------------+
|  count = 0   | > | doubled = 0  | > | renders "0"  |
+--------------+   +--------------+   +--------------+
       |
       | count++
       v
+--------------+   +--------------+   +--------------+
|  count = 1   | > | doubled = 2  | > | renders "2"  |
+--------------+   +--------------+   +--------------+

No dependency arrays. No manual subscriptions. It just works.

As runes do Svelte 5 tornam a reatividade automática:

<script>
	let count = $state(0)
	let doubled = $derived(count * 2)
</script>

<button onclick={() => count++}>
	{count} × 2 = {doubled}
</button>

Você muda count. A interface atualiza. Você não precisa pensar nisso.

Isso não é preguiça—é correção. Reatividade manual é uma fonte de bugs. Dependências esquecidas. Closures desatualizadas. Re-renderizações desnecessárias. O Svelte elimina essa categoria de problemas.

Reatividade automática significa:

Menos código para escrever
Menos bugs para corrigir
Mais tempo para pensar no seu problema real

`Local:` Mantenha o Estado Onde Ele Pertence

Pense localmente. Aja localmente. O estado deve viver o mais próximo possível de onde é usado.

 X Premature lifting          OK Local-first

+-------------------+        +-------------------+
|       App         |        |       App         |
| isOpen = $state   |        |                   |
+---------+---------+        +---------+---------+
          |                            |
    +-----+-----+                +-----+-----+
    |           |                |           |
    v           v                v           v
+-------+   +-------+        +-------+   +-------+
|  Nav  |   | Main  |        |  Nav  |   | Main  |
+-------+   +---+---+        +-------+   +---+---+
                |                            |
                v                            v
          +-----------+            +------------------+
          | Dropdown  |            |    Dropdown      |
          | (needs    |            | isOpen = $state  |
          |  isOpen)  |            |   (owns it!)     |
          +-----------+            +------------------+

State lives where it's used. Lift only when proven necessary.

O instinto de "elevar o estado" ou "colocá-lo em uma store" costuma ser prematuro. A maioria do estado não precisa ser compartilhada. A maioria do estado é usada por um componente, ou uma rota, ou uma pequena árvore de componentes.

O pensamento local-first significa:

Comece com $state no componente que precisa dele
Só eleve quando você realmente precisar compartilhar
Só vá global quando tiver provado que o local não funciona

<!-- This is usually enough -->
<script>
	let isOpen = $state(false)
</script>

<button onclick={() => (isOpen = !isOpen)}> Toggle </button>

{#if isOpen}
	<div class="dropdown">...</div>
{/if}

Sem store. Sem contexto. Sem prop drilling. Apenas o estado onde ele é necessário.

Estado global não é mau—é apenas caro. Cada parte do estado global é uma dependência que qualquer componente pode ter. É algo que todos na equipe precisam entender. É um ponto de acoplamento que torna a refatoração mais difícil.

Local-first significa pagar esse custo apenas quando você obtém valor real em troca.

`Minimal:` Cada Dependência Deve Justificar Seu Lugar

O melhor código é o código que você não escreveu. A melhor abstração é aquela que você não criou.

+------------------------------------------+
|       Need state management?             |
+---------------------+--------------------+
                      |
         +------------+------------+
         |                         |
         v                         v
+-----------------+      +-----------------+
| One component?  |      | Multiple routes?|
+--------+--------+      +--------+--------+
         |                        |
         v                        v
+-----------------+      +-----------------+
|   Use $state    |      |    Use load     |
|  (no library)   |      |    functions    |
+-----------------+      +-----------------+

Every abstraction must earn its place. Start simple.

Minimal significa:

Não adicione uma biblioteca até ter sentido a dor que ela resolve
Não crie uma abstração até ter escrito o mesmo código três vezes
Não otimize até ter medido

O Svelte ajuda aqui também. Como a reatividade está embutida, você não precisa de bibliotecas de gerenciamento de estado. Como o compilador é inteligente, você não precisa de wrappers de memoização. Como a sintaxe é próxima ao HTML, você não precisa de bibliotecas de componentes para coisas básicas.

Minimal não significa "nunca use bibliotecas." Significa que cada dependência deve justificar seu lugar. Cada abstração deve justificar sua existência.

<!-- You probably don't need a Modal component library -->
<dialog bind:this={dialog}>
	<h2>Are you sure?</h2>
	<button onclick={() => dialog.close()}>Cancel</button>
	<button onclick={confirm}>Confirm</button>
</dialog>

A Promessa

Esta série vai te ensinar a construir sistemas CALM com Svelte 5. Ao final, você terá:

Um modelo mental — Você entenderá por que certos padrões funcionam e outros não. Não apenas "como usar $state", mas "quando o estado deve existir e onde deve viver."

Um conjunto de padrões — Abordagens concretas e reutilizáveis para problemas comuns. Carregamento de dados. Manipulação de formulários. Limites de erro. Comunicação entre componentes. Padrões que escalam.

Confiança — O conhecimento de que você não está deixando passar algo importante. Que você não precisa aprender mais doze técnicas avançadas. Que o que você sabe é suficiente.

Não vamos cobrir todos os recursos. Vamos cobrir os recursos que importam para construir sistemas calmos. O restante você pode aprender quando—e se—precisar.

O Que Não Faremos

Não vamos:

Correr atrás de cada novo recurso — APIs experimentais são empolgantes, mas sistemas calmos são construídos sobre fundações estáveis
Abstrair prematuramente — Vamos escrever código "entediante" que seja fácil de entender
Otimizar antes de medir — Vamos confiar no compilador até termos evidências de que não deveríamos
Adicionar complexidade para parecer produtivo — Vamos resistir ao impulso de arquitetar quando deveríamos estar construindo

O Caminho

Aqui está o que está por vir:

Fundação — As runes que você realmente precisa (dica: são seis)
Modelos Mentais — Como pensar sobre fluxo de dados, mutação, estado derivado e efeitos colaterais
Construção — Padrões práticos de SvelteKit para roteamento, carregamento de dados, manipulação de formulários e comunicação entre componentes
Manutenção — Padrões que mantêm seu app simples enquanto ele cresce, incluindo os erros a evitar
Capstone — Uma aplicação completa que demonstra tudo, para que você possa ver como as peças se encaixam

Cada post se constrói sobre o anterior. Cada padrão justifica seu lugar. Ao final, você terá tudo o que precisa.

Para Quem É Isso

Esta série é para desenvolvedores que:

Já foram prejudicados pela complexidade e querem algo mais simples
São novos no Svelte e querem começar com bons hábitos
Conhecem o Svelte 4 e querem entender o jeito Svelte 5 de fazer as coisas
Estão cansados de tutoriais que mostram brinquedos em vez de padrões reais

Não é para desenvolvedores que:

Querem dominar cada canto do framework
Precisam saber sobre recursos experimentais agora
Preferem documentação de referência abrangente a guias opinativos

Vamos Começar

Calmo não é sobre trabalhar mais devagar. É sobre construir sistemas que não lutam contra você. Sistemas onde o código que você escreveu seis meses atrás ainda faz sentido. Sistemas onde novos recursos vão para o lugar óbvio.

O Svelte 5 torna isso possível. Esta série vai mostrar como.

A seguir: as seis runes que você realmente precisa. Nem mais, nem menos.

Bem-vindo ao CALM com Svelte 5.