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.
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; para node.widgets y el almacenamiento de valores de widgets, consulta Migración del sistema de widgets.
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
Usanode.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:
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 anode.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.