> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comfy.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Migración de callbacks de serialización para extensiones del frontend

> Cómo funcionan onSerialize y onConfigure con grafos basados en store y dónde deben guardar datos personalizados las extensiones del frontend de ComfyUI.

Configurar un `LGraph` raíz a partir de datos serializados ahora requiere una instancia de Pinia activa. `LGraph.configure()` vacía y reconstruye el grafo directamente sobre los almacenes ECS, así que un arnés de pruebas, un worker o un consumidor de LiteGraph independiente que llame a `new LGraph(data)` o `graph.configure(data)` sin una Pinia activa ahora falla de forma directa en lugar de producir en silencio un grafo vacío. Es el mismo requisito que se documenta en [Migración del registro de enlaces](https://docs.comfy.org/es/custom-nodes/js/link-registration-migration.md).

Las extensiones que se ejecutan en ComfyUI usan la instancia de Pinia activa de la aplicación. No crees ni actives una instancia de Pinia aparte desde el código de la extensión.

`node.onConfigure`, `node.onSerialize`, `graph.onConfigure` y `graph.onSerialize` conservan sus firmas y su orden de ejecución actuales. Para los hooks de temporización de conexiones, consulta [Migración de callbacks de conexión](https://docs.comfy.org/es/custom-nodes/js/connection-callbacks-migration.md); para `node.widgets` y el almacenamiento de valores de widgets, consulta [Migración del sistema de widgets](https://docs.comfy.org/es/custom-nodes/js/widgets-migration.md).

`onConfigure` ahora recibe una copia superficial de los datos serializados en lugar del objeto propio de quien llama. Añadir, eliminar o reasignar claves de nivel superior en el argumento del callback no cambia el JSON del flujo de trabajo de quien llama y no se persiste. Los objetos anidados (por ejemplo `inputs`, `pos`, `properties`) se siguen compartiendo con quien llama, así que mutarlos en el lugar todavía se filtra; las extensiones que dependían de cualquiera de los dos tipos de mutación deben guardar su estado propio en `node.properties` o `graph.extra`.

## Guardar datos propios en properties o extra

Usa `node.properties` para los datos de extensión por nodo y `graph.extra` para los datos de extensión por grafo. Siguen siendo las superficies de extensión estables y previstas para los datos persistidos.

`onSerialize` y `onConfigure` se llaman con `this` vinculado al objeto vivo del nodo o del grafo; el argumento que recibe la devolución de llamada es el objeto de datos serializado (`ISerialisedNode`/`ISerialisedGraph`), no el nodo ni el grafo vivos. Como `this` sigue siendo el objeto vivo, un hook puede modificar cualquier campo suyo, incluidos los campos que ahora se respaldan en el store. No uses estos hooks para sobrescribir campos centrales: una escritura mediante `this` desde dentro de `onSerialize`/`onConfigure` llega directamente al store, sin esquema, propiedad ni límite de deshacer propios.

`onSerialize` se ejecuta después de que el frontend haya copiado `graph.extra` y `node.properties` en el objeto de datos, así que una clave que el hook añada a `this.extra` o `this.properties` falta en este guardado. Dentro de `onSerialize`, escribe en el argumento de la devolución de llamada: `data.extra` para un grafo y `data.properties` para un nodo. De lo contrario, actualiza `graph.extra` o `node.properties` antes de que empiece la serialización.

`onSerialize` admite una sola devolución de llamada, así que conserva cualquier hook que ya haya instalado otra extensión:

```js theme={null}
const previous = graph.onSerialize
graph.onSerialize = function (data) {
  previous?.call(this, data)
  data.extra.myExtension = { version: 1 }
}
```

Solo el grafo raíz ejecuta `onSerialize`. Las definiciones de subgrafo se guardan sin llamar a ningún hook en el subgrafo, así que guarda los datos del subgrafo en `subgraph.extra` antes de guardar el flujo de trabajo.

Una clave personalizada de nivel superior que un hook añada a `data` permanece en el nivel superior en `LGraph.asSerialisable()`. El punto de entrada heredado `LGraph.serialize()` la mueve a `data.extensions` y deja fuera los valores que no son compatibles con JSON. Al cargar el flujo de trabajo, `onConfigure` vuelve a recibir la clave en el nivel superior. Las claves dentro de `extra` conservan su lugar en ambos puntos de entrada.

## Serializar nodos en lugar de enumerar propiedades

Si tu extensión crea una representación serializada o de depuración de un nodo enumerando sus propias propiedades, cámbiala a `node.serialize()`.

`id`, `type`, `title`, `flags`, `mode`, `color`, `bgcolor`, `shape` y `showAdvanced` ahora son propiedades de acceso sobre el almacén de datos del nodo en lugar de propiedades de datos propias en la instancia del nodo. `Object.keys(node)`, `for...in` y `{ ...node }` ya no exponen estos campos, aunque las lecturas y escrituras directas (`node.title`, `node.mode = ...`) siguen funcionando sin cambios. `inputs`, `outputs` y `widgets` siguen siendo enumerables como propiedades propias, así que la propagación y la enumeración todavía detectan esos tres.

Para `serializeValue` a nivel de widget, una capa de serialización independiente que construye el payload del prompt de la API, no el JSON del flujo de trabajo, consulta
[Migración del sistema de widgets](https://docs.comfy.org/es/custom-nodes/js/widgets-migration.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.