↑↓ to move · Enter to open · Esc to close

    All posts
    LinkedIn,

    RedCheck's recycle bin

    Soft deletes and a recycle bin for RedCheck — and why a 'just add a column' feature ended up touching half the architecture.

    Deleted something by mistake? No worries, RedCheck now has a Recycle Bin. 🗑️

    RedCheck’s recycle bin, empty: a friendly empty state saying deleted items will show up here.

    RedCheck’s recycle bin with a deleted subject and three deleted tasks, each with restore and delete-forever actions, and an ‘Empty bin’ button.

    Accidental deletions are incredibly common and a surefire way to ruin the UX. That’s why the latest feature I’ve been working on is a complete soft-delete and recycle bin system.

    On paper, it sounds like just adding a new column to the database and calling it a day. But implementing this robustly broke our initial entity contracts, which meant some deep refactoring:

    🛠️ Backend & database

    • Migrated the data model to include soft-delete flags (deleted).
    • Refactored queries and endpoints to ensure deleted items don’t pollute the main views.
    • Updated stored procedures and MySQL events so the new entity constraints wouldn’t break background automation.

    🎨 Frontend

    • Designed a dedicated view with smooth transition animations so restoring or permanently deleting tasks feels fluid.
    • Created friendly empty states and global actions like “Empty trash”.

    What’s the main takeaway from this iteration? No feature, no matter how trivial it seems, is ever just a quick fix. Simply modifying the base entity contracts forced a rethink of a large part of the architecture just to keep the database consistent and the frontend spotless.

    Feel free to check it out at redcheck.es! Any feedback or suggestions for improvement are more than welcome.

    ¿Has borrado algo sin querer? Tranquilo, RedCheck ya tiene papelera. 🗑️

    La papelera de RedCheck vacía: un estado vacío amable que indica que ahí aparecerán los elementos eliminados.

    La papelera de RedCheck con una asignatura y tres tareas eliminadas, cada una con acciones de restaurar y eliminar para siempre, y un botón de «Vaciar papelera».

    Los borrados accidentales son muy habituales y una forma segura de estropear la experiencia de usuario. Por eso la última funcionalidad en la que he estado trabajando es un sistema completo de borrado lógico (soft delete) con papelera.

    Sobre el papel suena a añadir una columna nueva a la base de datos y listo. Pero implementarlo de forma robusta rompió los contratos iniciales de nuestras entidades, lo que supuso una refactorización profunda:

    🛠️ Backend y base de datos

    • Migré el modelo de datos para incluir marcas de borrado lógico (deleted).
    • Refactoricé consultas y endpoints para que los elementos eliminados no ensucien las vistas principales.
    • Actualicé procedimientos almacenados y eventos de MySQL para que las nuevas restricciones de las entidades no rompieran la automatización en segundo plano.

    🎨 Frontend

    • Diseñé una vista propia con animaciones de transición suaves, para que restaurar o eliminar definitivamente una tarea se sienta fluido.
    • Creé estados vacíos amables y acciones globales como «Vaciar papelera».

    ¿La principal lección de esta iteración? Ninguna funcionalidad, por trivial que parezca, es nunca un arreglo rápido. Solo modificar los contratos base de las entidades obligó a repensar buena parte de la arquitectura para mantener la base de datos consistente y el frontend impecable.

    ¡Échale un vistazo en redcheck.es! Cualquier feedback o sugerencia de mejora es más que bienvenido.