O Problema do Arquivo Crescente

O formulário de reserva funciona, mas olhe para BookingForm.svelte. Ele está ficando longo. Campos de contato, seleção de data/hora, escolhas de serviço, complementos, notas, validação — tudo em um único arquivo. À medida que as funcionalidades crescem, isso se torna ingerenciável.

O Que Você Vai Aprender

Reconhecer quando os arquivos estão grandes demais
Entender os benefícios dos componentes
Planejar os limites dos componentes

A Realidade Bagunçada de um Único Arquivo

Veja o que acontece sem componentes:

<!-- filename: src/lib/components/BookingForm.svelte -->
<script>
  // 30+ lines of state declarations
  let customerName = $state('');
  let customerEmail = $state('');
  let customerPhone = $state('');
  let bookingDate = $state('');
  let selectedTime = $state('');
  let selectedService = $state('');
  let selectedAddOns = $state([]);
  let notes = $state('');
  let agreeToTerms = $state(false);
  // ... more state
  
  // 50+ lines of helper functions
  function generateTimeSlots() { /* ... */ }
  function formatDate(date) { /* ... */ }
  function formatTime(hour, minute) { /* ... */ }
  function calculateTotal() { /* ... */ }
  function validateEmail(email) { /* ... */ }
  // ... more functions
  
  // Services data
  const services = [/* 20+ lines */];
  const addOns = [/* 10+ lines */];
  const timeSlots = generateTimeSlots();
</script>

<!-- 200+ lines of markup -->
<form>
  <fieldset>
    <legend>Contact Information</legend>
    <!-- 30 lines of contact fields -->
  </fieldset>
  
  <fieldset>
    <legend>Appointment Details</legend>
    <!-- 40 lines of date/time -->
  </fieldset>
  
  <fieldset>
    <legend>Select a Service</legend>
    <!-- 50 lines of service cards -->
  </fieldset>
  
  <!-- More sections... -->
</form>

<!-- 100+ lines of styles -->
<style>
  /* Styles for everything */
</style>

Este arquivo poderia facilmente chegar a 500+ linhas. Encontrar qualquer coisa vira uma caça ao tesouro.

Problemas com Arquivos Grandes

Difícil de navegar — Onde está a lógica do horário? Rolar, rolar, rolar...

Difícil de testar — Você não consegue testar o card de serviço isoladamente.

Sem reutilização — Precisa dos cards de serviço em outro lugar? Copie e cole o código.

Conflitos de merge — Múltiplos desenvolvedores editando o mesmo arquivo entram em conflito constantemente.

Compreensão lenta — Novos membros da equipe demoram mais para entender.

A Solução com Componentes

Divida o formulário em partes focadas:

BookingForm.svelte
├── ContactFields.svelte      (name, email, phone)
├── DateTimePicker.svelte     (date and time selection)
├── ServiceSelector.svelte    (service cards)
│   └── ServiceCard.svelte    (individual card)
├── AddOnSelector.svelte      (checkbox list)
├── NotesField.svelte         (textarea)
└── PriceSummary.svelte       (total calculation)

Cada componente é pequeno, focado e testável.

Benefícios dos Componentes

Responsabilidade única — Cada componente faz uma coisa bem feita.

<!-- ServiceCard only displays a service -->
<ServiceCard service={lawnMowing} selected={true} />

Reutilização — Use o mesmo componente em múltiplos lugares.

<!-- On the services listing page -->
{#each services as service}
  <ServiceCard {service} />
{/each}

<!-- In the booking form -->
{#each services as service}
  <ServiceCard {service} selected={selectedService === service.slug} />
{/each}

Isolamento — Altere um componente sem afetar os outros.

Testabilidade — Teste os componentes individualmente.

// Test ServiceCard in isolation
test('displays service name', () => {
  render(ServiceCard, { props: { service: mockService } });
  expect(screen.getByText('Lawn Mowing')).toBeInTheDocument();
});

Como Identificar Componentes

Fique atento a estes sinais:

Padrões repetidos — A mesma estrutura aparece várias vezes.

<!-- This pattern repeats for each service -->
<label class="service-card">
  <input type="radio" />
  <h3>{service.name}</h3>
  <p>{service.description}</p>
  <span>${service.price}</span>
</label>

→ Extrair para <ServiceCard />

Agrupamentos lógicos — Campos relacionados que formam uma unidade.

<!-- Contact info is a logical group -->
<input name="name" />
<input name="email" />
<input name="phone" />

→ Extrair para <ContactFields />

Lógica complexa — Seções com seu próprio estado e auxiliares.

<!-- Time selection has its own logic -->
<script>
  function generateTimeSlots() { /* complex */ }
  function formatTime() { /* complex */ }
</script>

→ Extrair para <TimeSelector />

Potencial de reutilização — Algo que você pode usar em outro lugar.

<!-- Price badge could appear anywhere -->
<span class="price">${price}</span>

→ Extrair para <PriceBadge />

Limites de Componentes para o BookIt

Este é o plano para o formulário de reserva:

Componente	Responsabilidade
`BookingForm`	Orquestra os componentes filhos, gerencia o envio
`ServiceCard`	Exibe uma única opção de serviço
`PriceBadge`	Formata e exibe preços
`BookingPreview`	Mostra o resumo dos dados inseridos

Comece pequeno. Extraia primeiro as partes mais obviamente reutilizáveis.

Não Complique Demais

Nem tudo precisa ser um componente:

Granular demais:

<!-- Overkill -->
<FormLabel text="Email" />
<FormInput type="email" />
<FormError message={emailError} />

Na medida certa:

<!-- A single cohesive field component -->
<TextField 
  label="Email" 
  type="email" 
  bind:value={email} 
  error={emailError} 
/>

Se você está criando componentes com apenas 5 linhas que são usados uma única vez, você foi longe demais.

Resumo

Componentes grandes em um único arquivo se tornam difíceis de manter. Dividir a UI em componentes menores melhora a organização, permite a reutilização e facilita os testes. Fique atento a padrões repetidos, agrupamentos lógicos e lógica complexa isolada.

Principais conclusões:

Arquivos grandes são difíceis de navegar e manter
Componentes permitem reutilização e isolamento
Fique atento a padrões repetidos e agrupamentos lógicos
Não extraia em excesso — encontre o equilíbrio certo

Próximos Passos

Vamos extrair o primeiro componente. Continue com Criar o Componente ServiceCard para construir uma exibição de serviço reutilizável.