🥇 ♦️ 💂 菲米罗。为Figma制作一个插件（为Miro制作一个插件） 👩‍👩‍👧‍👦 👵🏽 ⚱️

在第三天，我们根据经验丰富的同志的建议，决定创建一个插件，该插件可以将Figma的布局导出为PNG图像到Miro。

我们的团队热衷于将这个想法变成现实，获得一个体面的大奖的机会尤其激起了人们的热情，因为在完全随机的情况下，我们在Miro 的插件竞赛完成之前不久就开始创建插件。

公平地说，值得注意的是，这种集成的想法已经在我们设计师的脑海中徘徊了很长时间。不久前，整个设计团队从一堆Sketch / Zeplin迁移到了现在流行的Figma平台。转移-已移动，但是许多使用旧工具的熟悉情况已不可用。

特别是在2019年8月，机器人开始在一家大型电子商务公司的网站上工作。使用Sketch的传统方案如下：我们使用Miro中的特殊插件从Sketch上卸载布局，并与客户团队进行讨论。我们将Miro用作该项目所有材料的存储库。使用注释和收集对屏幕地图的更改（排列箭头）非常方便。

这个项目大约有450个版面。一天一次几次，我们都卸载了版面，并进行了一些细微的更改，因此编辑一次也没有。由于缺少必要的插件，因此Figma中的所有卸载操作都是手动进行的：已导出的PNG / JPG，已保存，放置在Miro中，并以正确的顺序布置。

替换文本-一分钟，卸载-从20分钟到一个小时。为了用15种布局替换一个（！）Word，设计师花了整整一个小时的时间。我们意识到出口需要实现自动化，从而节省了设计师和美术指导的时间和神经。

因此，有了打字稿，react和mobx（感谢Figma，您有机会使用很酷的工具），我们开始研究插件。

最初，根据我们的乐观假设，工作时间为一周，最多两个星期-任务只是将适用于Sketch的Miro Plugin的所有功能转移到Figma导轨上。

但是，就像与研究活动相关的软件开发一样，乐观的估计可能与现实相去甚远。因此，在创建插件的过程中，出现了相当多的技术障碍。

障碍物次数：REST API Miro

由于Figma是一个Web应用程序（电子用于桌面），因此我们意识到我们的插件将在浏览器环境中工作。因此，我们将发送给Miro的REST API的所有请求都将受CORS浏览器策略的约束。

这意味着，如果我们要使用应用程序/ json格式发送带有正文的请求（例如，用于授权），并且服务器不会“喜欢”该请求，则服务器的响应将“发送”给我们。就我们而言，它发生了。

因此，决定将您的代理写在node.js上，这将符合我们的需求，并通过登录名/密码进行授权。为此，代理使用著名的中间件cors进行表达。

第二个障碍：再次是REST API Miro

在研究了Miro REST API的官方文档并尝试实现我们将Figma从Imagema导出到Miro的想法的基础上，我们意识到从Miro的所有可用小部件中（通过小部件我们指的是贴纸，形状，文本等）。 REST界面不允许我们创建带有图片的我们感兴趣的小部件。这意味着我们在Figma级别成功转换为PNG的那些布局，无法发送到Miro所需的板。

但是后来他们想起了一个类似的Sketch插件，该插件以某种方式知道如何进行此类导出。可以这么说，决定接管同事的经验并查看sketch_plugin源代码，因为Miro的同仁将源代码发布在Github上。然后一下子发现了几件事：

在可预见的世纪中，我们不打算为Sketch创建插件，因为用于开发Sketch插件的来自Objective-C和JS的科学怪人在查看源代码时会在方括号中看到波纹。

如果您还喜欢将JS和Objective-C的所有优点相结合，请上课。
屏幕截图的模型位于此处。

Sketch插件使用其他API，可在此处使用。该API提供了在Miro中的选定板上创建图像的功能。这是一个加号。不利的一面是我们没有找到有关它的文档。

经过这些启示后，我们的团队决定以Sketch插件中的神秘API为基础。在黑暗中徘徊，没有此API的规范，我们仍然克服了将图像导入Miro的问题。而且，似乎可以结束这首史诗，但没有。

障碍三：表现

