I randomly came across a blog post by Figma in which they explained how they built their plugin system. It’s a great read from an engineering perspective which discusses the creation of a secure sandbox. At that time I didn’t know how handy this knowledge would become for myself.

It started with playing around in figma with a shallow idea of having a token system in there and later export it into code consumable by ember. As a developer we are used to variables and referencing others, which made me wondering when I realized I couldn’t reference styles in Figma – Instead they created a new copy for each. That was a bummer to me so I aksed on Twitter what my options are:

Hello @figmadesign – I have a color palette and design tokens create from them (both are color styles). When I change the style for one of the color palette, I'd like the design token to update, too – is that possible?

— gossi (@unistyler) November 24, 2019

They responded and asked me to forward this request to their support, which I did. Their answer was similar to: “Unfortunately this is not possible in Figma itself but you are a developer, this is how you can develop Figma plugins, you’ll find a way” (this is the summary in my words ;-). Well played Figma support hence they were 100% right, so thanks for your answer and now following is the story what happened afterwards.

Learnings

I ended up developing three! plugins for Figma (currently under review) and here is what I learned:

• The documentation by Figma is well written. It’s great to jumpstart and they provide a github repo with examples.
• The knowledge that I gained from reading how Figma creating their plugin system (referred article in the first paragraph) was almost invaluable and made the understanding so much more clear.
• Figma suggests to use typescript and their scaffolding routine ships them right away. As a typescript lover this is super nice to work with.
• While you can use an established frontend framework, I decided against it and stick with vanilla TS/DOM/HTML+CSS. That said I didn’t write the best and cleanest code and treat the plugin as a snippet where it is ok to not go 100% on code quality.
• Testing is not “evangelized” by Figma (see detailed feedback below).
• Working with a package manager (npm/yarn) doesn’t come out of the box, which is good and bad (see detailed feedback below).
• When developing the third plugin I found my groove in how I want to organize the code for my plugins:
  • I separated UI and src by folders, which improved the handling for me.
  • Called it main instead of code (their suggestion).
  • Adopting CQRS/ES here in a way that: UI sends command and the main process responds with event messages.
  • Using the great Figma DS by Thomas Lowry
• Calling the ui was straight-forward, yet calling the “main” thread is unclear. In “regular” web development you call it backend, which doesn’t make sense here. Maybe Figma has a stance here on how to call it?

Feedback

The Figma plugin API is still very young, they have a roadmap with an outlook for further features. From what I learned working with this early feature set, this is my feedback:

Styles

As I mostly worked with styles, there is some confusion to it. From the API you have a styleId and in the UI you see the name of the given style. You see a given node with xyz as fill style, then you spot this one in your local styles, change it and nothing happens because it is a style from a team library that has the same name.

What I wanted to build into my plugin, too was the possibility to search for a style by name, but due to the limit of only accessing local styles was not possible yet. They mentioned APIs for full access to the team library already, which I think will make it possible (and will also incorporate the concept of access to various team libraries).

I also still hope, they will make it built-in to search for styles by name. See all swatches and hover them for the name takes a while.

Referencing XYZ

I was building my plugins mostly for the reason, that referencing in Figma is not possible. I wish they will built it into their product. Not only styles but also for example numerical values, e.g. when I use auto-layout and always want to give the same vertical and horizontal spacing or the size of a text, I for myself would want to manage this in one location and reference it from all implementations.

This would make all my plugins obsolete – then I couldn’t be more happy 🙂

Package Manager

They have examples showing how to use a package manager, I’d wish one of their scaffolding templates comes with it for quicker jumpstart. Also I think there is a great chance to move some code into packages, e.g. Figma types can go into it’s own package and future things, too.

Testing

As mentioned earlier, there is no official way to test your plugin. If they provide a mocking library, that would encourage more people to write automated tests and at some point, Figma can run those on their infrastructure prior to the publish process.

Publish Process

I wasn’t expecting a review process after publishing my first plugin but I admire this step and I even received feedback/ideas for what I can do to improve my plugin, this was the best surprise in the whole journey, thank you so much for it.

However, future releases of new version just happened without review. This has the chance to sneak in a bad behavior after your plugin got approved.

Threading / Background Process / Reactive Programming

At the moment plugins can not have a background process or any reactive programming. What would be nice for my plugin, was to listen on the change of one style and update the reference once that happens. None of this is possible at the moment but on their roadmap.

Here is a workaround recipe:

• Store your originals plugins data in the shared plugin storage
• Create a second plugin that will access this data
• The second plugin has a setInterval in the UI that sends commands to the main thread executing a specific routine

This works surprisingly good, yet has the downside that only one plugin can be active at a time. So once you invoke another plugin your “thread” plugin stops working.

Public Plugin Data

Sometimes you want to make your plugin data public to be consumable by third party consumers, e.g. readable by Figma’s REST API. At the moment this is not possible. I for myself decided to use jsonbin.io as third party provider and added an export feature to my plugin.

My idea would be to offer a third storage option from the Figma plugin API itself, next to plugin storage and shared plugin storage, something like a meta object on the node itself, which is exposed through the Figma REST API.
It’s a request that asks for much risk and requires another set of levels regarding ACLs – I know this for myself, yet isn’t bad to share the idea.

Summary

The plugin system for Figma is still young but already really great and I enjoyed working with it. Not only in code but also the way in which they publicly speak about the development of their system is very attractive. It seems to me they carefully take the next step and not overpace to deliver quality. That explains the limited API for now but I’m convinced they will improve it. Overall figma has done a great job with its plugin system and the communcation I had was very positive, thumbs up!

Update 2020-01-11: The article speaks about three plugins. I now merged them into one, which is Style References. With that, I refactored the code architecture and organized it way better to my style.

Lastly I leave some references, maybe somebody has an interest in what I did:

• My figma community profile: figma.com/@gossi
• Plugin: Style References – Github and Figma

-gossi