Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • E ECMAscript-Typescript
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 11
    • Issues 11
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • imunnic
  • ECMAscript-Typescript
  • Issues
  • #11

Closed
Open
Created Nov 04, 2025 by imunnic@imunnicMaintainer

CRUD completo

  • Descripción

A partir del HTML proporcionado, desarrollar el archivo JavaScript necesario para implementar un gestor completo de recursos sanitarios, conectado a una API REST.

El sistema debe permitir:

  1. Navegar entre los distintos recursos obtenidos de api/recursos.
  2. Visualizar los datos del recurso actual en un formulario editable.
  3. Actualizar (PATCH) los datos de un recurso pulsando el botón “Guardar cambios”.
  4. Añadir un nuevo recurso (POST) mediante un formulario en un modal, que se abre al pulsar el botón “Nuevo recurso”.
  5. Mostrar mensajes de confirmación o error tras cada operación.

El archivo HTML no debe modificarse.

  • Valor que aporta

Este ejercicio integra todos los conceptos clave de asincronía y comunicación con APIs REST:

  • Lectura y navegación de datos (GET).

  • Edición parcial (PATCH).

  • Alta de nuevos elementos (POST). Además, introduce una capa de interfaz más avanzada mediante un modal, reforzando la separación entre lógica, datos y presentación.

  • Criterios de aceptación

  • No se modifica el archivo HTML.

  • Al cargar la página, se obtienen los recursos desde api/recursos.

  • El primer recurso se muestra automáticamente en el formulario.

  • Los botones “Anterior” y “Siguiente” permiten navegar por la lista.

  • El formulario principal muestra:

    • Tipo de recurso.
    • Nombre.
    • Disponibilidad.
  • El botón “Guardar cambios” realiza una petición PATCH al recurso actual (api/recursos/{id}).

  • El botón “Nuevo recurso” abre un modal con un formulario de creación.

  • Al enviar el formulario del modal, se realiza un POST con los datos introducidos.

  • Se muestran mensajes de éxito o error tras cada operación (GET, PATCH, POST).

  • El modal se cierra automáticamente al crear un recurso nuevo.

  • No se recarga la página en ningún momento.

  • Pruebas

  1. Al abrir la página, se muestran los datos del primer recurso de la lista.

  2. Los botones “Anterior” y “Siguiente” cambian los datos del formulario.

  3. Si se modifica algún campo y se pulsa “Guardar cambios”, se hace un PATCH correcto.

  4. Si se pulsa “Nuevo recurso”, aparece el modal con un formulario vacío.

  5. Al enviar el formulario del modal:

    • Se realiza un POST a la API.
    • Se muestra el mensaje “Recurso creado correctamente”.
    • El modal se cierra.
    • El nuevo recurso se añade a la lista de navegación.
  6. Ante errores de red o validación, se muestran mensajes de error sin romper la app.

  • Tiempo estimado: 60–75 min

  • Elementos relacionados: #8, #9, #10, #6

Assignee
Assign to
Time tracking