Is there a way to have dynamic RETURN_TYPES ?

[devingfx]

I need a node that "casts" the output depending on the inputs (essentially a format COMBO to choose the output type).
Is this possible?

[ltdrdata]

There's only an ugly wildcard trick to do that.

backend:
https://github.com/ltdrdata/ComfyUI-Impact-Pack/blob/940ad41b1508cf9156bea8ee0ef7c87a851cc24f/modules/impact/logics.py#L642

frontend:
https://github.com/ltdrdata/ComfyUI-Impact-Pack/blob/940ad41b1508cf9156bea8ee0ef7c87a851cc24f/js/impact-pack.js#L240

[christian-byrne]

Could you point me what event/callback I need to hijack for the load of the node widgets to execute my dynamic output's type/name setter, please?

See the onGraphConfigured and onAfterGraphConfigured callbacks which you can hijack: https://github.com/Comfy-Org/ComfyUI_frontend/blob/56f3842045758de6c6029915525df013d2cf6f4a/src/scripts/app.ts#L1705-L1728

Example

[devingfx]

@christian-byrne What is the difference between overriding LGraphNode.prototype.onConfigure and ComfyNode<nodeType>.prototype.onGraphConfigure/onAfterGraphConfigured ?

[christian-byrne]

@christian-byrne What is the difference between overriding LGraphNode.prototype.onConfigure and ComfyNode<nodeType>.prototype.onGraphConfigure/onAfterGraphConfigured ?

To my knowledge, ComfyNode class is not exposed for you to overrwrite properties on. Assuming by ComfyNode<nodeType> you meant an instance of a ComfyNode, then you will need to access via ComfyNode<nodeType>.constructor.prototype. The target for the modifications will depend on desired scope of changes:

• Apply to a specific instance of a particular node: ComfyNode<nodeType>.onGraphConfigured/onAfterGraphConfigured
• Apply to all current or future instances of a particular node: ComfyNode<nodeType>.constructor.prototype.onGraphConfigured/onAfterGraphConfigured
• Apply to all instances of all nodes: LGraphNode.prototype.onAfterGraphConfigured

[devingfx]

by ComfyNode<nodeType> I meant a subclass of ComfyNode not a instance... BTW all methods are accessible because of inheritance, I wrote that this way to somehow point out where each methods was defined...

The question was more: "Why not override onConfigure on a specific ComfyNode subclass (and safely calling the old/overriden method to let the inheritance chain apply)? Is it safe/dangerous?"

Meanwhile I figured out and opened an issue, that is, on my undestanding (and debug session step by step), a core extension is overriding onGraphConfigured too hardly (not calling the overriden method) and extensions overriding this cannot be called. Because the order of extension loading is not garantied due to async operation... So in my case, my extension did override the method, then widgetInput is loaded after and completely erase my ext's overrding...

[christian-byrne]

Thanks, I understand now. ComfyNode<nodeType> to denote a subclass of ComfyNode is from what type system?

Can you give an example of where ComfyNode is subclassed?