Plugins for Figma
With our design team trying out Figma, we learned that Figma supports custom plugins. The Springlabs team got curious about how much work would be involved in creating one ourselves.
Our team at Springload has recently switched from Sketch to Figma. The switch as opened us up to the thriving community of plugins and plugin creators. The Springlabs team got curious about how much work would be involved in creating one ourselves.
We learned that setting up a dev environment was only a few clicks away through the setup process in the Figma desktop app. Figma has a setup guide that will show you each step.
A plugin is divided into 2 parts and communication happens via the “postMessage” function.
This is the plugin UI shell, which has access to the browser API, and displays the custom plugin user interface.
After a brief discussion on how one of our designers uses Figma to manage breakpoints, we thought that would be an interesting angle to try for our first plugin exploration.
For our test workflow in Figma, we decided to use a naming convention based on breakpoints.
[BREAKPOINT] / classname
Which might look something like this:
If there is no breakpoint number given, it will be seen as the default values for that component.
Once the components are made, we wanted our plugin to create some semi-sensible breakpoints. Bear in mind that we didn’t start off with anything more than to try and see how Figma plugin development works.
The Figma API exposes all the local text styles as objects via the “figma.getLocalTextStyles()” function. These styles are not to be confused with CSS styles, they are objects used within Figma to describe the component. With a bit of parsing however, it’s easy to do a rough conversion. This was sufficient for now, but we are curious to see what the best approach for these conversions is.
With our rough conversion ready, the iframe can now send the data to our UI sandbox via “postMessage” method that is available via the Figma API.
Now we are back in the UI, we have access to the browser API, but not the Figma API.
Our workflow for this experiment was based on naming convention within Figma. If the name starts with a number, treat it as a breakpoint variation of that class.
The UI code simply finds the default component name and its breakpoint variant and parses a SCSS mixin based on the breakpoint number. There is a lot of room for improvement with this approach, but for our testing purposes it did the job well enough. To create a more verbose mixin, we map the breakpoint numbers to the function names of those mixins.
Our mapping looks something like this:
The end result gave us a handy snippet we could copy and paste into our SCSS files without the need to select each text style and its variants in Figma.
When discussing a design between designers and developers, the word “components” will pop-up as soon as the conversation starts. We were wondering if this conversation would be helped if there was a page with all the components neatly displayed.
With a better understanding of how Figma plugins work, we had a basic version going within a short afternoon. With a single click of a button, all exponents we neatly laid out on a dynamically created page, ready for handover conversations between developers and designers.
Figma plugin learnings
We loved the ease of creating a plugin. It didn’t take us long to get it up and running. The part that excites me the most is that the tool is written in JS. A tool to design a webpage built with web technology makes it easy for us to use our existing skills to customise our workflow. Fun times ahead!