Itsy: A Free Pack for Writing Web Apps that Run in Coda

[Saulo_Vallory]

Thanks for taking the time to clarify all that! The Figma approach would be my recommendation for Coda, not you though.

@Bill_French

Figma’s plugins are sandboxed and sanitized which means there are many limitations to what you can build

I didn’t know they were sanitized! But I also haven’t run into any restrictions so far. They even allow a Plugin which is almost an IDE! Check this out:

I would love to have some like that (that was sanitized and restricted ) in Coda

[Bill_French]

@Saulo_Vallory

I didn’t know they were sanitized!

@Saulo_Vallory

But I also haven’t run into any restrictions so far.

That’s good. Maybe I’m overblowing the limitations or the Sandbox approach is finely tuned in a manner that allows developers to do what they need in the vast majority of use cases.

The plugin API doesn’t allow you to access anything outside of the current file it’s running in. Plugins can’t access:

• Styles and components from any team or organization libraries. The Plugin API can only access styles, components, and instances that are currently in the file, or have been imported into the file via a function like importComponentByKeyAsync()
• External fonts or web fonts accessed via a URL. Plugins can only access fonts that are accessible in the editor, which includes Figma’s default fonts, shared organization fonts, or fonts stored locally on your computer. You’ll be required to load any fonts you want to use in your plugin. This doesn’t apply to fonts you want to use in your plugin’s UI.
• Other file metadata like the file’s team or location, permissions, or any comments associated with that file. The includes the version history of that file. You can get read access to these aspects of a file via Figma’s REST API.

And despite their plugin success, it’s approach has not been a bed of roses. Even so, it’s about the best approach one could expect given the hopes of developers and the constraints needed to appease the CSOs.

[Saulo_Vallory]

@Bill_French

Styles and components from any team or organization libraries. The Plugin API can only access styles, components, and instances that are currently in the file, or have been imported into the file via a function like importComponentByKeyAsync()

@Bill_French

Other file metadata like the file’s team or location, permissions, or any comments associated with that file. The includes the version history of that file. You can get read access to these aspects of a file via Figma’s REST API

I see these two as a good thing! It does not make sense to me that a plugin would access other files. But there’s nothing (that I know of at least) stopping you from asking the user for permission to access their account via the API, right inside the plugin. You can then make requests to read the entire files.

@Bill_French

External fonts or web fonts accessed via a URL

That’s not a limitation imposed on the plugin, figma documents do not embed fonts

[Bill_French]

@Saulo_Vallory

That’s not a limitation imposed on the plugin

All of these references and texts are Figma’s own support content.

[Wayne_Simpson1]

Is there a new Itsy pack yet

[Bill_French]

Nope. I think Itsy is a dead end unless something materially has changed in the ability of the file system of a Pack to render content and code.