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
Entender los beneficios de los componentes
Planificar los límites de los componentes

La realidad desordenada de un solo archivo

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

Problemas con archivos grandes

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

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

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

Conflictos de fusión — Varios desarrolladores editando el mismo archivo generan conflictos constantemente.

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

La solución de los 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 testeable.

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 — Cambia un componente sin afectar a los demás.

Testeabilidad — 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 múltiples 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 funciones auxiliares.

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

Este es el plan para el formulario de reservas:

Componente	Responsabilidad
`BookingForm`	Orquesta los componentes hijos, gestiona 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 de a poco. Extrae primero las piezas más obviamente reutilizables.

No sobre-ingenierices

No todo necesita ser un componente:

Demasiado granular:

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

Justo lo necesario:

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

Si estás creando componentes con solo 5 líneas que se usan una sola vez, te has excedido.

Resumen

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

Conclusiones clave:

Los archivos grandes son difíciles de navegar y mantener
Los componentes habilitan 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.