Arbeitsfläche trifft Code: Aufbau der Code-Ebenen von Figma

Letzte Woche haben wir Code-Ebenen in der Beta-Version eingeführt, eine neue Ebenenart in Figma Sites, die durch React-Code gerendert wird. Benutzer können Code-Ebenen verwenden, um die volle Kraft des Webs auf die visuelle Arbeitsfläche zu bringen und interaktive Erlebnisse mit Formularen, Shadern, Interaktionen und APIs zu erstellen. Gleichzeitig verhalten sich Code-Ebenen wie andere Figma-Ebenen, indem sie in Frames verschachtelt, in Komponenten verwendet und frei auf der Arbeitsfläche verschoben und in der Größe verändert werden können. Darüber hinaus können Benutzer*innen mit einem einzigen Klick Entwürfe, die in Figma erstellt wurden, in Code-Ebenen umwandeln und Verhalten hinzufügen, indem sie dasselbe KI-Modell nutzen, das auch Figma Make antreibt.

Um Code-Ebenen in Figma zu erstellen, mussten wir zwei unterschiedliche Denkmodelle über Software miteinander in Einklang bringen: Design und Code. Heute ist die visuelle Arbeitsfläche von Figma eine offene, flexible Umgebung, die es den Benutzer*innen ermöglicht, schnell Designs zu iterieren. Code schließt weitere Möglichkeiten auf, ist jedoch strukturierter – es erfordert eine hierarchische Organisation und präzise Syntax. Um diese beiden Modelle in Einklang zu bringen, mussten wir einen hybriden Ansatz schaffen, der die schnelle, explorative Natur des Designs respektiert und gleichzeitig die vollen Fähigkeiten des Codes freisetzt.

Zur erfolgreichen Umsetzung mussten drei Herausforderungen gelöst werden:

1. Nahtlose Integration von Code-Ebenen und -Komponenten in das Ökosystem von Figma
2. Entwicklung einer leistungsstarken und dennoch benutzerfreundlichen IDE zur Unterstützung der Code-Anpassung
3. Aktivierung von Multiplayer-Kollaboration zwischen Designer*innen und Entwickler*innen

Code als Material

Code ist traditionell als ein Dateisystem strukturiert – ein Baum von Verzeichnissen, wobei Code-Dateien die Blattknoten sind. Während dieses Modell großartig für die Entwicklung ist, lässt es sich schwer mit der räumlichen 2D-Arbeitsfläche von Figma in Einklang bringen. Beispielsweise können Objekte überall in der visuellen Arbeitsfläche existieren, während sich Code-Dateien an einem bestimmten Ort im Dateisystem befinden. Diese Unstimmigkeit führt zu praktischen Herausforderungen im Workflow: Wie wird eine visuelle Ebene kopiert, wenn diese einem bestimmten Dateipfad entspricht? Ist die Quelle der Wahrheit die Arbeitsfläche oder ein Dateisystem? Sollte das Klonen einer Code-Ebene eine Instanz davon erstellen, wie es in der Programmierung üblich ist, oder eine verzweigte Version, so wie es bei der Duplizierung in Figma traditionell der Fall ist?

Wir wussten, dass der Code in Figma sowohl Designer*innen als auch Entwickler*innen vertraut sein musste, was bedeutete, dass Benutzer*innen die Möglichkeit behalten sollten, Code-Ebenen auf der räumlichen Arbeitsfläche frei zu manipulieren. Die Lösung war, Code-Ebenen als ein neues Arbeitsflächengrundelement zu implementieren. Code-Ebenen verhalten sich wie jede andere Ebene, mit vollständiger räumlicher Flexibilität (einschließlich Verschiebung, Größenänderung und Neuzuordnung) und nahtloser Layout-Integration (wie Platzierung in Autolayout-Stapeln). Am wichtigsten ist, dass sie sich leicht duplizieren und iterieren lassen und so den freiformigen und experimentellen Charakter der visuellen Arbeitsfläche nachahmen. Dies ermöglicht die Erstellung und den Vergleich verschiedener Versionen von Code nebeneinander. Typischerweise erfordert das Erstellen von zwei Kopien des Codes zum Vergleich das Erstellen separater Git-Zweige, aber mit Code-Ebenen ist es so einfach wie ⌥ zu drücken und zu ziehen. Dies erstellt automatisch einen Fork des Quellcodes für schnelles Ausprobieren.

