Spacing Grid export support

[IljaKosynkin]

Good time of the day!

First of all, thank you for the all great work you've done! I've enjoyed both working on and working with the script.

Said that, we have a case in our company that is not covered by the script yet: a Spacing Grid export (basically margins, paddings etc; spacing between the components). I took a liberty to prepare a draft of implementation for your review and I hope that after some discussion and changes we would be able to merge it into the main script.

Note that I haven't created or changed any tests on purpose, as I'm not sure the implementation will be fine from your standpoint. I will gladly add them, when I'll get a greenlight that everything is good on implementation side.

You can see an example of spacings I was going off (prepared by our designer) below:

[subdan]

Hello, @IljaKosynkin. Thanks for the idea and the PR! I have already thought about adding support for exporting spacing from Figma and decide that FigmaExport should not support it for the following reasons:

1. FigmaExport was designed primarily as a tool to simplify and speed up the export of Figma's image components, color styles and text styles. Manual exporting is time-consuming. Colors and images change frequently, but spacings is rarely changed. If you change the spacing if Figma, you can change it very quickly in the code. Moreover, Figma does not have such an entity as spacing, which can be exported.
2. Each company has its own approach to working with spacings. Something universal will be difficult to do. E.g. someone separates them into vertical and horizontal, and some do not.

You can create a Discussion or Issue, describing what you want to do. If other developers vote for it, I will consider adding such functionality. You can continue to use fork in your company and add new features for your need.

[IljaKosynkin]

Hey, @subdan, thanks for the quick response!

I respectfully disagree with your assessment. Let me explain why:

1. My personal experience is that colors are rarely touched, but images and spacings are changed on a regular basis. And Figma doesn't really have a separate entities for images and colors either. As far as I can see in the code, colors are fetched via styles and images via components (and then actual image is loaded via image endpoint). That doesn't really count as having a specific entity, in my opinion.
2. The same applies to colors, images etc. does it not? You've already specified a contract the Figma file has to follow in order for the script's subcommands to work (i.e. components being grouped in the frames with a certain name). I can quite easily imagine a few other ways of representing the same data differently. I do not critique you for it, by any stretch of imagination, quite the opposite - I believe it is perfectly fine to put forward a contract and work only when the contract is adhered to. However, I fail to see why spacings has to be so different, that you can't specify a contract for it? We can discuss some ways to make the implementation more flexible and that is a welcomed discussion, however I don't see it as a point to reject the feature completely.

I've created a discussion poll here to see what people think. I would suggest leaving this PR alive until poll is done and closing it if majority votes "No" and continuing work from the current state of affairs otherwise

[subdan]

1. For colors Figma have Color Styles, for images — Components. A designer uses Color Styles and Components to compose a screen. If a color or image component changes then the screen also changes. Both entities can be easily exported using Figma API. Does your designer use components for spacings to compose a screen? If a spacing component changes then the screen also must be changed automatically. So, every spacing on the screen must be specified using spacing components. I've found an example of how to use spacing components: https://uxdesign.cc/worry-less-about-spacing-in-figma-8b44f34db4f5 Do you use the same approach?

2. Yes, I agree. We need to discuss it to make the implementation more flexible.

[IljaKosynkin]

Ah, I get your point now and it is a great one! I did discuss it with our designer and she wasn't particularly excited about the idea. She told me that she personally does not like this approach as if anything changes in the design it is quite painful to unwind the design and then compose it back. I personally feel like this approach is good one to use, but I'm no designer and the final word is by them.

But does it change anything from export implementation view? The designer shall design a spacing grid and adhere to it. Wherever particular designer chooses to use spacing components while composing the screen or not - is up to designer, we do not particularly care about it, as long as spacing grid itself is properly updated with every such change?