Le plan de travail allié au code : construire les calques de code de Figma

La semaine dernière, nous avons lancé les calques de code en version bêta, un nouveau type de calque dans Figma Sites rendu par du code React. Les utilisateurs peuvent utiliser des calques de code pour apporter toute la puissance du web au plan de travail visuel, en créant des expériences interactives avec des formulaires, des shaders, des interactions et des API. En même temps, les calques de code fonctionnent comme d'autres calques Figma, en cela qu'ils peuvent être imbriqués dans des frames, utilisés dans des composants et déplacés et redimensionnés librement sur le plan de travail. De plus, en un clic, les utilisateurs peuvent instantanément convertir les designs créés dans Figma en calques de code et ajouter un comportement en utilisant le modèle d'IA qui alimente Figma Make.

Pour créer des calques de code dans Figma, nous avons dû réconcilier deux modèles de pensée différents à propos du logiciel : le design et le code. Aujourd'hui, le plan de travail visuel de Figma est un environnement flexible et ouvert qui permet aux utilisateurs de faire évoluer rapidement leurs designs. Le code donne accès à d'autres capacités, mais il est plus structuré – il nécessite une organisation hiérarchique et une syntaxe précise. Pour réconcilier ces deux modèles, nous devions élaborer une approche hybride respectant la nature rapide et exploratoire du design tout en donnant accès à l'ensemble des fonctionnalités du code.

Pour réussir cela, il a fallu relever trois défis :

1. Intégrer naturellement les calques de code et les composants dans l'écosystème de Figma
2. Créer un IDE puissant mais facile à utiliser pour alimenter la personnalisation du code
3. Permettre la collaboration entre les designers et les développeurs

Le code comme matériau

Le code est traditionnellement structuré comme un système de fichiers – une arborescence de répertoires, avec des fichiers de code comme les nœuds feuilles. Bien que ce modèle soit idéal pour le développement, il est difficile de l'adapter au plan de travail spatial 2D de Figma. Par exemple, les objets peuvent exister n'importe où dans le plan de travail visuel, tandis que les fichiers de code résident à un emplacement spécifié dans le système de fichiers. Cette incohérence se traduit par des défis pratiques pour le workflow : comment copier un calque visuel lorsqu'il correspond à un emplacement de fichier spécifique ? La source de vérité est-elle le plan de travail ou un système de fichiers ? Le clonage d'un calque de code doit-il créer une instance de celui-ci (comme c'est la norme en matière de code) ou créer une version dédoublée, à l'image du fonctionnement traditionnel de la duplication dans Figma ?

Nous savions qu'il fallait que le code dans Figma soit familier pour les designers et les développeurs, ce qui signifiait que les utilisateurs devaient encore pouvoir manipuler librement les calques de code sur le plan de travail spatial. La solution a été de mettre en œuvre des calques de code en tant que nouvelle primitive de plan de travail. Les calques de code se comportent comme n'importe quel autre calque, avec une flexibilité spatiale totale (y compris le déplacement, le redimensionnement et la réaffectation) et une intégration transparente de la mise en page (par exemple, le placement dans des piles de mise en page automatique). Plus important encore, ils peuvent être dupliqués et réitérés facilement, imitant la nature libre et expérimentale du plan de travail. Cela permet de créer et de comparer différentes versions du code côte à côte. Généralement, créer deux copies de code à comparer nécessite de créer des branches git distinctes. Mais, avec les calques de code, c’est aussi simple que d'appuyer sur ⌥ et d'effectuer un glisser-déposer. Cela crée automatiquement un dérivé du code source pour une improvisation rapide.

Nous avons choisi de soutenir React car son modèle de composants s'aligne étroitement sur la notion de composants de Figma. Dans Figma, les composants sont des blocs de construction réutilisables et flexibles que les designers utilisent pour créer des interfaces. React fonctionne de la même manière : les développeurs combinent des composants React réutilisables pour créer des écrans et des applications. De plus, parce que les propriétés de React s'alignent directement sur la notion de propriétés de composants de Figma, nous les avons reliées. Vous pouvez définir des propriétés dans le code, puis les modifier visuellement à l'aide de contrôles personnalisables tels que des bascules, des curseurs et des menus déroulants.

Un IDE avec batteries sur le web

Bien que les calques de code puissent être créés et modifiés entièrement avec l'IA, nous savions que les utilisateurs souhaiteraient également modifier le code directement pour une flexibilité totale. Pour que cela soit transparent, nous avons intégré une expérience de modification de code moderne dans Figma, en commençant par notre choix de moteur principal de l'IDE : CodeMirror.

CodeMirror offre une base extensible pour l'édition de code web, et permet ainsi de définir des extensions pour des fonctionnalités telles que les thèmes de couleurs, la recherche et le remplacement et les numéros de ligne. Dans de nombreux cas, nous avons dû remplacer les comportements par défaut pour intégrer l'éditeur de code dans Figma ; par exemple, nous avons remplacé le comportement d'annulation/de rétablissement par défaut de CodeMirror par une mise en œuvre personnalisée basée sur notre propre pile d'annulation.

Nous avons reconnu très tôt que les performances pouvaient devenir un obstacle, surtout pour les bases de code larges. Les opérations de l'IDE telles que le regroupement et la vérification des types peuvent être lentes, et parce que JS ne possède qu'un fil, elles peuvent entraîner un blocage de l'UI lors du traitement de fichiers volumineux. Pour que l'environnement de code de Figma demeure rapide, nous exécutons la majeure partie de la chaîne d'outils de développement dans un Web Worker. À l'intérieur du worker, nous utilisons esbuild (créé par le co-fondateur de Figma, Evan Wallace) pour des temps de regroupement rapides, et Tailwind v4 avec Lightning CSS pour une compilation de style efficace. Ces outils sont partiellement écrits en code natif et compilés au format WebAssembly, offrant un gain de performances significatif.

Pour minimiser la complexité de la gestion des dépendances, nous installons automatiquement les packages importés depuis NPM ou une URL ESM. Inutile d'initialiser un package.json – il suffit d'importer les bibliothèques dont vous avez besoin et de commencer à créer dans un bac à sable sécurisé. La plupart des packages fonctionneront directement dans Figma, y compris les packages favoris de la communauté tels que Motion et React-Three-Fiber.

Rendre les calques de code collaboratifs

La collaboration multijoueurs est au cœur de Figma, permettant aux équipes de travailler efficacement ensemble pour concevoir et offrir de magnifiques expériences. Notre technologie multijoueurs prend en charge la synchronisation simultanée pour de nombreux champs de nœuds, tels que la position et la couleur. Mais elle n'avait jamais été utilisée dans un domaine aussi complexe que le code source, qui peut potentiellement consister en de milliers de lignes de texte.

Cette nouvelle exigence a présenté une opportunité de repenser notre approche. La solution la plus simple pour synchroniser les modifications réside dans la méthode du « last-write-wins », où les changements de chaque utilisateur écrasent ceux effectués par les autres utilisateurs. Cela fonctionne pour les textes courts, tels que des éléments de texte UX dans un design Figma, mais s'avère problématique lorsqu'il s'agit de modifier des fichiers de code source volumineux simultanément, surtout sur des connexions lentes. Nous avons également vu que ce problème s'aggravait lorsque les modèles d'IA effectuaient des modifications simultanées du code, créant ainsi des conflits supplémentaires.

Nous avons donc cherché de meilleures alternatives, en nous tournant vers des algorithmes classiques de modification collaborative de texte tels que les transformations opérationnelles (OT) et les types de données répliquées sans conflit (CRDT). Les OT transforment les opérations simultanées afin qu'elles puissent être appliquées sans conflits. Ils constituent la technologie de base pour de nombreux éditeurs de texte collaboratifs, tels que Google Docs. Cependant, ils ralentissent lors de la fusion de fichiers présentant de nombreux conflits, car toutes les modifications conflictuelles doivent être transformées les unes par rapport aux autres.

Inversement, la plupart des CRDT traitent chaque caractère comme une entité indépendante. Cela rend la fusion des modifications beaucoup plus facile, mais entraîne une surcharge de mémoire plus élevée. Pour traiter les mises à jour, l'historique complet du document doit être reconstruit en mémoire, même s'il n'y a pas de modifications simultanées (comme dans le cas d'utilisation le plus courant). Cela crée une surcharge de mémoire et réduit les performances.

