# FRONTEND_ARCHITECTURE

## Objetivo

Documentar como se integra el nuevo frontend con Tailwind dentro del proyecto actual, comenzando solo con `Home`.

## Principio de arquitectura

El rediseno no reemplaza el backend. Reemplaza la presentacion.

Por eso la arquitectura frontend debe respetar:

- rutas existentes,
- controladores existentes,
- variables dinamicas existentes,
- y puntos reales de render en las vistas PHP.

## Punto de entrada actual de Home

- Ruta: `/`
- Controlador: `HomeController::index`
- Vista principal: `app/Views/home.php`
- Layout base: `app/Views/layout/template.php`

## Flujo actual de render

1. La ruta `/` resuelve `HomeController::index`
2. El controlador obtiene SEO, slides, secciones de contenido y estado de campana
3. El controlador renderiza `app/Views/home.php`
4. `home.php` extiende `layout/template.php`
5. `home.php` compone la pagina usando parciales existentes

## Composicion actual de Home

La home actual se arma con estas piezas:

- `componentes/carrousel`
- `componentes/quienes-somos`
- `componentes/colash-servicios`
- `componentes/formacion`
- `componentes/bannerDiscipulos`
- `componentes/donacion`
- bloque inline final de "equipo de evangelizadores"

## Implicacion para el rediseno

El nuevo `Home` no debe pensarse como una sola vista monolitica. Conviene dividirlo por secciones para poder:

- integrar mejor con PHP,
- reutilizar bloques,
- comparar contra Figma por seccion,
- y evitar archivos inmanejables.

## Estrategia recomendada para Home

### Opcion preferida

Mantener:

- `HomeController::index`
- `app/Views/home.php`
- `app/Views/layout/template.php`

Y redisenar:

- el contenido de `home.php`
- los parciales asociados a Home
- y, si hace falta, el layout compartido

### Opcion a evitar por ahora

- rehacer routing
- mover logica de datos al frontend
- acoplar el diseno a HTML estatico sin contemplar variables del controlador

## Layout compartido actual

El layout actual ya controla:

- metadatos SEO
- carga de CSS global
- carga de Bootstrap CDN
- scripts de tracking
- `renderSection('contenido')`
- inclusion del footer compartido

Esto significa que cualquier rediseno del Home debe decidir explicitamente:

- si el nav va dentro del layout o de la propia pagina,
- si el footer actual se reemplaza o se refactoriza,
- y como convivira Tailwind con los assets actuales durante la migracion

## Deuda visual detectada

En el frontend actual hay mezcla de:

- estilos inline,
- bloques `<style>` dentro de vistas,
- Bootstrap,
- clases custom heredadas,
- y parciales con marcado muy acoplado

Por eso el rediseno debe usar una estrategia mas consistente desde el dia 1.

## Regla de integracion

Antes de modificar una seccion visual, revisar:

1. si usa datos dinamicos,
2. si tiene links reales a otras rutas,
3. si su contenido proviene de base de datos o de texto fijo,
4. si la misma seccion reaparece en otras pantallas

## Componentes iniciales candidatos para Home

No hace falta un catalogo separado todavia, pero si conviene reconocer estos bloques:

- Header / navegacion principal
- Hero / slider
- Seccion "Quienes somos"
- Seccion de servicios
- Seccion de formacion
- Banner CTA
- Seccion donativos
- Footer

## Regla para futuras pantallas

Cada nueva pantalla debe documentarse con el mismo minimo:

- ruta
- controlador
- vista
- layout
- parciales
- datos dinamicos
- enlace Figma

## Estado de este documento

Base inicial valida solo para `Home`. Debe crecer por pantalla, no por teoria.

## Lecturas

Las vistas de Primera lectura, Segunda lectura y Salmo extienden `Templates/main.php` y delegan la estructura visual común a `lecturas/_reading_content.php`. El parcial recibe únicamente datos de presentación ya entregados por `LecturasController`; no realiza consultas ni modifica la lógica de disponibilidad de la segunda lectura.

Laudes y Vísperas usan el mismo layout mediante `lecturas/_hours_content.php`; cada vista define solo el tipo y título. Sus rutas con fecha mantienen el contrato existente de `LecturasController`.