useEditorContext: así funcionan los composables Vue en n8n
En pocas palabras: useEditorContext es un composable de Vue escrito en TypeScript que vive en packages/frontend/editor-ui/src/app/composables/useEditorContext.ts, dentro del repo n8n-io/n8n. Expone un objeto con features del editor como claves y valores booleanos, combinando overrides por host con la configuración global que llega desde el store de Pinia.
Entre los composables Vue en n8n, useEditorContext es de los más interesantes: define qué funciones del editor puede activar o restringir cada host.
useEditorContext es un composable escrito en TypeScript que forma parte del editor-ui de n8n, la interfaz donde se arman los workflows de automatización. Su trabajo es exponer un objeto con features del editor como claves y valores booleanos: qué está habilitado y qué no para el contexto actual. El archivo vive en packages/frontend/editor-ui/src/app/composables/useEditorContext.ts, dentro del repositorio oficial n8n-io/n8n en GitHub.
En 30 segundos
- Ubicación exacta: packages/frontend/editor-ui/src/app/composables/useEditorContext.ts, en el repo n8n-io/n8n.
- Para qué existe: su comentario interno lo describe como “Per-editor host overrides for the current editor context”, o sea, overrides por host para el contexto actual del editor.
- Regla de oro: un host solo puede restringir; un
falseexplícito gana, y si omite la feature (o mandatrue), se aplica el gating del store. - De dónde saca los datos: consume useSettingsStore de Pinia para saber qué features están habilitadas a nivel app.
- Qué devuelve: un objeto con features como claves y booleanos como valores, incluidos executionSuccessToasts y la disponibilidad de Instance AI.
n8n es una herramienta de automatización de flujos de trabajo desarrollada por la empresa alemana n8n GmbH, fundada por Jan Oberhauser en 2019. Permite conectar aplicaciones y servicios mediante una interfaz visual y código personalizado para automatizar tareas y procesos.
¿Qué es un composable en Vue.js?
Un composable es una función que usa la Composition API de Vue para encapsular y reutilizar lógica con estado. Nada más.
Si alguna vez copiaste y pegaste la misma función de formateo de fechas en cinco componentes distintos, ya viviste el problema que resuelven. Un componente arma la interfaz; un composable guarda la lógica que varios componentes necesitan. Según la guía oficial de Vue, la gracia está en que podés meter refs, computed y watchers dentro de una función y llevarla a donde quieras. Es reutilización de verdad, no la de los mixins viejos que nadie extrañaba.
Ojo con un detalle que suele confundir: cada llamada a un composable con estado interno crea su propio estado. Si querés compartir datos entre componentes, ahí entra Pinia o un estado externo. (Spoiler: no hay “magia”, son funciones bien organizadas.) Sobre eso hablamos en cómo escribir expresiones dentro del editor.
¿Y esto qué tiene que ver con n8n? Que el equipo escribió todo el editor-ui en Vue, así que patrones como este atraviesan todo el frontend del producto.
¿Cuál es la diferencia entre lógica stateless y stateful?
La diferencia es una sola: la lógica stateless toma un input y devuelve un output al momento; la stateful maneja estado que cambia con el tiempo.
Un formateador de fechas es stateless: le pasás una fecha, te devuelve texto. Fin. Rastrear la posición del mouse en la página es stateful: el valor cambia constantemente y algo tiene que guardarlo. En escenarios reales, la lista se amplía hasta incluir gestos táctiles o el estado de conexión con una base de datos, como enumera el análisis de Ramu Narasinga en dev.to. Si venís de React, esto te va a sonar: los Hooks resuelven el mismo problema, y los composables son el equivalente del lado de Vue.
| Aspecto | Lógica stateless | Lógica stateful |
|---|---|---|
| Entrada y salida | Input y output inmediato | Estado que cambia en el tiempo |
| Ejemplo típico | Formateador de fechas | Posición del mouse en pantalla |
| Casos reales | Validaciones y formateo | Gestos táctiles, conexión a la base |
| Cómo se reutiliza | Función exportada y listo | Composable con la Composition API |
¿Qué hace useEditorContext en el código de n8n?
Ponele que integrás el editor de n8n dentro de tu propio producto y no querés que salte el aviso de “ejecución exitosa” en cada workflow. Ahí entra este composable.
Su cometido está escrito en el propio archivo, en un comentario que dice: “Per-editor host overrides for the current editor context” (overrides por host para el contexto actual del editor). Un host es quien aloja o embebe el editor, y necesita ajustar qué features se muestran sin tocar el código base de n8n. Es la diferencia entre pedirle un cambio al equipo de n8n y resolverlo vos con configuración. Tema relacionado: conectar tus flujos con Airtable.
¿Y si el host quiere encender algo que la app tiene apagado? No puede. El comentario del código es explícito: “A host can only restrict: an explicit `false` supersedes the feature; omitted (or `true`) falls back to the store gating below”. Traducido: el host solo puede restringir, nunca otorgar. Ese sistema de “permisos” donde solo podés decir que no me parece un diseño fino: evita que quien embebe el editor rompa el modelo de features de n8n.
¿Cómo se estructura useEditorContext por dentro?
La estructura tiene tres capas: leer el store de settings, aplicar la precedencia de overrides del host y devolver un objeto plano de booleanos.
Abrís el archivo, leés el comentario, te metés en la implementación, ves que llama al store de configuración, después recorre los overrides del host uno por uno, aplica la regla del false explícito y, al final, te devuelve un objeto simple que cualquier componente puede consumir sin enterarse de toda esa cadena. (Sí, en serio, todo eso ocurre en un solo composable.) Una versión simplificada del comportamiento, basada en lo que describe el código real:
// Comportamiento simplificado; el archivo real cubre más casos.
const settingsStore = useSettingsStore();
function resolverFeature(clave, override) {
// Un host solo puede restringir: un `false` explícito gana;
// omitido (o `true`) cae al gating del store.
if (override === false) {
return false;
}
return settingsStore.featureHabilitada(clave);
}Hay otro detalle de arquitectura que vale oro: la parte de Instance AI “espeja” a useInstanceAiAvailable(), la compuerta equivalente de la capa de features, pero usando primitivas de la capa de aplicación. Resultado: este composable base no importa ningún módulo de features, y eso mantiene las dependencias limpias. Acordate de la regla cuando diseñes el tuyo. Lo explicamos a fondo en dominar el nodo HTTP Request.
¿Composables o Pinia: cuándo conviene cada uno?
No compiten: en n8n el composable consume al store. useEditorContext toma useSettingsStore de Pinia, la librería de manejo de estado, como fuente de verdad global y le agrega encima la capa de overrides por host.
La verdad es que la regla práctica que uso yo es simple. Si el dato es global y compartido (settings, sesión, plan contratado), va a Pinia. Si la lógica es reutilizable pero vive pegada al ciclo de vida del componente, va en un composable. El punto medio, como muestra este caso, es un composable que orquesta decisiones usando datos del store. La alternativa directa sería consultar useSettingsStore desde cada componente, aunque ahí perdés la capa de overrides concentrada en un solo lugar.
| Criterio | Composable | Store de Pinia |
|---|---|---|
| Alcance del estado | Por instancia, cada llamada tiene el suyo | Global y compartido |
| Ideal para | Lógica reutilizable acotada al componente | Estado de app: settings, sesión |
| Ejemplo en n8n | useEditorContext, useInstanceAiAvailable | useSettingsStore |
| Relación entre ellos | Puede consumir stores | No depende de composables |
¿Qué features expone useEditorContext?
Devuelve un objeto donde cada clave es una feature del editor y cada valor un booleano que dice si está habilitada.
- executionSuccessToasts: controla si aparecen los avisos de ejecución exitosa tras correr un workflow. Es justo el tipo de cosa que un host querría apagar en un embed.
- Disponibilidad de Instance AI: evalúa que el módulo esté activo y habilitado, que esté listo (o sea corregible por un admin) y que el usuario pueda mandarle mensajes a la IA de la instancia.
Narasinga cierra su lectura con una hipótesis razonable: el retorno agrupa las features habilitadas en el contexto del editor, con booleanos según el gating. Habría que confirmarlo contra el archivo completo, pero el patrón coincide con lo que se ve en los fragmentos que él publica.
¿Dónde está el archivo y cómo explorarlo vos mismo?
Está en packages/frontend/editor-ui/src/app/composables/useEditorContext.ts del repositorio n8n-io/n8n en GitHub. El recorrido de referencia incluye también NodeView.vue, la vista principal del editor, así que tenés ambos extremos: la definición y un lugar donde se usa.
Mi consejo de lectura: arrancá por los comentarios, seguí el flujo del store y recién después mirá los detalles. Es un archivo corto, re piola para leer en una sentada. Relacionado: disparar notificaciones automáticas por Slack.
Errores comunes con composables Vue en n8n
Estos tropiezos se repiten en equipos que migran a Composition API. Los ordeno del más frecuente al más caro.
- Asumir que el composable comparte estado entre componentes. Cada llamada crea estado propio; si necesitás compartir, usá Pinia o estado externo, como aclara la guía de Vue.
- Pensar que un override en
truehabilita features. En useEditorContext el host solo puede restringir; eltrueequivale a “no opino, decide el store”. - Importar módulos de features desde un composable base. Acoplás todo y perdés la separación de capas que n8n cuidó espejando useInstanceAiAvailable con primitivas de aplicación.
- Duplicar la lógica de gating en cada componente. Si cada vista consulta al store directamente, cualquier cambio de reglas se vuelve una cacería de refactors. Centralizá en el composable.
Preguntas Frecuentes
¿Qué es useEditorContext en n8n?
Es un composable de Vue del editor-ui de n8n que expone qué features del editor están habilitadas para el contexto actual. Aplica primero los overrides del host y, cuando no hay override, cae al gating del store de Pinia. Vive en packages/frontend/editor-ui/src/app/composables/useEditorContext.ts.
¿Dónde está el archivo useEditorContext en el repositorio de n8n?
En packages/frontend/editor-ui/src/app/composables/useEditorContext.ts del repo n8n-io/n8n en GitHub. El análisis de Ramu Narasinga en dev.to lo recorre junto con NodeView.vue como referencia de uso.
¿Qué propiedades devuelve useEditorContext?
Un objeto con features del editor como claves y booleanos como valores. Entre las documentadas están executionSuccessToasts y la disponibilidad de Instance AI; el resto de las claves sigue el mismo patrón de gating.
¿Se puede usar useEditorContext fuera de n8n?
No como paquete: es código interno del frontend del editor y no forma parte de la superficie para desarrollar nodos personalizados. El patrón sí se replica en cualquier app Vue: un composable que combine overrides locales con un store global.
¿Cuándo usar un composable y cuándo Pinia?
Pinia para estado global compartido, como settings o sesión; composables para lógica reutilizable ligada al ciclo de vida del componente. En n8n conviven los dos: useEditorContext consume useSettingsStore y le suma la capa de overrides por host.
Conclusión
Lo valioso de esta publicación es la lectura del código: quedó documentado paso a paso cómo n8n resuelve el gating de features del editor con un composable que combina overrides de host y store global. Para cualquiera que construya frontends con Vue, el patrón es un golazo: API plana de booleanos, precedencia clara y cero acoplamiento con módulos de features.
Si te toca diseñar algo parecido, robá dos ideas: la precedencia del false explícito y la separación entre capa de aplicación y capa de features. Y después contame si te zafó tan bien como a mí.
