After importing variables from figma, remote update is not triggered while using genericVersionedStorage

[kibbon]

Token studio v2.0.3 / Figma 124.3.2

Describe the bug
Total 3 bugs:

1. Import variables from figma, don't triggle updating to remote while using genericVersionedStorage -> expect triggled as usual.
2. Export variables sets generate WRONG set name and mode name.
3. Import variables changes list unchanged token.

To Reproduce
Steps to reproduce the behavior:

1. Open empty figma file, use any genericVersionedStorage setting with a empty token json file
2. Add variables in figma like this:
   
3. Click import variables in token studio:
   
4. Click export variables in token studio, the generated variables set and mode name is wrong:
   
   
   As mentioned in Bug 2, the variable set name and mode name are all full name.

Expect: Name the set as 'Color/ColorGroup', modes as 'Dark' and 'Light', generate 1 collection with 2 modes instead of 2 collections

5. Click import variables in token studio again, we can see that the bad effect of wrong collection name:
   
   There is NO WAY to change our collection name again, as it's legal in figma variable system, so we need token studio to support it.
6. After we temporarily adjust the names of collections and modes, we changed the value of variable color, and try import:
   
   As mentioned in Bug 1, the value of the changed token is updated, but the "updating generic remote" toast didn't show, and no update request is sent to the remote end.
   If we click "Apply to selection" or add/remove/edit token, it would update as usual.

Expect: "Import variables" should triggle updating.

7. Import variables again, we saw changed list contained unchanged tokens:
   

As mentioned in Bug 3, unchanged token value should be hidden.

Expect: List changed token only.
​

Tasks

Beta Give feedback

No tasks being tracked yet.

[kibbon]

Please note this issue

[keeganedwin]

Hey @kibbon, just to confirm, you're importing variables then exporting them back to keep them in sync. This however is expected behaviour with importing and exporting because of the way the plugin translates them.

When importing variables, the plugin translates Figma modes and collections to sets and subsets. Your Color/ColorGroup collection was imported as the set with its modes as sub-sets Light & Dark. So it doesn’t involve themes. Exporting on the other hand involves themes-groups and themes or if you're not a Pro user then sets that are translated to figma collections and modes. So your set Color/ColorGroup with sub-sets Light & Dark were translated to two different collections with 1 mode each.

Due to these differences in functionality you can’t use both to keep them in tokens/variables in sync. We usually advise users to stick to one flow. So if you’re importing variables then you stick to this flow because it’s the best way of keeping changes in sync, and if you’re exporting you want to stick to this flow. There is workaround for using both to keep tokens & variables in sync but it’s extremely fragile and unreliable.

[keeganedwin]

However, here's the ticket for a feature on our feedback platform FeatureBase, that if implemented can possibly resolve the flow of using both functions to keep variables in sync.

[kibbon]

Hey @kibbon, just to confirm, you're importing variables then exporting them back to keep them in sync. This however is expected behaviour with importing and exporting because of the way the plugin translates them.

When importing variables, the plugin translates Figma modes and collections to sets and subsets. Your Color/ColorGroup collection was imported as the set with its modes as sub-sets Light & Dark. So it doesn’t involve themes. Exporting on the other hand involves themes-groups and themes or if you're not a Pro user then sets that are translated to figma collections and modes. So your set Color/ColorGroup with sub-sets Light & Dark were translated to two different collections with 1 mode each.

Due to these differences in functionality you can’t use both to keep them in tokens/variables in sync. We usually advise users to stick to one flow. So if you’re importing variables then you stick to this flow because it’s the best way of keeping changes in sync, and if you’re exporting you want to stick to this flow. There is workaround for using both to keep tokens & variables in sync but it’s extremely fragile and unreliable.

Thanks for your reply! Therefore, the imported and exported collections correspond to the same collection, which is expected under the current token studio plug-in design? From a user perspective, we still hope that this problem will be solved in the future. Until then, I would advise colleagues in our company not to try to use the export function.
In addition, this issue still reports two other bugs, including diff change display exception and import not triggering remote side update. Please pay attention to these two issues.