feat(icon.ts simplify-node-response.ts): optimize icon handling with direct MCP response integration

[miraclehen]

Overview

This pull request optimizes the icon handling process in the frontend project by transitioning from LLM-based icon recognition and individual downloads to directly utilizing the Figma MCP server response. During local development, an LLM prompt manages icon file checks, creation, and correct referencing. I suggest adding prompt documentation and Figma icon naming guidelines in the README to ensure the Figma MCP server operates as expected.

Changes Made

• Icon Handling Update:
  • Icons are now sourced directly from the icons resource in the Figma MCP response, eliminating LLM-based recognition and manual downloads.
  • During development, the LLM prompt identifies icons, checks if they exist in the src/assets/icons directory, creates new files using the icon field value if absent, and ensures correct referencing of the icons resource. Existing files are reused to avoid duplication.
  • Icon filenames are generated with an MD5 hash based on file content, ensuring unique filenames and preventing duplicate writes in the frontend project.
  • This change focuses exclusively on icons, with no component-related modifications.

Prompt

These were the reference prompts I used while working on this PR:
Constraints:

• If an element returned from the Figma MCP data contains an icon field, it indicates that the element is an icon and must use the corresponding resource from the icons assets.
• Before using the icons resource, check if the corresponding file exists in the src/assets/icons directory of the project root.
  • If it does not exist, create a new file in that directory named after the value of the icon field, and write the resource content from Figma into that file.
  • If it already exists, reuse the existing file without recreating it.
• The component name used for the import should remove the suffix after the last underscore (_) in the filename.
  For example, if the icon field is arrow_right_aba990.svg, the usage should be:

import ArrowRight from "./assets/arrow_right_aba990.svg?react";
<ArrowRight />

Documentation Update Suggestion:

Suggested adding a section in the README with LLM prompt guidelines and Figma icon naming recommendations to guide users interacting with the Figma MCP server during local development, ensuring the server operates as expected and standardizing icon naming.

README Update (Suggested)

To ensure users can effectively interact with the Figma MCP server, I suggest adding the following guidelines to the Readme files.

Suggested Prompt:

1. If a Figma node in the MCP response contains an icon field, it indicates the element is an icon, and the corresponding icons resource from the response must be used.
2. Before using the icons resource, check if a file named after the icon field value (e.g., arrow_right_aba990.svg) exists in the src/assets/icons directory of the project root.

• If the file does not exist, create a new file in src/assets/icons using the icon field value as the filename and write the corresponding icons resource content from the Figma MCP response into it.
• If the file exists, reuse it without modification to avoid duplication.

3. Based on your project's specific method for using SVG files, define how the icon should be imported and utilized (e.g., as a React component, or other approach).

Suggested Figma Guidelines

1. Icon names should consist of ASCII characters only. Avoid using non-ASCII characters or symbols to ensure compatibility with file systems and development environments.

This is a bold change, but local testing shows promising results, and I’d greatly appreciate feedback from the maintainers to ensure it aligns with the project’s goals. 😊

[GLips]

Was able to take a look at the code and take it for a spin too. This is awesome—I really like a lot of the stuff in here.

I love the logic in getNodeCategory which identifies all the parts of an icon, rather than the current implementation which sometimes only grabs one vector from a icon composed of many parts. This is a huge fix for SVG handling.

The deterministic naming seems super useful too—especially if we could do it solely based on the Figma file metadata (i.e. before downloading the file itself). That way we could check the filesystem first to see if a file exists before we kick off the download.

One issue—I'm not sure PNG images are supported and downloaded anymore in this version? We'll need to maintain support for that.

There are two other things I'm a bit concerned about at a higher, more architectural level. Would to chat through more.

1. Combining image downloads with data request

I'm not sure about combining the image downloads with the initial Figma data request. The reasons I can immediately think of are twofold.

Potential Issue: Latency

Increases latency of the initial call to get Figma data. If you're iterating on a design and calling the same frame, or following up on an initial design with a focus on a child frame the LLM didn't get quite right, downloading images would slow that iteration down.

I kinda like the Unix-philosophy of one-job-per-tool for the MCP, but I do also see the benefit of combining the two functions into a single function where it's not the LLM's direct responsibility to ask for image downloads.

I could go either way here honestly. Curious to hear your thoughts.

Potential Issue: CMS-backed Projects

Some developers might be working in CMS-backed systems, where images are pulled dynamically and Figma images only serve as placeholders.

Combining the two features means developers can't include "ignore the images in the file, and instead pull from our CMS this way: ..." in their prompt.

Addressing this first concern

We might be able to address both issues by including a arguments for the get_figma_data function like download_icons and download_images. Still not certain about the ergonomics of a tool with more arguments vs. split tools for different jobs.

That would probably work, but we also just added some SVG options to the download_figma_images tool. In my experience adding too many options to tool calls can confuse LLMs more than having more separated tools.

2. Including SVG strings in response

This one I feel more strongly about than the first.

Including the full SVG strings for icons in the get_figma_data request adds a lot of tokens to requests for frames that have a few SVGs, or even a single complex SVG.

The technique of downloading them to a local tmp directory is pretty clever, but I'm just concerned about blowing up LLM's context windows. Also if I'm not mistaken, an LLM would need to create the SVG files on its own from the passed in data via subsequent tool calls.

Addressing this second concern

I feel like downloading SVGs as files is a better solution there, since SVGs can be stored and served as files, and we already run locally on developers' computers, so have access to read/write files without LLMs driving everything.

---

Looking forward to hearing your thoughts on the above and working to get this merged. Thanks for another great contribution!