El problema del archivo que crece

El formulario de reservas funciona, pero mira BookingForm.svelte. Se está haciendo largo. Campos de contacto, selección de fecha/hora, opciones de servicio, complementos, notas, validación — todo en un solo archivo. A medida que crecen las funcionalidades, esto se vuelve imposible de manejar.

Lo que aprenderás

Reconocer cuándo los archivos son demasiado grandes
Comprender los beneficios de los componentes
Planificar los límites de los componentes

La realidad caótica de un solo archivo

Esto es lo que sucede sin 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 archivo podría alcanzar fácilmente las 500+ líneas. Encontrar cualquier cosa se convierte en una búsqueda del tesoro.

Problemas con los archivos grandes

Difícil de navegar — ¿Dónde está la lógica de los horarios? Scroll, scroll, scroll...

Difícil de probar — No puedes probar la tarjeta de servicio de forma aislada.

Sin reutilización — ¿Necesitas las tarjetas de servicio en otro lugar? Copia y pega el código.

Conflictos en merge — Múltiples desarrolladores editando el mismo archivo generan conflictos constantemente.

Comprensión lenta — Los nuevos miembros del equipo tardan más en entender el código.

La solución con componentes

Divide el formulario en piezas enfocadas:

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 es pequeño, enfocado y comprobable.

Beneficios de los componentes

Responsabilidad única — Cada componente hace una sola cosa bien.

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

Reutilización — Usa el mismo componente en múltiples 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}

Aislamiento — Modifica un componente sin afectar a los demás.

Comprobabilidad — Prueba los componentes de forma individual.

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

Cómo identificar componentes

Busca estas señales:

Patrones repetidos — La misma estructura aparece varias veces.

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

→ Extraer a <ServiceCard />

Agrupaciones lógicas — Campos relacionados que forman una unidad.

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

→ Extraer a <ContactFields />

Lógica compleja — Secciones con su propio estado y helpers.

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

→ Extraer a <TimeSelector />

Potencial de reutilización — Algo que podrías usar en otro lugar.

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

→ Extraer a <PriceBadge />

Límites de componentes para BookIt

Aquí está el plan para el formulario de reservas:

Componente	Responsabilidad
`BookingForm`	Orquesta los componentes hijos, maneja el envío
`ServiceCard`	Muestra una opción de servicio individual
`PriceBadge`	Formatea y muestra precios
`BookingPreview`	Muestra un resumen de los datos ingresados

Empieza pequeño. Extrae primero las piezas más obviamente reutilizables.

No sobrediseñes

No todo necesita ser un componente:

Demasiado granular:

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

En su justa medida:

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

Si estás creando componentes de solo 5 líneas que se usan una sola vez, has ido demasiado lejos.

Resumen

Los componentes grandes de un solo archivo se vuelven difíciles de mantener. Dividir la interfaz en componentes más pequeños mejora la organización, permite la reutilización y facilita las pruebas. Busca patrones repetidos, agrupaciones lógicas y lógica compleja aislada.

Puntos clave:

Los archivos grandes son difíciles de navegar y mantener
Los componentes permiten la reutilización y el aislamiento
Busca patrones repetidos y agrupaciones lógicas
No extraigas en exceso — encuentra el equilibrio adecuado

Próximos pasos

Extraigamos el primer componente. Continúa con Crear el componente ServiceCard para construir una visualización de servicio reutilizable.