Nodes/comfy-ovum/_.fromPairs
ComfyUI Node

_.fromPairs

_.fromPairs builds your object

By sfinktah·Created about a year ago·Updated 10 months ago· 7
_.fromPairs
  • obj
  • values
  • manyValues
  • *

You have two lists: keys and values. You need a dict. _.fromPairs zips them together - ['k1','k2'] and [1,2] become {'k1': 1, 'k2': 2}. It's the reverse of _.pairs, aliased zipObject in lodash. If a dict is the shape your downstream wants (a config block, a payload for a JSON node), this is the node that builds it.

It's part of the _.* family in sfinktah/comfy-ovum, the auto-generated wrappers around underscore3 (a Python port of Underscore.js).

The manyValues twist

The description adds a non-standard option worth knowing about: set manyValues and the input flips to [key, value1, value2, ...], producing {key: [value1, value2, ...]}. So one key can collect several values into a list under it - handy for grouping a run's settings under a single key without pre-zipping.

The inputs that matter

  • obj - the primary object. For the keys+values form, this is the array of keys (loose *; also accepts a _.CHAIN).
  • values - the parallel array of values, matched by position. ANY, JSON allowed.
  • manyValues - an ANY input that switches to the [key, v1, v2, ...] interpretation.

Output is a loose * - a Python dict in practice (I verified ['k1','k2'] + [1,2]{'k1': 1, 'k2': 2} against the shipped port). Wire it into anything that consumes DICT.

Why you'd reach for it

When a downstream node wants a dict and your graph naturally produces aligned lists - say a list of setting names from a widget editor and a list of values from sliders. Building the pair lists upstream and zipping them here beats hand-wiring individual key/value nodes, and it keeps the mapping obvious.

Install

ComfyUI Manager, search "comfy-ovum", or:

cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum

Restart, under ovum/underscore. No models, no downloads.

Honest warnings

Family disclaimer applies: work in progress. Watch out for length mismatch - if your keys and values lists don't line up, the dict just stops at the shorter one, silently. And the chain rule: feed a _.CHAIN in and you get a chain out, so _.value it before using the dict downstream.

Categoryovum/underscore

Inputs (3)

NameTypeDefaultDescription
objopt*Primary input object. Also accepts _.CHAIN to continue chaining.
valuesopt*values: JSON allowed for arrays/objects where applicable.
manyValuesopt*manyValues: JSON allowed for arrays/objects where applicable.

Outputs (1)

NameTypeDescription
**