Aplicación Angular de profesores con componentes compartidos

Aprende cómo la visión de profesores en Angular coordina dos aplicaciones con componentes compartidos, un backend común y arranque ágil con Nx Console y Nx Cloud. Aquí verás cómo un cambio en servicios, modelos o UI repercute en ambas apps al mismo tiempo, optimizando trabajo y evitando duplicación de código.

¿Cómo se organiza la aplicación de profesores en Angular y Nx?

La segunda app se encuentra en packages, app dos, y muestra un panel de profesores con navegación entre dos rutas: gestión de cursos e inscripciones por curso. Actúa como pivote con el Note JS Server, compartiendo recursos con la primera app.

• Rutas clave: gestión de cursos e inscripciones por curso.
• Componentes compartidos: tabla de inscripciones, tarjeta del curso y botón cuando corresponde.
• Carpeta UI compartida: UI shared centraliza tarjeta, tabla y estilos comunes.
• Lógica en TS: cada vista tiene su controlador, con modelos como curso y un Api Service ya usado en la app uno.
• Imports en Angular diecisiete: componentes se importan directamente en cada vista.
• Linting: el constructor puede mostrar errores que se corrigen luego.

¿Qué componentes se reutilizan entre apps?

• Tabla compartida: listados y, según el caso, acciones del CRUD.
• Tarjeta de curso: misma presentación en ambas apps.
• Botón: solo donde la lógica de negocio lo necesita.

¿Cómo ayuda el modelo y el Api Service?

• Modelo curso: tipa datos y uniforma el intercambio.
• Api Service: centraliza llamadas al backend, evitando duplicaciones.

¿Qué flujo cubre el CRUD de cursos y cómo validarlo?

La gestión de cursos usa un formulario reactivo: el botón de crear permanece deshabilitado si no se cumplen las condiciones. La tabla compartida ofrece el CRUD completo.

• Create: crear un curso desde el formulario.
• Read: visualizar cursos existentes en tabla y tarjetas.
• Update: editar desde acciones de la tabla.
• Delete: eliminar registros cuando sea necesario.

Importante: en la pantalla de profesores no hay botón de inscripción en las tarjetas, porque no corresponde a su lógica de negocio.

¿Cómo se ven las inscripciones por curso?

• Un select permite elegir el curso y ver sus inscripciones.
• Una tarjeta general y una tabla sin acciones muestran la información relevante.

¿Qué datos prácticos se mencionan?

• Validación: el botón crear se habilita solo si el formulario es válido.
• Flujo completo: crear, ver, editar y eliminar en una misma vista.

¿Cómo sincroniza todo con el mismo backend y qué herramientas aceleran?

Se arranca el server con Nx Console y se espera a que esté en localhost 3000. Luego se abren la app uno en 4200 y la app dos en 4201. La velocidad mejora gracias a la caché de Nx Cloud, que guarda resultados en memoria.

• Puertos: 3000 para backend, 4200 para app uno, 4201 para app dos.
• Rendimiento: Nx Cloud acelera el ciclo de desarrollo con caché.
• Pivote: ambas apps consultan el mismo backend, sincronizando cambios.

¿Qué demuestra el ejemplo de “Angular con Firebase”?

• Se crea un curso “Angular con Firebase” y aparece la nueva tarjeta.
• Desde la app uno, un usuario puede inscribirse.
• En la app dos, en inscripciones por curso, se ve “Alice Cooper” recién inscripta.
• Conclusión operativa: lo que ocurre en una pantalla impacta en la otra por compartir el mismo backend.

¿Qué pasa al modificar componentes compartidos?

• Se cambia el color de la etiqueta de profesores en el CSS de la tarjeta en UI shared (clase course teacher).
• El cambio se refleja de inmediato en ambas aplicaciones.
• Valor: una sola modificación afecta múltiples proyectos, ahorrando tiempo y código.

¿Qué decisiones de negocio son solo educativas?

• Selector de usuario actual expuesto para simplificar pruebas: en producción habría login.
• Modificaciones abiertas a cualquiera: en la vida real habría restricciones y permisos.

¿Te gustaría ver otras mejoras en componentes compartidos o flujos de validación? Cuéntalo en los comentarios y propón qué optimizar a continuación.