Códice Cotalker: el sello compacto que mantiene únicas tus questions (parte 2)

Estás creando un formulario nuevo y le agregas una question simple: "Nombre de producto", pero el sistema te lanza un error y te dice que ese code ya existe. Nunca has creado esa question pero ya intuyes la razón: ese code de question vive en otro formulario, en otro flujo, escrito por alguien que tocó esta misma company solo que hace dos años... quizá hasta fuiste tú mismo.

Bienvenido a la verdad que todos pasan de largo con las questions en Cotalker: sus codes no son únicos por formulario, son únicos por toda la company.

Cómo nombrar formularios en Cotalker: la convención del prefijo

La convención del prefijo entre paréntesis para formularios en Cotalker: cómo organizar tu workspace y migrar flujos entre ambientes sin perder el contexto.

Esteban Tejeda DevEsteban Tejeda

Acá bajamos un escalón más. En este nivel no se nombran hechizos enteros: se nombran sus palabras. Cada question es una palabra menor del conjuro, y Cotalker no tolera que dos palabras de poder se llamen igual. Por eso, en esta segunda parte, verás reglas más estrictas que en la primera.

Capítulo 1: La regla incómoda, codes únicos a nivel global

En toda biblioteca arcana hay una ley que no se rompe: ninguna palabra de poder puede repetirse. Cotalker la aplica al pie de la letra: el code de una question es único en toda la company, no en el formulario.

Esto significa que:

• ✅ Puedes tener dos questions con el mismo display ("Nombre de tienda") en formularios distintos.
• ❌ No puedes tener dos questions con el mismo code (nombre_de_tienda) en formularios distintos.

¿Por qué es así? Misterios de la Orden de los Arquitectos Primigenios. Quizás alguna decisión temprana de diseño que el resto de la plataforma asumió como ley. Lo único cierto es que la regla existe y el sistema la hace cumplir: dos questions no pueden compartir code, aunque vivan en formularios que nunca se cruzan.

Capítulo 2: la herencia del prefijo

La parte 1 de esta saga estableció que el code de un formulario lleva el prefijo del flujo (por ejemplo inv_enviar_a_tienda) y esa misma regla aplicaremos para questions solo que con un sutil cambio: cada identificador de una question debe llevar el prefijo de su formulario, esto quiere decir:

Si el formulario tiene como code inv_enviar_a_tienda, entonces sus questions serán:

inv_enviar_a_tienda_nombre_de_tienda
inv_enviar_a_tienda_direccion_de_tienda
inv_enviar_a_tienda_responsable_de_envio

Hasta aquí todo bien, se entiende claro cómo deben nombrarse las questions, pero acá viene el giro: aunque está correcto, esta solución tiene un leve punto de falla, cuando llegas a un dropdown que muestra los codes de las questions, esos nombres se cortan, lo que los hace muy difíciles de seleccionar.

Para solucionar este problema tuvimos que recurrir al gran Sergio "el Sellador Ancestral": un hechicero que existe desde antes de que Operaciones tuviera nombre. Un ente tan antiguo y poderoso que no se le encuentra, se le invoca, y solo si pronuncias su nombre tres veces seguidas. Así que respiré hondo y lo llamé: Sergio… Sergio… Sergio…

El aire se quebró. Desde algún pliegue olvidado de un lugar sin coordenadas, anterior al tiempo mismo. El Sellador Ancestral descendió, nos miró como quien ya conocía la pregunta antes de formularse, y dijo…

Capítulo 3: El prefijo acortado

"…Tomas el code del formulario, descartas el prefijo de flujo y conviertes el resto en una abreviación tomando la primera letra de cada palabra."
- Sergio, el Sellador Ancestral.

Suena un tanto complejo, pero con este ejemplo se entenderá bastante:

1. Formulario -> inv_enviar_a_tienda
2. Prefijo del form -> inv_
3. Resto -> enviar_a_tienda -> enviar_a_tienda -> eat
4. Prefijo de questions -> inv_eat_

El resultado: las questions de ese formulario llevan inv_eat_ como prefijo, no inv_enviar_a_tienda_X. Más corto. Más legible. Cumple la unicidad sin saturar el dropdown.

Para el ejemplo anterior, nos quedaría este resultado:

inv_enviar_a_tienda_nombre_de_tienda -> inv_eat_nombre_de_tienda
inv_enviar_a_tienda_direccion_de_tienda -> inv_eat_direccion_de_tienda
inv_enviar_a_tienda_responsable_de_envio -> inv_eat_responsable_de_envio

Capítulo 4: Codes reservados

Hay reglas que no se inventan, como las páginas obligatorias que todo libro de hechicería bien escrito tiene: el título y los subtítulos. Sus codes están preordenados por la práctica acumulada.

Cada formulario casi siempre tiene:

• Un título principal: su code SIEMPRE será <prefijo>_title
• Subtítulos: si existen, simplemente es <prefijo>_subtitle_1 , <prefijo>_subtitle_2 , etc.

Para el ejemplo anterior, tendríamos:

inv_eat_title -> Título principal del formulario "Enviar a tienda"
inv_eat_subtitle_1 -> Primer subtítulo
inv_eat_subtitle_2 -> Segundo subtítulo

¿Por qué codes reservados? Porque son patrones que se repiten en cada formulario. Si cada implementador inventara el code del título a su gusto (titulo_principal, header, nombre_del_form), terminarías con cinco convenciones distintas para el mismo concepto. Reservar _title y _subtitle_N corta la discusión: hay una sola forma de nombrar el título de un formulario, y todo el equipo la conoce.

Capítulo 5: el lenguaje secreto del display

Hasta acá hablamos del code, pero las questions tienen una segunda dimensión: el display, lo que el invocador ve. El display vive en un lenguaje secreto: tres marcas entre corchetes que no nombran al hechizo, sino que delatan su naturaleza.

Las tres marcas más comunes en los display son las siguientes:

Estas marcas van al inicio del display, antes del nombre real, y se pueden combinar:

✅ [PRL] [HIDE] ID Usuario -> preload y oculto: precarga el usuario y lo deja oculto para que otra question acceda a esta
✅ [DEP] Estado anterior -> deprecado: mantener por compatibilidad (si ya funciona así, mejor no moverlo para no romper nada).
✅ [PRL] Nombre de tienda -> preload: precarga el valor desde el asset de la tarea

Capítulo 6: La conclusión del segundo círculo

Las questions no son hijas pequeñas del formulario: son las palabras de poder del hechizo. Estas convenciones existen porque sin ella, la biblioteca arcana se vuelve un campo minado de reglas duplicadas y maldiciones crípticas.

Pero esto no termina acá. Las colecciones también tienen sus propias convenciones: cuándo se sellan, cuándo se dejan libres, y cómo tratar sus elementos. Todo eso lo veremos en la parte 3.

¿Te ha pasado el error del code duplicado en una question? Cuéntamelo en los comentarios.