Render drops a nested instance's non-default slot fill

[nathanacurtis]

Problem

When render places a nested instance, any prop configuration whose value is an object is skipped. The instance is created, its scalar properties are applied, and the object-valued ones are dropped with nothing said. Two kinds are affected: a slot fill ($slotContent) and a prop binding ($binding).

Consequences:

• A composition's nested instance loses content the spec places in a non-default slot — the canvas shows the main component's default instead
• An instance whose property should stay bound to the host's own prop renders unbound
• A round trip cannot restore what it read: generate loses the same non-default slot fill (MVP: Capture a nested instance's non-default slot fill when generating a composed spec #672), and render loses it again on the way back

Observed with specs carrying propConfigurations.aside.$slotContent and propConfigurations.children.$binding — both rendered as if the entries were not there, with no warning in CLI output. It is documented as deliberate for now: "Phase 4 scope: scalar configs (variant/boolean/text). Deferred and skipped here: $nested deep configs, and object values ($binding pass-through, $slotContent)."

Potential solution(s)

• Apply a $slotContent configuration by building the referenced content into the named slot on the instance
• Apply a $binding by wiring the instance's property to the host's prop rather than leaving the main component's default
• Until both land, warn when an object-valued configuration is skipped, naming the element and prop

Acceptance criteria

• A nested instance whose spec fills a non-default slot renders with that content in that slot
• A nested instance whose property is bound to a host prop renders bound, not at the main component's default
• A $nested deep configuration is applied, or skipped with a warning naming it
• Any configuration render cannot apply produces a warning naming the element and prop

Case data

• Fixture: Slot Non Default Nested (1660:441), Slot Passthrough (1660:429)
• Workspace: specs-testing — TEST New Layout Test Cases page
• Territory: figma-from-specs
• Impacted file(s): specs-from-figma/packages/figma-from-specs/src/PropConfigurations/PropConfigurations.ts
• Size: m

Notes

Read-side counterpart is #672, so the fill is lost in both directions today.

Render warnings are also withheld from CLI output behind a disabled flag in RenderCommand.ts, which is why a skipped configuration is invisible rather than merely unimplemented.

---

Implementation details are tracked internally.

[nathanacurtis]

Round-trip evidence confirming this, now that the read side is fixed.

#672 and #677 landed the capture half: a nested instance's non-default slot fill is emitted, bound through the instance's props. Rendering that spec and capturing it back loses the fill again, which isolates the remaining loss to this issue.

In:

layout: [root: [levelZeroText, level1: [twoSlots: [aChild]]]]
twoSlots:
  propConfigurations:
    aside: { $slotContent: "…/slotContentExamples/testSlotTwoSlots__aside__default" }

Out, after render then capture:

layout: [root: [levelZeroText, level1: [twoSlots: [aChild]]]]
# no aside, no examples concern at all

The consolidated default-slot tree survives intact. The bound non-default slot is empty on the canvas, so there is nothing to capture. Render completes with no warning, which matches the note here about warnings being withheld behind a disabled flag — the skipped configuration is invisible rather than merely unimplemented.

#680 was filed against this symptom before I found this issue and has been closed as a duplicate; its only unique content is the above.

One practical note for whoever works this. A spec copied away from the sibling file holding its run facts loses the naming convention render needs, and render then fails to resolve instance elements for a reason unrelated to this issue. Keep that file beside a spec folder when rendering one in isolation, or the symptom reads as this bug and is not. Filed as #683.

[nathanacurtis]

Fixed for $slotContent; the other two now report themselves.

What landed

A slot-content reference is not a component property, so setProperties was never going to carry it. It is now built into the slot matched by name inside the instance, emptied first so the spec's fill replaces the main component's default rather than piling on top — the same rule the default-slot path already followed.

Round trip on Slot Non Default Nested, identical across all three concerns:

	in	out
anatomy	aChild, level1, levelZeroText, root, twoSlots	same
layout	root > levelZeroText > level1 > twoSlots > aChild	same
binding on the instance	aside: {$slotContent: …}	same
referenced entry	testSlotTwoSlots__aside__default with content: Aside	same

• a nested instance whose spec fills a non-default slot renders with that content in that slot
• a nested instance whose property is bound to a host prop renders bound — not done, see below
• a $nested deep configuration is skipped with a warning naming it
• any configuration render cannot apply produces a warning naming the element and prop

What is left, and why I stopped short

$binding pass-through is not implemented. Wiring a nested instance's property to the host component's own property is not something I could establish the plugin API supports in the way this needs, and guessing at it would be worse than leaving it reported. It now warns naming the element and prop, so an unbound instance is visible rather than silent.

If that half should stay tracked separately from the slot half, this issue is a good candidate to split — the slot work is done and verified, the binding work is unstarted and needs an API answer first.

Also worth noting: render warnings are still withheld from CLI output behind a disabled flag in the render command, so these new warnings are reachable but not yet printed by default. That is the same condition this issue's notes described, and it is unchanged.

[nathanacurtis]

Split, as the two halves had different fates.

• This issue now covers the slot fill only, which is done and round-trip verified. Closing it.
• Apply a non-image prop binding on render, or settle that it cannot be #684 carries the prop-binding and $nested halves, which are unstarted and gated on a platform question.

The title has been narrowed to match.

The reason for splitting rather than leaving one issue open: the binding half is not an implementation gap. componentPropertyReferences is the only route the Plugin API offers for wiring a node property to a containing component's property, and it admits exactly visible, characters, and mainComponent — a boolean, text, and instance-swap pass-through on a sublayer's node property. A nested instance's own variant property is not in that set, so the general case has no setter as the API is typed. That needs settling against the current API documentation before any code, which is a different kind of work from the fill.