Wir haben uns entschieden, React zu unterstützen, weil sein Komponentenmodell eng mit dem Komponentenkonzept von Figma übereinstimmt. Komponenten in Figma sind wiederverwendbare und flexible Bausteine, die Designer*innen zur Erstellung von Benutzeroberflächen verwenden. React funktioniert auf die gleiche Weise – Entwickler*innen kombinieren wiederverwendbare React-Komponenten, um Bildschirme und Apps zu erstellen. Zudem stimmen die Props von React direkt mit dem Konzept der Komponenten-Eigenschaften in Figma überein, weshalb wir sie miteinander verknüpft haben. Du kannst können Eigenschaften im Code definieren und diese dann visuell mit anpassbaren Steuerelementen wie Kippschaltern, Schiebereglern und Dropdown-Menüs bearbeiten.

Eine voll ausgestattete IDE im Web

Während Code-Ebenen vollständig mit KI erstellt und bearbeitet werden können, wussten wir, dass Benutzer*innen auch den Code direkt bearbeiten möchten, um volle Flexibilität zu erreichen. Um dies nahtlos zu gestalten, haben wir ein modernes Codier-Erlebnis in Figma integriert, beginnend mit unserer Wahl für den Kern des IDE-Motors: CodeMirror.

CodeMirror bietet eine erweiterbare Basis für webbasierte Codebearbeitung und ermöglicht es uns, Erweiterungen für Funktionen wie Farbthemen, Suchen-und-Ersetzen und Zeilennummern zu definieren. In vielen Fällen mussten wir die Standardverhalten außer Kraft setzen, um den Code-Editor in Figma zu integrieren; zum Beispiel haben wir das Standard-Undo/Redo-Verhalten von CodeMirror durch eine benutzerdefinierte Implementierung ersetzt, die auf unserem eigenen Undo-Stack basiert.

Wir erkannten früh, dass die Leistung zu einem Engpass werden könnte, insbesondere bei großen Codebasen. IDE-Aufgaben wie das Bündeln und Überprüfen von Typen können langsam sein, und da JS nur einen Thread verwendet, kann dies dazu führen, dass die UI beim Verarbeiten großer Dateien hängen bleibt. Um die Code-Umgebung von Figma schnell zu halten, führen wir den Großteil der Entwicklungstoolkette in einem Web Worker aus. Im Worker nutzen wir esbuild (erstellt von Figma-Mitbegründer Evan Wallace) für schnelle Bündelungszeiten und Tailwind v4 mit Lightning CSS für eine effiziente Stilkompilierung. Diese Tools sind teilweise in nativem Code geschrieben und in WebAssembly kompiliert, was eine erhebliche Leistungssteigerung bietet.

Um die Komplexität des Abhängigkeitsmanagements zu minimieren, installieren wir automatisch importierte Pakete von NPM oder einer ESM-URL. Es ist nicht notwendig, ein package.json zu initialisieren – importiere einfach die benötigten Bibliotheken und beginne mit dem Entwickeln in einer sicheren Sandbox. Die meisten Pakete funktionieren sofort in Figma, einschließlich beliebter Community-Favoriten wie Motion und React-Three-Fiber.

Gestalten von Code-Ebenen in Zusammenarbeit

Die Zusammenarbeit im Multiplayer-Modus steht im Mittelpunkt von Figma und ermöglicht es Teams, effizient zusammenzuarbeiten, um großartige Erlebnisse zu entwerfen und bereitzustellen. Unsere Multiplayer-Technologie unterstützt die gleichzeitige Synchronisierung für viele Knotenfelder, wie Position und Farbe. Aber es war noch nie für ein so komplexes Feld wie Quellcode verwendet worden, das potenziell Tausende von Textzeilen umfassen kann.

Diese neue Anforderung bot die Möglichkeit, unsere Vorgehensweise noch einmal zu überdenken. Die einfachste Lösung zur Synchronisierung von Bearbeitungen ist „last-write-wins“, bei der die Bearbeitungen aller Benutzer*innen die Bearbeitungen anderer Benutzer*innen überschreiben. Dies funktioniert für kurze Textstücke, wie z.B. Teile von UX-Text in einem Figma-Design, bricht jedoch zusammen, wenn gleichzeitig große Quellcodedateien bearbeitet werden, insbesondere bei langsameren Verbindungen. Wir haben auch festgestellt, dass dieses Problem sich verschärfte, wenn KI-Modelle gleichzeitig Änderungen am Code vornahmen, was zusätzliche Konflikte erzeugte.

