Aprender otra plataforma sin empezar de cero
De React a una aplicación de escritorio que debe funcionar sin conexión: cómo avanzar con agentes, conservar lo que sirve y poner a prueba lo nuevo.
Sabés resolver la interfaz en React. Pero ahora esa misma interacción tiene que seguir funcionando sin internet, conservar lo que hizo después de un cierre inesperado e instalarse en una computadora que no tiene tu entorno de desarrollo.
Los componentes siguen resultando familiares. Alrededor aparecen una base local, procesos distintos, sincronización, instaladores y actualizaciones. Y hay una condición que vuelve todo más exigente: estás trasladando un flujo que ya funciona y que necesita seguir funcionando durante la migración.
Es el tipo de proyecto que antes podía quedar detrás de una curva de aprendizaje enorme. Con agentes, se puede empezar a recorrer esa curva de otra manera: investigar una frontera, construir una pieza y examinarla mientras todavía estás aprendiendo la plataforma.
La experiencia previa importa mucho ahí. Aunque no conozcas todas las APIs nuevas, ya tenés criterio para preguntar qué debería conservarse y reconocer cuándo un resultado cambió sin motivo.
Lo conocido también puede viajar
La primera decisión útil aparece antes de abrir una ventana de escritorio: identificar qué partes del sistema actual no necesitan pertenecer a la web.
Una función que recibe datos y devuelve un resultado puede ser reutilizable. Un módulo que mezcla esa función con llamadas al servidor, variables de entorno y detalles del framework va a necesitar una separación más cuidadosa.
Extraer un núcleo compartido permite conservar una sola implementación de las reglas. La interfaz web y la nueva aplicación consumen ese mismo núcleo, cada una con su forma de obtener y guardar los datos.
Eso requiere algo más que mover una carpeta. El paquete debe poder ejecutarse sin arrastrar dependencias del servidor. También hay que conservar los caminos que usa la aplicación existente, o cambiarlos de manera coordinada.
Una comprobación concreta es darle las mismas entradas a la implementación anterior y a la extraída, y comparar los resultados. Otra es impedir que el paquete vuelva a importar componentes exclusivos de la web. Así, la independencia que buscabas queda respaldada por una comprobación automática.
Cada comportamiento que lográs conservar es una cosa menos que tenés que aprender y migrar al mismo tiempo.
Aprender sobre una pieza que ya se puede tocar
Electron permite construir la interfaz con tecnologías web y separar ese código de las responsabilidades propias del escritorio. Su modelo de procesos distingue el proceso principal de los procesos que renderizan las ventanas.
Para alguien que viene de React, esa separación ofrece un punto de apoyo. La interfaz puede seguir organizándose con componentes, mientras el acceso a recursos locales se resuelve detrás de una API acotada. El aislamiento de contexto ayuda a mantener esa frontera; no conviene exponer una puerta genérica a cualquier operación del sistema.
Acá los agentes pueden ayudar de varias maneras: explicar el recorrido entre procesos, construir un ejemplo mínimo, localizar una dependencia que se filtró y revisar si la interfaz recibió más capacidades de las necesarias.
La secuencia cambia. En vez de estudiar toda la plataforma antes de hacer algo útil, podés alternar preguntas con experimentos pequeños:
- ¿Cómo pide la interfaz una lectura local?
- ¿Dónde se confirma que una escritura terminó?
- ¿Qué recibe la pantalla si esa escritura falla?
Cada respuesta debería dejar una pieza que se pueda inspeccionar y probar. Si sólo deja una explicación convincente, todavía falta conectar el aprendizaje con el comportamiento.
Guardado acá y confirmado allá
Una aplicación puede abrir sin internet y seguir dependiendo de la red para casi todo lo importante.
Para completar una acción offline necesita datos disponibles en el equipo y un lugar donde persistir lo que la persona acaba de hacer. El estado de React sirve para representar la interacción; por sí solo no conserva una operación después de cerrar el proceso.
Una forma de organizarlo es separar una copia local de los datos necesarios para consultar de una cola persistente de operaciones pendientes de enviar. SQLite permite almacenar esa información en el equipo con transacciones; su documentación sobre commit atómico explica cómo mantiene la consistencia frente a interrupciones y qué condiciones supone del almacenamiento.
La interfaz también tiene que respetar esa separación. “Guardado” puede significar cosas distintas:
| Estado visible | Qué puede afirmar la aplicación |
|---|---|
| Guardado en este equipo | La escritura local terminó. Falta la confirmación del servidor. |
| Sincronizado | El servidor confirmó la operación y esa respuesta quedó registrada localmente. |
| Necesita revisión | La operación se conserva, pero hay un rechazo o un problema que requiere resolver algo. |
Estos estados ayudan a que una conexión mala no se convierta en una duda permanente sobre si conviene volver a tocar el botón.
La parte difícil está entre dos pasos
Un ejemplo didáctico: una aplicación permite guardar anotaciones sin conexión y enviarlas más tarde.
La anotación queda registrada en el equipo. Vuelve internet, la aplicación la envía y el servidor la guarda. Justo antes de que llegue la confirmación, se corta la conexión otra vez.
Desde el equipo no se puede saber todavía si el servidor terminó. Reintentar es razonable. Crear una anotación nueva por cada reintento produciría duplicados.
Por eso la operación necesita una identidad que se conserve entre intentos. El servidor debe poder reconocerla y devolver el resultado existente. Registrar esa identidad junto con el efecto de la operación, de forma atómica, evita dejar una separación donde uno se confirme y el otro no.
También aparecen dos momentos distintos: cuándo se produjo la acción y cuándo llegó al servidor. En un flujo siempre conectado pueden quedar muy cerca. Al sincronizar más tarde, tratarlos como si fueran el mismo dato puede cambiar el orden y el significado de lo ocurrido.
Estas decisiones se vuelven más claras cuando se prueban las interrupciones. Cerrá la aplicación después de guardar localmente. Cortá la conexión después de enviar. Recuperala cuando la confirmación ya se perdió. Al volver, tiene que ser posible explicar qué quedó pendiente y qué quedó confirmado.
Una pantalla que responde bien durante el recorrido ideal todavía no contesta esas preguntas.
Orquestar para aprender mejor
En una migración así hay frentes que pueden avanzar por separado: estudiar la persistencia, extraer una función, preparar una comprobación o revisar un contrato. También hay decisiones que necesitan cerrarse antes de repartir más implementación.
El objetivo de la orquestación es que cada frente devuelva algo que permita decidir el siguiente paso. Un agente puede investigar las opciones; otro, construir una pieza acotada; una revisión posterior puede buscar los supuestos que quedaron escondidos en esa implementación.
Definir contexto, límites y evidencia ayuda especialmente cuando parte del terreno es nuevo. La revisión tiene que poder cuestionar al primer resultado, incluso cuando compila y pasa sus propias pruebas.
Conviene automatizar las comprobaciones que ya entendés: compatibilidad de salidas, dependencias permitidas, recuperación de operaciones y armado del paquete. Así, cuando algo falla, la atención vuelve a una decisión concreta en lugar de reconstruir todo el recorrido a mano.
Si una dependencia del servidor vuelve a entrar al núcleo compartido, conviene que el error aparezca al proponer el cambio. Ese feedback concreto permite corregir el rumbo sin depender de que alguien recuerde revisar siempre lo mismo.
Este pan sigue en el horno
Hasta acá, el avance concreto está en preparar la base: el reconocimiento persistente de reintentos y la separación entre el momento de una acción y el de su recepción ya tienen una primera implementación integrada. La extracción del núcleo compartido está en revisión.
La aplicación de escritorio utilizable sigue siendo el próximo resultado por comprobar. Falta hacer convivir las piezas y probar un recorrido completo en una computadora real, con desconexiones y reinicios incluidos.
El aprendizaje que ya queda es una forma de encarar lo desconocido: conservar el comportamiento que entendés, aislar una responsabilidad nueva y exigirle una comprobación. Repetir ese recorrido vuelve abordable una plataforma que, mirada de una sola vez, parecía demasiado grande.