在该插件的第一个beta测试期间，结果表明用户通常对将图像从Figma导出到Miro的漫长过程感到不满意。例如，大约3分钟，卸载了30个布局。这三分钟中大约70％的时间是通过将请求正文发送到服务器而获得的。

事实证明，我们的缺点是在代理应用程序上/ json被用作图像和元数据的预期格式，并且这些图像本身以UInt8Array的形式传输。自然，我们将期望的格式更改为multipart / form-data，现在在可接受的50秒内加载了相同的30种布局。当然，仍有增长的空间，但是速度增加了3倍，这是我们的小胜利。

障碍四：边缘场景

似乎插件使用场景很容易让人耻辱，但在工作过程中，我们遇到了插件操作的大量未处理边缘状态，必须采取一些措施。

如果我们花一些时间将某个功能（例如授权，从Figma中导出布局作为图像等）用于N，那么处理此功能的边缘脚本也将花费N时间。而且，当然，这些额外的时间大大改变了插件的发布日期。但是，这项工作可以使工具具有较高的弹性。

障碍五：授权

如果您突然想为Figma编写插件，请做好以下准备：通过第三方服务（google，facebook，slack等）授权将不可用，因为Figma中的插件通过iframe起作用，而oAuth协议不支持通过浮动框架进行授权。某些安全策略的强度（尤其是防止点击劫持攻击）。

在我们的插件上下文中这意味着什么？这意味着通过第三方服务在Miro中注册的用户将无法使用用户名/密码通过插件登录，也无法选择要从Figma导出布局的所需板。他们将无法执行此操作，因为通过第三方服务注册时，Miro仅为将来的用户帐户设置电子邮件，而没有设置密码。

我们选择的解决方法非常简单：我们警告插件用户，如果他是通过Miro中的第三方服务注册的，并且没有密码，则他需要使用标准功能“通过电子邮件恢复密码”才能接收或恢复密码。

结果，我们未能成功与Miro竞争。由于我们在业余时间参与了该项目，因此在开发2周时进行的乐观评估并未实现，并持续了2个月。

Miro 宣布，在解决技术问题的同时，这种情况更加令人生气获奖者包括Semyon Volkov和Roman Krasilnikov，他们使用了类似的Figma2Miro插件。他们的项目排名第六。与我们的实现不同，我们的实现仍然更多是Figma插件（从UI和启动导出的平台的角度来看），他们为Miro制作了该插件。

但是，不幸的是，这些家伙创建的解决方案无法满足机器人的需求，这就是为什么我们继续开发自己的插件的原因，该插件很快就准备好了。该插件称为Figmiro。

现在，感谢Figmiro，我们的设计师节省了很多时间，将布局从一个系统导入到另一个系统。例如，从谢尔盖·库特科夫（Sergey Kutkov）的报价中卸载布局的那个小时变成了2（！）分钟。

总而言之，我想指出，关于Figmiro的工作更多是研究性质的。当您以一种或另一种形式进行两个第三方系统的集成时，您需要为高度的不确定性和解决问题的框架中缺乏信息做好准备。在我们的案例中，我们花费了大量时间来研究两个平台的API功能，测试假设并找到解决方案。

Figmiro插件可以做什么

一切工作都与我们在Sketch中使用的相同：选择框架，单击按钮，然后在Miro中显示布局：

将选定的帧上传到Miro中的选定板。
覆盖先前卸载的布局，同时在板上保持一定位置。

将来，我们计划支持插件并以加快卸载和同步过程的方式优化其工作。如果Miro更新了其API，我们将为其重建插件。

Figmiro插件有效

设计师Anton Magartsov，领先的iOS开发人员Roman Churkin，前端开发人员Anton Eryshev和Ilya Krupnov，服务器开发经理Andrei Muravyov和艺术总监Sergey Kutkov。

所有链接：

插件在Github上，
代理在Github上，
插件中的figma。

我们正在收集有关GitHub上插件运行情况的反馈。

PS
我们知道为服务创建公共API的难度很大，同时要最大程度地满足这些API用户的所有需求。

Redmadrobot团队感谢来自Miro和Figma的人员提供了使我们日常业务流程自动化的机会。

菲米罗。为Figma制作一个插件（为Miro制作一个插件）