Todo CLI en Rust 5. Siguiente paso, pasar de CLI a TUI con ratatui

Llegamos al cierre de la serie con una pregunta natural: si ya tenemos una base sólida en dominio, aplicación y persistencia, ¿cuál es el siguiente salto con sentido?

Read this chapter in English: EN

Para mí, está bastante claro: construir esta misma herramienta como TUI con ratatui.rs.

No como experimento decorativo, sino como evolución real del producto.

De terminal sobria a cocina con estrella Michelin (y una rata al mando)

#

La CLI actual funciona bien para comandos directos:

• add
• list
• done
• todo
• delete

Pero cuando el flujo se vuelve más interactivo (navegar tareas, filtrar varias veces, editar estados en lote), el modelo comando por comando empieza a friccionar.

Una TUI te permite:

• navegar con teclado por listas,
• cambiar estado con atajos,
• visualizar contexto completo en pantalla,
• y reducir rondas de comandos para tareas cotidianas.

La despensa ya está llena: dominio y use cases listos para cocinar

#

Gracias a la arquitectura actual en todo-cli-rs:

• src/tasks/domain/task.rs
• src/tasks/application/use_cases
• src/tasks/ports/outputs/task_repository.rs

podemos cambiar el adaptador de entrada/salida sin tocar reglas de negocio.

Ese era exactamente el objetivo de separar capas desde el capítulo 1.

Dos menús en el mismo restaurante: CLI para scripts, TUI para ratones

#

El siguiente paso lógico no es “reemplazar” el binario CLI, sino convivir:

• modo CLI para automatización y scripting,
• modo TUI para uso interactivo diario.

Por ejemplo:

• todo-cli add "x" sigue funcionando,
• todo-cli tui abre la interfaz con ratatui.

Qué cambia y qué no

#

No cambia:

• entidad Task e invariantes,
• casos de uso (add, list, done, todo, delete),
• repositorio JSON e in-memory,
• taxonomía de errores por capa.

Sí cambia:

• nuevo adaptador adapters/tui,
• event loop (teclado, ticks, redraw),
• estado de UI (selección, foco, filtros activos),
• renderizado de widgets y layout.

Plano de cocina: cómo encajar ratatui sin romper la vajilla

#

Una forma limpia de introducirlo:

src/tasks/adapters/
  cli/
  tui/
    app_state.rs
    events.rs
    renderer.rs
    screens/
      task_list.rs
      task_detail.rs

app_state mantiene estado de interfaz; cuando ocurre una acción de usuario, dispara un caso de uso existente.

Ejemplo:

• tecla d sobre tarea seleccionada -> MarkTaskDoneUseCase
• tecla t -> MarkTaskTodoUseCase
• tecla a -> flujo de input para AddTaskUseCase

Donde la rata suda: retos técnicos al pasar de CLI a TUI

#

1. Modelo de estado de UI

   • qué estado pertenece a interfaz y qué estado pertenece al dominio.

2. Gestión de errores sin romper experiencia

   • en CLI puedes imprimir error y salir.
   • en TUI necesitas surfacear errores en pantalla sin destruir sesión.

3. Rendimiento de refresco y consistencia

   • evitar renders innecesarios,
   • mantener sincronización entre repositorio y vista.

4. Testing de interfaz

   • seguir apoyándonos en tests de dominio/use cases,
   • y añadir tests focalizados para eventos críticos de TUI.

Receta por pasos: roadmap para servir la TUI sin quemarla

#

1. Añadir subcomando tui al parser actual.
2. Crear adapters/tui con un listado simple de tareas.
3. Mapear teclas para done/todo/delete reutilizando casos de uso.
4. Añadir filtro en vivo por estado.
5. Añadir formulario de alta rápida (add).
6. Refinar UX (atajos, ayuda contextual, mensajes de error en barra inferior).

Cierre: menos teclado-castigo, más flujo con sabor a queso

#

La evolución a ratatui no va de “hacerlo más bonito”. Va de elevar la productividad sin reescribir el núcleo del sistema.

Si la arquitectura está bien planteada, pasar de CLI a TUI no es una cirugía mayor. Es añadir un nuevo adaptador encima de un dominio que ya sabe comportarse.

Y esa, al final, era la apuesta de toda la serie.