Saltar a contenido

Angular: fundamentos para construir aplicaciones web modernas

Presentaciones del módulo (descargables)

06 · Angular: fundamentos para construir aplicaciones web modernas (.pptx) 07 · Taller estudiante-front (.pptx)

De las páginas enriquecidas a una SPA organizada por componentes, modelos, servicios y rutas.

Pregunta guía

¿Cómo pasamos de manipular una página manualmente a diseñar una aplicación mantenible?

Si es tu primer contacto con el desarrollo frontend, empieza por la Teoría del frontend.

La respuesta de esta sección es una idea: dividir la interfaz en piezas con responsabilidades claras — vista, estado, datos y navegación.

Ruta de la sección

# Página Qué se aprende
— Teoría del frontend Frontend vs. backend, modelos de renderizado (MPA, SPA, SSR, SSG), cómo funciona una SPA, componentes, herramientas y calidad
0–2 Generalidades (esta página) Cómo eran las páginas enriquecidas, qué es Angular, qué es una SPA y qué cambia en la arquitectura
3 Proyecto base Qué contiene un proyecto Angular y primer "Hola Mundo"
4 Componentes La unidad fundamental: qué son, para qué sirven y cómo se componen
5 Modelos Contratos para entender los datos
6 Servicios Lógica reutilizable y acceso a datos con HttpClient
7 Routing Navegación dentro de la SPA
8 Formularios Capturar y validar información
9 Excepciones Manejar errores sin romper la experiencia
★ Taller estudiante-front Todo lo anterior funcionando en una app real conectada a Spring Boot, con sus repositorios públicos
— Caso de estudio Una aplicación real de seguimiento catastral leída con estas piezas

Código de ejemplo del curso

Toda la sección se aplica en el Taller estudiante-front, cuyo código es público:

Mapa arquitectónico: ¿cómo evolucionó la web?

La responsabilidad de construir la interfaz se desplazó hacia el navegador.

flowchart LR
    N["Navegador<br/>solicita una URL y muestra el HTML recibido"] <-- "HTTP · HTML" --> S["Servidor web<br/>consulta datos y genera cada vista"]
    J["JavaScript + AJAX<br/>enriquece la página y actualiza fragmentos"] --- N
    S --> DB[("Base de datos<br/>persiste la información del negocio")]
flowchart LR
    subgraph A["Angular en el navegador<br/>construye vistas y conserva el estado de la interfaz"]
        R[Router]
        C[Componentes]
        SV[Servicios]
    end
    A <-- "HTTP · JSON" --> API["API REST<br/>expone operaciones y reglas del negocio"]
    API --> DB[("Base de datos<br/>permanece protegida detrás de la API")]

La idea central

Antes el servidor entregaba vistas; ahora Angular compone la experiencia y la API entrega datos.

0. Antes de Angular: ¿cómo eran las páginas enriquecidas?

Del documento enlazado a la aplicación interactiva.

La evolución ocurrió por capas, cada una sumando una responsabilidad:

Capa Responsabilidad
HTML Estructura y contenido de la página
CSS Presentación, distribución y apariencia
JavaScript Interacción y cambio del DOM
Servidor Generaba páginas completas o fragmentos
AJAX Actualizaba zonas sin recargar todo
Problema Lógica, eventos y datos crecían sin una estructura común

El ciclo típico de una página enriquecida era:

  1. El navegador solicita una URL.
  2. El servidor devuelve HTML.
  3. JavaScript agrega comportamiento.
  4. AJAX solicita nuevos datos.
  5. El DOM se modifica manualmente.
  6. → Necesidad de un framework.

Así se veía el paso 5 con lo que aprendimos en JavaScript:

fetch('/api/students')
  .then(res => res.json())
  .then(students => {
    const lista = document.querySelector('#lista');
    lista.innerHTML = '';
    students.forEach(s => {
      const li = document.createElement('li');
      li.textContent = `${s.name} - ${s.email}`;
      lista.appendChild(li);
    });
  });

Funciona. Pero cuando hay veinte pantallas, cada una con sus selectores, eventos y llamadas fetch, nadie sabe dónde vive cada regla ni qué se rompe al cambiar un id del HTML.

Idea clave

Una página enriquecida era interactiva, pero no necesariamente estaba organizada como una aplicación.

1. ¿Qué es Angular y para qué sirve?

Framework para aplicaciones web de una sola página (SPA).

  • Un framework completo

    Angular aporta estructura, herramientas y convenciones para construir aplicaciones de frontend con TypeScript.

    UI + navegación + datos + formularios

  • ¿Qué significa SPA?

    Single Page Application: se carga una base HTML y la interfaz cambia en el navegador sin pedir una página completa por cada navegación.

    URL cambia → Router cambia la vista

  • ¿Para qué sirve?

    Para crear interfaces complejas y mantenibles: paneles, sistemas empresariales, portales y aplicaciones conectadas a APIs.

    misma estructura para todo el equipo

  • Cómo organiza la aplicación

    Separa la interfaz en componentes; la información en modelos; la lógica y acceso a datos en servicios; la navegación en rutas.

    Componentes → Servicios → API

Analogía

Una SPA es un escenario fijo: Angular cambia actores y escenas sin reconstruir todo el teatro.

¿Por qué TypeScript?

TypeScript es JavaScript con tipos. Lo que en JavaScript descubrimos al ejecutar (un undefined, un campo mal escrito), TypeScript lo detecta al compilar. Para quien viene de Java resulta familiar: clases, interfaces, genéricos y modificadores de acceso.

AngularJS ≠ Angular

En internet aparecerán respuestas de AngularJS (ng-controller, $scope): es otro framework, anterior a 2016, y no aplica. Angular (2+) está basado en componentes y TypeScript.

2. Antes vs. ahora: un cambio de arquitectura

De páginas servidas a una aplicación frontend por capas.

① Antes: cada URL pedía una página · SERVIDOR

El servidor ejecutaba lógica, consultaba datos y devolvía una página HTML completa para cada URL. Es lo que hicimos con Thymeleaf.

✅ Ventajas ❌ Desventajas
Renderizado inicial directo Recargas frecuentes
Lógica centralizada en servidor Vista acoplada al servidor
Menos JavaScript en cliente Experiencia menos fluida

② Transición: JavaScript + AJAX · DOM

Se empezaron a pedir datos en segundo plano y a modificar fragmentos del DOM. La experiencia mejoró, pero el código podía terminar disperso entre eventos y selectores.

Más interacción, pero sin una arquitectura uniforme.

③ Ahora: Angular controla la SPA · FRONTEND

Angular carga la aplicación; Router, componentes y servicios actualizan la experiencia y consumen una API.

✅ Ventajas ❌ Desventajas
Navegación fluida Mayor complejidad inicial
Piezas reutilizables Estado en el cliente
Frontend y API separados Exige cuidar rendimiento y seguridad

④ Toque arquitectónico: responsabilidades separadas · CAPAS

Pieza Responsabilidad
Vista y componentes Presentan
Modelos Describen datos
Servicios Resuelven lógica y comunicación
Router Coordina navegación
Backend Conserva reglas y persistencia

Menor acoplamiento, mayor reutilización y pruebas más sencillas.

La misma separación por capas que construimos en Backend con Spring Boot se repite en el frontend:

Backend (Spring) Frontend (Angular)
@RestController Componente
@Service Servicio (@Injectable)
DTO Modelo (interface)
Mapeo de URL (@GetMapping) Ruta (Routes)

Idea transversal

Separar responsabilidades reduce el impacto del cambio.

Referencias