🧪 Data Preview Test

Right off the bat, an honest warning: you won't find this node in the right-click menu. It lives in the Shima/Hidden category - a test and demonstration node the pack author built to prototype two frontend features: showing which values a node actually used, and highlighting critical widgets. If a workflow loads with this node in it, it's almost certainly a template or a pack example, not something you should build on. But understanding it teaches you a genuinely important concept in this pack: the use_commonparams switch and the "where did this number come from?" problem.

How it works

The node holds a set of hardcoded test values - test_seed (42), test_width (512), test_height (512), test_project ("TestProject"), test_model ("sdxl"). It also accepts a shima.commonparams bundle from Shima.Commons. The use_commonparams toggle decides the winner:

• OFF - the hardcoded values are used.
• ON (with a commonparams bundle connected) - the values from Shima.Commons win: its seed, width, height, project name, and model type.

Then it emits two outputs. data is a DICT with the resolved values plus a source field telling you which side won ("hardcoded" or "shima.commonparams"). used_values_text is a human-readable STRING summarizing the same thing - seed, width, height, project, model, and which source provided them. That's the "used values display" the node was built to demo: a box on the node showing, at a glance, what was actually in play for the last run.

The extra widgets - line_art_invert, canny_high/canny_low, depth_model, normal_strength, palette_colors, highlight_threshold, shadow_threshold - are stubs mimicking MultiSaver's settings, there to demonstrate widget highlighting rather than to do anything. Don't treat them as working controls; this is a test fixture.

Why it matters beyond the test

The pattern it demonstrates is everywhere in this pack: Shima nodes accept values from your local widgets or from a Commons bundle, and the use_commonparams switch (the green toggle in a node's topbar) decides which wins. The #1 "why did my settings get ignored" bug in Shima workflows is a node reading Commons values you didn't expect. DataPreviewTest is the pack showing you, in the clearest possible terms, what that handoff looks like and how to read which source is winning.

Installing it

It ships with the Shima pack - ComfyUI Manager → search Shima, or:

cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf.git Shima

Restart ComfyUI. It won't appear in menus; you'd only encounter it in a workflow that already contains it.

Common issues

• "I can't find it in the menu." Correct - it's a hidden test node. If you want to play with it, you need a workflow that references it.
• "The preview-control widgets do nothing." They're demonstration stubs for widget highlighting, not functioning preprocessors. That's by design.
• "The values look wrong." Check the source field. If use_commonparams is on and a Commons bundle is connected, the hardcoded values are supposed to be ignored - that's the feature.

Don't build production workflows on a test node. Do steal its lesson: when a Shima node ignores what you typed, look for the Commons override - that's where your number actually lives.