Also suchten wir nach besseren Alternativen und wandten uns klassischen kollaborativen Textbearbeitungsalgorithmen wie Operational Transformations (OTs) und Conflict-Free Replicated Data Types (CRDTs) zu. OTs transformieren gleichzeitige Operationen, sodass sie konfliktfrei angewendet werden können. Sie bilden die grundlegende Technologie für viele kollaborative Texteditoren, wie zum Beispiel Google Docs. Allerdings verlangsamen sie sich, wenn Dateien mit vielen Konflikten zusammengeführt werden, da alle konfliktbehafteten Änderungen gegeneinander transformiert werden müssen.

Im Gegensatz dazu behandeln die meisten CRDTs jedes Zeichen als eine unabhängige Einheit. Dies erleichtert das Zusammenführen von Bearbeitungen erheblich, führt jedoch zu einem höheren Speicheraufwand. Um Aktualisierungen zu verarbeiten, muss die gesamte Historie des Dokuments im Speicher neu aufgebaut werden, selbst wenn es keine gleichzeitigen Bearbeitungen gibt (was der häufigste Anwendungsfall ist). Dies führt zu einem Speicherüberlauf und verringert die Leistung.

Glücklicherweise hat ein letztes Jahr veröffentlichter Artikel den Event Graph Walker (Eg-walker) eingeführt, ein neuer Algorithmus, der die meisten Vorteile von OTs und CRDTs bietet. Eg-walker stellt Bearbeitungen als einen gerichteten azyklischen kausalen Ereignisgraphen dar. Sein Algorithmus ist analog zu einem Git-Rebase; er ordnet mehrere divergente Zweige in eine lineare Reihenfolge um. Um gleichzeitige Ereignisse zusammenzuführen, baut Eg-walker vorübergehend eine CRDT-Struktur. Nachdem sein Auflösungsalgorithmus abgeschlossen ist, verwirft Eg-walker das interne CRDT und gibt Speicher frei. Im idealen Fall von sequenziellen, konfliktfreien Bearbeitungen sind Aktualisierungen nahezu kostenlos. Als Ergebnis ist es so schnell wie CRDTs beim Zusammenführen, hat aber einen minimalen Speicheraufwand wie OTs.

Angesichts der Leistungs- und Speichervorteile haben wir den Eg-walker-Algorithmus verwendet, um den Multiplayer-Kollaborationsdienst für Code-Ebenen zu erstellen. Wenn Benutzer*innen eine Code-Datei bearbeiten, sendet der Client dem Server eine Liste von Bearbeitungen. Der Server stimmt gleichzeitige Bearbeitungen von allen aktiven Clients mithilfe von Eg-walker ab und sendet eine aktualisierte Liste von Bearbeitungen zurück, wobei etwaige Konflikte gelöst werden. Mit dieser Architektur übernimmt der Multiplayer-Dienst die rechenintensivsten Zusammenführungsarbeiten für alle Clients, was schnelle Anfangsladezeiten und eine performante Benutzererfahrung selbst bei großen Dateisystemen ermöglicht.

Die Zukunft von Code und Design

Code-Ebenen sind nur der Anfang für Code in Figma. Wir erwarten, noch mehr direkte Manipulation auf Code-Ebenen zu bringen, um die Lücke zwischen Code- und Design-Workflows weiter zu schließen—damit Benutzer*innen nahtlos zwischen den Medien wechseln können, je nach Bedarf zu jedem beliebigen Zeitpunkt.

In seinem Vortrag „Inventing On Principle“, sagt der Interface-Designer Bret Victor, dass „Schöpfer eine unmittelbare Verbindung zu dem brauchen, was sie schaffen ... wenn man etwas macht, wenn man eine Änderung vornimmt oder eine Entscheidung trifft, muss man die Auswirkungen davon sofort sehen können.“ Während wir die Fähigkeiten von Code in Figma weiter ausbauen, lassen wir uns von dieser Idee leiten: Anstatt Design und Code in separate Tools zu unterteilen, sollten wir alle in der Lage sein, gemeinsam in einer gemeinsamen Umgebung zu entwickeln.

Code-Ebenen sind jetzt in Figma Sites in der Beta-Version verfügbar. Wir können es kaum erwarten zu sehen, was du kreierst.

Wir stellen Entwickler*innen ein! Erfahre mehr über das Leben bei Figma und stöbere in unseren offenen Stellen.