Heureusement, un article publié l'année dernière a présenté Event Graph Walker (Eg-walker), un nouvel algorithme offrant la plupart des avantages des OT et des CRDT. Eg-walker représente les modifications sous forme de graphe d'événements causals acycliques dirigés. Son algorithme est analogue à un rebase git ; il réorganise plusieurs branches divergentes en un ordre linéaire. Pour fusionner des événements simultanés, Eg-walker construit temporairement une structure CRDT. Après avoir exécuté son algorithme de résolution, Eg-walker supprime le CRDT interne, libérant ainsi de la mémoire. Dans le chemin idéal de modifications séquentielles sans conflit, les mises à jour sont presque sans coûts. En conséquence, Eg-walker est aussi rapide que les CRDT en termes de fusion, mais présente une faible surcharge de mémoire, à l'instar des OT.

Compte tenu des avantages en termes de performance et de mémoire, nous avons utilisé l'algorithme Eg-walker afin de développer le service de collaboration multijoueurs pour les calques de code. Lorsqu'un utilisateur modifie un fichier de code, le client envoie une liste de modifications au serveur. Le serveur réconcilie les modifications simultanées de tous les clients actifs en utilisant Eg-walker, et renvoie une liste mise à jour des modifications, résolvant ainsi tout conflit. Avec cette architecture, le service multijoueurs gère le travail de fusion le plus coûteux en calcul pour tous les clients, ce qui permet des temps de chargement initiaux rapides et une expérience utilisateur performante même pour des systèmes de fichiers volumineux.

L'avenir du code et du design

Les calques de code ne sont que le début du code dans Figma. Nous prévoyons d'apporter un degré de manipulation directe encore plus important aux calques de code pour combler encore davantage le fossé entre les workflows de codage et de conception, et ainsi permettre aux utilisateurs de basculer sans effort entre les supports selon leurs besoins à tout moment.

Dans son discours « Inventing On Principle », le designer d'interface Bret Victor affirme que « les créateurs ont besoin d'une connexion immédiate à ce qu'ils créent… lorsque vous créez quelque chose, si vous effectuez une modification, ou prenez une décision, vous devez en voir l'effet immédiatement. » Alors que nous continuons à étendre les capacités du code dans Figma, nous sommes guidés par cette idée : plutôt que de cloisonner le design et le code dans des outils séparés, nous devrions tous être capables de créer ensemble dans un environnement partagé.

Les calques de code sont désormais en version bêta dans Figma Sites. Nous sommes impatients de voir ce que vous allez créer !

Nous recrutons des ingénieurs ! Découvrez les conditions de travail à Figma et consultez nos postes vacants.