Skip to main content
Question

[MCP] Text Rendering Issue When Updating Design System Component Text Through IDE

  • May 21, 2026
  • 0 replies
  • 1 view

maymayHoliday

Context

I was using VS Code Copilot to convert an existing design into components from my design system inside Figma.

The workflow was:

  1. Start from a screenshot-based design.
  2. Use VS Code Copilot with Figma integration to rebuild the screen using my design system components.
  3. Replace the default component text with the actual text from my design.

The problem appeared when Copilot, through the Figma Plugin API runtime, attempted to update the text content inside these design system components.
 

What I Expected

For a design system input field, the automation should be able to:

  1. insert the component
  2. set the component state and variant
  3. update the text values
  4. show the updated result correctly on the Figma canvas
     

What Actually Happened

I observed two different failure modes:

  1. In some cases, text-property updates failed entirely.
  2. In other cases, the internal text data changed successfully, but the Figma canvas still displayed the old default text.

So the issue was not just “the text update failed”. In some cases, the update succeeded internally, but the rendered result on the canvas did not refresh.

 

Why I Ran a Minimal Experiment

To isolate the issue, I created a minimal reproducible example with only one input component.

The goal was to determine whether the problem came from:

  1. the wrong component
  2. the wrong variant
  3. failed text write
  4. successful write but failed repaint

Minimal Test Setup

I tested a single input field from my design system with this intended configuration:

  1. Variant = Inactive
  2. Status = Normal
  3. Input text = Populated
  4. State = Default

Target visible result:

  1. title = Amount
  2. value = 49.00 HKD

I then tested two separate update methods.

 

Test 1: Component Property-Based Text Update

In the first test, Copilot used the Figma Plugin API runtime to:

  1. create a new frame
  2. insert one design system input component
  3. set non-text properties such as variant and state
  4. update text through the component’s exposed text properties

Text properties attempted:

  1. Title text = Amount
  2. Active text = 49.00 HKD

Observed result:

  1. ✅ non-text properties were applied successfully 
  2. ☹️ text-property writes failed
  3. ☹️  Figma returned errors indicating the text properties could not be updated because the component used a font that was not available
  4. the stored values stayed at the defaults
  5. the canvas also displayed the defaults

Meaning:

  1. this update path failed before the new text was stored

Test 2: Direct Descendant Text-Layer Update

In the second test, Copilot used the Figma Plugin API runtime to:

  1. create another new frame
  2. insert the same input component
  3. set the same non-text properties
  4. bypass component text properties
  5. directly find the visible descendant text nodes inside the component instance
  6. change those text nodes from:
  7. Title to Amount
  8. Active text to 49.00 HKD

Observed result:

  1. no error was returned
  2. reading the instance back showed that the internal text values had changed successfully
  3. the component now stored:
  4. Amount
  5. 49.00 HKD
  6. however, the canvas screenshot still displayed:
  7. Title
  8. Active text

Meaning:

  1. the data changed successfully
  2. the canvas did not repaint correctly

What I Did Manually

After the minimal test, I manually duplicated the frame directly in the Figma editor.

Observed result:

  1. the duplicated frame displayed the correct updated text
  2. the component now visibly showed:
  3. Amount
  4. 49.00 HKD
  5. reading the duplicated frame confirmed that the stored internal text and the visible canvas output were now aligned
     

     

Meaning:

  1. manual duplication in the Figma editor triggered a redraw or rehydration step that the plugin-driven path did not trigger

What This Proves

The experiment isolates two separate issues in the plugin-driven update path:

  1. Text-property writes can fail at the component-property level.
    Reason:

  2. the Figma Plugin API runtime returned font-related errors when updating exposed text properties on the component

  3. Direct text-node writes can succeed internally but still fail visually.
    Reason:

  4. the internal instance data changes correctly

  5. the Figma canvas can continue rendering stale default text

  6. the visible result does not match the underlying instance data until a manual editor-side action occurs

So this is not simply a “write failure”. It is also a render invalidation or repaint problem.


Why This Matters

This creates a reliability issue for any plugin-driven or Copilot-driven design conversion workflow.

A tool may:

  1. correctly update the component instance data
  2. read the updated values back successfully
  3. still leave the user looking at stale default text on canvas

That means:

  1. model state and visual state can diverge
  2. plugin-side verification alone is not enough
  3. visual validation is required
  4. manual editor actions may be needed to make the canvas catch up

Expected Behavior

When text inside a component instance is updated through the Figma Plugin API runtime:

  1. the internal instance data should update
  2. the canvas should repaint immediately
  3. the visible text should match the stored text
  4. no manual duplication or editor-side refresh should be required

Conclusion

This appears to be a Figma Plugin API runtime issue involving text updates inside design system component instances.

More specifically:

  1. one update path fails at the property-write level because of a font-related restriction
  2. another update path succeeds in stored data but does not reliably trigger a correct canvas repaint
  3. the Figma editor’s own manual duplication path appears to force a repaint that the plugin-driven path does not

So the root issue is not that the design system component is wrong, and not that the intended text was never written. The issue is that plugin-driven text updates and visible canvas rendering can become inconsistent.

Thanks!