Cuando una aplicación permite crear y editar registros, el siguiente paso natural es implementar la opción de eliminar. En el contexto de una app de rodadas ciclistas, cancelar un evento es una acción crítica e irreversible que requiere tanto una implementación técnica sólida como una comunicación clara al usuario.
¿Cómo se agrega el botón de eliminar en la vista?
El punto de partida es el archivo rides.page.html, donde ya existe un botón de editar. A partir de ese botón se crea uno nuevo con las siguientes modificaciones [01:00]:
- El texto cambia de "editar" a "eliminar".
- El ícono se reemplaza por
trash, que representa visualmente la acción de borrar.
- Se le asigna el color
danger (rojo) para advertir que la acción es irreversible.
- En lugar de usar
routerLink, se utiliza un evento de clic que llama al método delete pasándole el ride.id.
Este cambio de routerLink a un evento de clic es importante porque no se necesita redirigir a otra página; la eliminación ocurre directamente desde la lista.
¿Qué diferencia hay entre la petición DELETE y PUT en la API?
Si observamos la API desde Postman, la petición DELETE es muy similar a la de PUT: solo necesita recibir el ID del elemento que se quiere eliminar [01:30]. No se envía un cuerpo con datos adicionales, únicamente el identificador del registro.
¿Cómo se implementa el método delete en el servicio?
Dentro del archivo services/ride.ts, se toma como base el método update, se copia y se realizan estos ajustes [02:05]:
- Se renombra a
delete.
- En lugar de recibir un objeto
ride completo, recibe únicamente el ID.
- Se cambia el verbo HTTP de
put a delete.
- Se pasa un solo parámetro: el ID del recurso a eliminar.
typescript
delete(id: number) {
return this.http.delete(${this.apiUrl}/${id});
}
Este patrón sigue la convención RESTful donde el método HTTP DELETE combinado con el identificador en la URL es suficiente para indicar qué recurso debe eliminarse.
¿Por qué es crítico notificar al usuario sobre el resultado?
De vuelta en rides.page.ts, el método delete llama a this.rideService.delete(id) y se suscribe al observable para manejar dos escenarios [02:40]:
- Éxito: se muestra un
alert con el mensaje "eliminado con éxito" y se ejecuta this.getRides() para refrescar la lista automáticamente.
- Error: se muestra una alerta indicando "no se pudo eliminar la rodada" y se registra el error en
console.log para que el desarrollador pueda diagnosticar el problema.
typescript
delete(id: number) {
this.rideService.delete(id).subscribe(
(data) => {
alert('Eliminado con éxito');
this.getRides();
},
(error) => {
alert('No se pudo eliminar la rodada');
console.log(error);
}
);
}
La notificación al usuario es fundamental en este tipo de operaciones. Si la eliminación falla silenciosamente y el usuario cree que se canceló la rodada, los participantes podrían llegar al punto de encuentro sin líder o sin organización [03:10]. Este es un ejemplo real de por qué el manejo de errores no es opcional.
¿Cómo se refleja la eliminación en la interfaz?
Al llamar a this.getRides() después de una eliminación exitosa, la lista se actualiza inmediatamente. En la demostración, la rodada "viaje a Alaska2" desaparece de la vista al instante, pasando de cuatro elementos a tres sin necesidad de recargar la página [03:45].
¿Qué mejora de seguridad se puede agregar como reto?
Un paso adicional recomendado es implementar un modal de confirmación antes de ejecutar la eliminación [04:10]. Este componente actúa como un candado de seguridad:
- Si el usuario confirma, se procede con el
delete.
- Si el usuario cancela, no ocurre ninguna acción.
Este patrón de confirmación es una buena práctica de UX (user experience) en cualquier operación destructiva, ya que protege contra clics accidentales y refuerza la conciencia de que la acción no tiene vuelta atrás.
¿Ya implementaste el modal de confirmación? Comparte tu solución y cuéntanos qué enfoque utilizaste.
