The main idea behind the Figma to XState plugin is to transform Figma's prototype into an XState machine to use as a starting point for creating the real XState machine that developers will use.

At the moment, Figma's frames are exported as XState's states, and the reactions that navigate among different frames are transformed into events.

The SCROLL_TO reactions are a bit different from the NAVIGATE ones:

1. NAVIGATE events bring the users to a different frame, while SCROLL_TO ones do not
2. SCROLL_TO events mimic the standard scroll actions on the page, a behavior not typically bound to a state machine

So the main question is: what would the users expect to see in the XState's machine for Figma's SCROLL_TO event?

First of all, let's start with Figma's official docs, which say

[Scroll to action] is useful to replicate anchor links and interactions with scrollable elements like carousels.

Based on this, I can think of the SCROLL_TO reactions as anchor links, something that's stored in the URL's hash as part of the information on the current page.

Multiple anchors

The only difference with a standard web page is that a Figma prototype could have more than one "anchor" link for a single frame. See the following video, where I show the "multi-anchor" concept.

You can play with the original Figma file here.

So, remaining on the anchor similarity

• on a web page, you get one anchor at a time (only one thing is scrolled to when you click on an anchor)
• in Figma, there can be more than one anchor rolled to at once (in the video, I click on more anchors, and all of them are visible in the viewport)

Anyway, for the sake of simplicity, I will create one state for the anchor-free Figma frame (as already happening) and one state for every frame+anchor combo.