Feature Request: Dict Merge / Multi-DICT Input Support for String Formatter

[ndk28319]

Hello, thank you for creating ComfyUI-StringConstructor.
I’ve been using it to build a modular prompt system and it works very well.

While designing larger prompt workflows, I noticed that currently the system mainly relies on chain-style DICT accumulation:

DICT → DICT → DICT → Formatter

Each StringConstructorDictFromText node receives an existing dict and adds new entries.

However, when the number of prompt modules grows (e.g., body, character, pose, outfit, environment, camera, style, etc.), this chain can become very long in ComfyUI workflows.

Feature idea

Would it be possible to support parallel DICT aggregation, for example through a node like:

DICT_A
DICT_B
DICT_C
↓
DictMerge
↓
StringConstructorFormatter

Conceptually this would just merge multiple dictionaries before passing them to the formatter, something like:

merged = {}
merged.update(dictA)
merged.update(dictB)
merged.update(dictC)

Since StringConstructorFormatter ultimately uses str.format_map() with a single dictionary, this approach should still work with the existing formatting logic.

Why this could help

For larger prompt systems this would allow workflows to be structured more like:

Prompt Modules
body
character
pose
outfit
environment
camera
style
↓
DictMerge
↓
Formatter

Instead of requiring a long sequential chain of dict nodes.

This could make large prompt graphs more compact and easier to maintain.

Question

Do you think something like a DictMerge node (or multi-DICT input support for the formatter) would fit within the design of StringConstructor?

I’d be interested to hear your thoughts on whether this would align with the intended architecture.

Thanks again for the great tool!

[Lex-DRL]

Thanks for the kind words.

I'm a strong proponent of single-responsibility and DRY principles, and a strong opponent to reinventing a wheel.

The Basic Data Handling pack (that I recommend in ReadMe) already contains nodes for all the common dict operations, including merge. However, currently it conflicts with my pack, because I use frozendict instead of the built-in dict, and I'd like to keep using it.
I've already made a PR to fix it: StableLlama/ComfyUI-basic_data_handling#46
(though, it fails some tests now, so I need to investigate that)

[ndk28319]

Adding this here as a follow-up thought related to the proposed solution (PR #46).

I’m not reviewing the implementation itself, but I used AI-assisted analysis to look at the design approach and found a potential risk worth mentioning.

The current approach seems to rely on a generic "preserve input type" strategy, reconstructing mappings via:

• type(input_dict)(result)
• type(input_dict)(result.items())

However, the Python Mapping protocol only guarantees read-like behavior, and does not guarantee that arbitrary mapping-like classes can be reconstructed through these constructors.

This may work for dict or frozendict, but may not be safe for arbitrary mapping implementations.

Because of this, a few possible failure points could be:

1. Output type changes where existing tests expect a plain dict
2. Constructor mismatch for non-standard mapping classes
3. Behavioral differences in mutating nodes due to the intermediate "dict → reconstruct" approach

Since the original goal seems to be compatibility with frozendict, it might be safer to narrow the scope instead of supporting arbitrary mappings.

For example:

• Explicitly support dict and frozendict
• Fall back to plain dict for other mapping inputs

This would make behavior more predictable and easier to test, compared to trying to preserve arbitrary mapping types generically.

This message was prepared with AI assistance.

[Lex-DRL]

@ndk28319

I used AI-assisted analysis

Which specific AI tool have you used?

[Lex-DRL]

My PR is merged to basic_data_handling node pack: StableLlama/ComfyUI-basic_data_handling#46
It now properly works with frozendict and thus, with this pack, which I recommend using.

Closing the issue