Grist se positionne comme une alternative sérieuse dans la gestion de vos données, quelque part entre le tableur traditionnelle et la structure rigoureuse de base de données relationnelles. Mais sa véritable force réside dans son extensibilité grâce aux Custom Widgets. Avec ces extensions, vous pouvez dépasser les limites de l’interface native pour créer vos propres vues sur mesure, et même d’ajouter des fonctionnalités uniques, parfaitement adaptées à vos besoins. Pour créer ces extensions, la solution Custom Widget Builder est souvent utilisé, mais elle montre vite ses limites pour un développement web plus robustes.
Dans ce guide, nous allons voir comment déployer un environnement de développement local sous Windows (WSL2). L’objectif ? Retrouver le confort de vos IDE favoris (JetBrains, VS Code…), bénéficier du live-reload pour visualiser les changements dans votre code en temps réel, et travailler en toute sécurité dans un bac à sable, totalement isolé de votre instance de production.
Préambule
Motivations
Développement de custom widget avec la solution « Custom Widget Builder »
Pour concevoir un widget, l’outil Custom Widget Builder est souvent la porte d’entrée naturelle. Son interface avec onglets permet d’écrire et de tester son code directement dans le navigateur.
— Développer des widgets Grist avec la solution « Custom Widget Builder »
L’avantage majeur de ce builder est qu’il élimine totalement la contrainte de l’hébergement. Traditionnellement, un widget nécessite un serveur web externe pour être déployé. Ici, le code que vous saisissez (HTML, CSS et JavaScript) est stocké directement au sein du document Grist en tant que donnée de configuration.
Où le code HTML et JavaScript est-il stocké avec Custom Widget Builder ?
Techniquement, le builder ne traite pas votre code comme un fichier distant mais comme une simple option de configuration d’une vue. Lors de la sauvegarde, le builder utilise la méthode
grist.setOptions()pour enregistrer l’intégralité de votre code sous forme de chaîne de caractères (JSON) directement dans le document Grist.// https://github.com/gristlabs/grist-widget/blob/master/custom-widget-builder/api.js const options = { _js: jsModel.getValue(), _html: htmlModel.getValue(), }; (...) grist.setOptions(options);Pour comprendre les coulisses du stockage de ces options
_jset_htmlcontenant le code de votre widget, il faut se rappeler qu’un document Grist est avant tout une base de données SQLite. Celle-ci héberge vos données métiers, mais aussi des tables systèmes indispensables à Grist. Ainsi, le code saisi dans le Custom Widget Builder n’est pas sauvegardé dans un fichier externe, mais directement dans la table système _grist_Views_section, au sein de la colonne options.
– Custom Widget Builder, stockage du code dans la base de données SQLite du document Grist
Cette architecture rend votre widget totalement nomade. Puisque le code fait partie intégrante du document, il voyage avec lui. Si vous déplacez, télécharger ou partager votre fichier .grist, votre widget voyage dans ce dernier et reste opérationnel et prêt à l’emploi dès l’ouverture, sans aucune configuration supplémentaire.
Limites du développement avec « Custom Widget Builder »
Bien que cette approche soit extrêmement pratique pour expérimenter et déployer très rapidement son code sans aucune configuration complexe, elle atteint rapidement ses limites dans le développement web.
-
L’absence de contrôle de version : Le code est stocké dans le document Grist, empêchant l’utilisation d’un dépôt Git spécifique pour suivre l’historique du code ou collaborer sereinement (pull-request/fork).
-
Une gestion des dépendances précaire : Vous êtes limité à l’import de bibliothèques JavaScript via CDN. Cela rend le projet dépendant de ressources externes, moins stable, et plus complexe à maintenir sur le long terme.
-
Un écosystème bridé : L’interface ne permet pas de profiter pleinement des outils modernes de développement web (TypeScript, frameworks, build-tools, préprocesseurs CSS …).
-
Un cycle de développement laborieux : Développer à l’extérieur dans un IDE, puis intégrer manuellement chaque modification dans la vue d’un Custom Widget Builder devient vite fastidieux. La boucle itérative (modification, rechargement, test) est lente, et source d’erreurs.
Disposer d’un environnement de développement local de widget Grist
Pour gagner en DX (Developer Experience), amélioration du confort et de l’efficacité d’un développeur, il est préférable de mettre en place un environnement de développement local spécifique. L’enjeu est de retrouver le confort des outils de développement modernes dans un IDE, tout en gardant un pied dans Grist.
-
Servir les fichiers du widget dans un serveur web local.
-
Automatiser le rafraîchissement (live reload) pour visualiser chaque changement de code du widget instantanément dans le navigateur.
-
Tester en condition réelles dans une instance Grist locale, sans risquer de corrompre vos données ou d’impacter l’instance de production.
C’est précisément ce que propose le projet gristlabs/grist-widget.
Dans ce guide, nous allons détailler la mise en place d’un environnement de développement local sous Windows (avec WSL2) pour concevoir et tester vos propres custom widget depuis un IDE moderne (Jetbrains, Visual Studio Code …). Codez dans votre IDE, et visualisez les changements instantanément de vore widet à chaque sauvegarde, grâce au « live reload ».
— Développer des widgets Grist avec le live reload
Déploiement du projet gristlabs/grist-widget comme environnement de développement local
La manière la plus simple d’utiliser l’ensemble des outils de développement du projet gristlabs/grist-widget est de travailler dans un environnement Linux. Toutefois, dans ce guide, nous resterons sous Windows en nous appuyant sur WSL version 2.
Guide de déploiement express
- Installer Docker Desktop et Git-for-Windows
- Installer Ubuntu dans WSL2
> wsl --install > wsl --install -d Ubuntu - Installer Node.js et Yarn avec NVM dans l’instance Ubuntu WSL
# Entrer dans l'instance Ubuntu > wsl -d Ubuntu $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash $ nvm install 20.20 $ nvm use 20.20 $ npm install -g yarn - Cloner le projet gristlabs/grist-widget et installer ses dépendances.
Attention , le projet ne doit pas doit être cloner dans le montage mnt/c/de l’instance Ubuntu WSL !$ sudo mkdir /projects && sudo chown v20100v:v20100v /projects $ cd /projects && git clone https://github.com/gristlabs/grist-widget.git $ cd grist-widget && git submodule update --init --recursive $ yarn install - Modifier la configuration réseau du serveur de développement dans le fichier
./buildtools/dev-server.jspour une écoute broadcast (remplacezlocalhostpar0.0.0.0à la fin).}).listen(WIDGETS_PORT, '0.0.0.0', () => { (...) }); - Lancer l’environnement de développement avec l’IP de l’instance Ubuntu (
hostname -I) via la commandegrist:dev. Elle permet de lancer simultanément le serveur de widgets (port 8585) et une version légère de Grist (port 8484).$ export IP_WSL=$(hostname -I | awk '{print $1}') $ GRIST_WIDGET_LIST_URL=http://$IP_WSL:8585/manifest.json yarn run grist:dev - Vous pouvez accéder et travailler avec l’instance locale de Grist, en ouvrant la page http://localhost:8484, et consulter le manifest à http://localhost:8585/manifest.json.
Guide de déploiement détaillé (TL;DR)
Installation de Docker
L’environnement de développement gristlabs/grist-widget utilise une instance locale de Grist encapsulée dans un conteneur Docker basé sur l’image gristlabs/grist. Sous Windows, la méthode la plus simple est d’utiliser la solution officielle Docker Desktop. Consulter ce guide Windows | Docker Docs pour l’isntaller.
Une fois Docker Desktop lancé, l’environnement est prêt et vous pouvez commencer à créer, gérer et exécuter vos conteneurs directement depuis Windows. Pour vérifier que votre installation est parfaitement opérationnelle, le moyen le plus simple est de lancer l’image de test hello-world fournie par Docker.
Ouvrez un terminal et entrez :
> docker --version
Docker version 28.4.0, build d8eb465
> docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4f55086f7dd0: Pull complete
Digest: sha256:452a468a4bf985040037cb6d5392410206e47db9bf5b7278d281f94d1c2d0931
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
(...)
Vérifier l’activation de WSL (Windows Subsystem for Linux)
Bien que les outils de développement du projet gristlabs/grist-widget soient nativement conçus pour Linux, vous pouvez parfaitement travailler sous Windows grâce au service WSL 2 (Windows Subsystem for Linux). WSL est une couche de compatibilité qui permet d’exécuter un noyau Linux directement au sein de Windows.
Le sous-système Windows pour Linux (WSL) est une collection de composants Microsoft conçus pour permettre aux binaires Linux 64 bits natifs au format exécutable et lisible (ELF64) de fonctionner au sein du système d’exploitation (OS) Windows 10 ou Windows 11. Il s’agit d’une fonctionnalité intégrée à Windows qui permet d’exécuter un environnement GNU/Linux complet directement, sans aucune machine virtuelle lourde ni système de double‑boot.
Bien que les instances Linux puissent fonctionner sous Windows à l’intérieur d’une VM, WSL présente des avantages.
- Il demande moins de ressources informatiques (processeur, mémoire et stockage) qu’une VM complète.
- Il permet aux environnements Windows et Linux de fonctionner simultanément, ce qui permet aux développeurs d’utiliser des applications Windows et des utilitaires Linux sur les mêmes fichiers
- Il permet aux applications Linux GUI de fonctionner de manière native sous Windows.
Cependant WSL présente toutefois certaines limites, car il ne s’agit pas d’un environnement Linux à part entière.
- Il s’agit d’une couche de compatibilité qui vous permet d’exécuter des binaires Linux sur Windows. Ce n’est pas une réelle distribution Linux. Cela signifie que toutes les fonctionnalités de Linux ne sont pas disponibles dans WSL. Par exemple, WSL ne prend pas en charge certains systèmes de fichiers Linux, tels que ext4.
- Toutes les distributions Linux ne sont donc pas disponibles dans WSL.
- WSL n’est pas aussi rapide qu’une installation Linux native. En tant que couche de virtualisation, WSL doit traduire les appels système Linux en appels système Windows. Ce processus de traduction ajoute des coûts supplémentaires, ce qui ralentir les performances.
Pour installer ou mettre à jour WSL vers la version la plus récente, ouvrez un terminal en mode administrateur et exécutez les commande suivantes :
# Installer WSL
> wsl --install
# Vérifier l’état de WSL
> wsl --status
Distribution par défaut: docker-desktop
Version par défaut: 2
# Contrôler détaillé de la version active
> wsl --version
Version WSL : 2.6.1.0
Version du noyau : 6.6.87.2-1
Version WSLg : 1.0.66
Version MSRDC : 1.2.6353
Version direct3D : 1.611.1-81528511
Version de DXCore : 10.0.26100.1-240331-1435.ge-release
Version de Windows : 10.0.26100.7623
# Mettre à jour WSL
> wsl --update
# Lister les distributions Linux disponibles
> wsl --list
Distributions du Sous-système Windows pour Linux :
docker-desktop (par défaut)
Installation de la distribution Ubuntu dans WSL
Pour installer la distribution Ubuntu dans votre environnement WSL, exécutez la commande suivante dans un terminal en tant qu’administrateur.
# Installer Ubuntu et créer un user unix
> wsl --install -d Ubuntu
Téléchargement : Ubuntu
Installation : Ubuntu
La distribution a été installée.
Elle peut être lancée via 'wsl.exe -d Ubuntu'
Lancement : Ubuntu...
Provisioning the new WSL instance Ubuntu
This might take a while...
Create a default Unix user account: v20100v
New password:
Retype new password:
passwd: password updated successfully
To run a command as administrator (user "root"), use "sudo ".
# Pour définir la distribution Linux par défaut
> wsl --set-default Ubuntu
Une fois Ubuntu installée, vous pouvez la démarrer directement depuis un terminal Windows avec la commande wsl -d Ubuntu. Si Ubuntu est définie comme distribution par défaut, il suffit d’exécuter wsl pour la démarrer.
Vous pouvez alors accéder à vos fichiers Linux Ubuntu de deux manières :
-
depuis votre terminal Windows.
-
ou depuis l’explorateur Windows.
— Accès au fichiers Linux Ubuntu (WSL2) via l’explorateur Windows
Installation de Node.js et Yarn dans l’instance Ubuntu WSL
Pour gérer efficacement les différentes versions de Node.js dans un environnement, il est recommandé d’utiliser l’outil NVM (Node Version Manager). Cela permet de changer de version de Node en une commande sans polluer le système d’exploitation.
-
Installer NVM. Entrer dans votre distribution Ubuntu WSL2, pour y installer globalement NVM avec la commande suivante.
> wsl -d Ubuntu > v20100v@PCNAME:/mnt/c/Users/v20100v$ # Télécharger et installer NVM via appel curl sh > v20100v@PCNAME:/mnt/c/Users/v20100v$curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash -
Charger NVM dans votre instance Ubuntu WSL2, en ajoutant les lignes suivantes à votre fichier
~/.bashrcsi elles n’y figurent pas déjà. Pensez à recharger ensuite votre configuration avec ($source ~/.bashrc) ou en redémarrant votre session WSL.export NVM_DIR="$HOME/.nvm"\ [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"Vérifier que NVM est bien accessible.
v20100v@PCNAME:/$ nvm --version 0.39.5 -
Installer et activer Node.js version 20.20 avec NVM.
$ nvm install 20.20 Downloading and installing node v20.20.0... Downloading https://nodejs.org/dist/v20.20.0/node-v20.20.0-linux-x64.tar.xz... ####################################################################### 100.0% Computing checksum with sha256sum Checksums matched! $ nvm use 20.20 Now using node v20.20.0 (npm v10.8.2) -
Installer Yarn globalement. Pour installer les dépendances du projet gristlabs/grist-widget visibles dans le fichier package.json, vous aurez également besoin de Yarn, un gestionnaire de dépendances dans l’écosystème Node.js. On l’installe avec npm, le gestionnaire par défaut dans Node.js.
$ npm install -g yarn $ yarn -v 1.22.22
Clonage du dépôt gristlabs/grist-widget
Pour cloner (récupérer) le code du projet dans l’instance Ubuntu WSL2, on utilise l’outil git. Si ce dernier n’est pas présent vous pouvez l’installer avec la commande sudo apt install git -y.
-
Créer un répertoire de travail dans lequel sera cloner le projet.
# Entrer dans l'instance Ubuntu WSL2 > wsl -d Ubuntu > v20100v@PCNAME:/mnt/c/Users/v20100v$ # Créer un répertoire de travail à la racine $ cd / $ sudo mkdir projects # Changer le propriétaire $ sudo chown v20100v:v20100v /projects Attention , il est très important de créer le répertoire du projet à l’intérieur de l’instance WSL. Il ne faut surtout pas utiliser le point de montage mnt/c/. Ce dernier utilise le système de fichier Windows via une couche de traduction (drvfs) provoquant :- des lenteurs d’accès au disque très importante,
- des problèmes dans la gestion des permissions POSIX rendant certains scripts inexécutables (le chmod +x est ignoré), alors que dans le système de fichier natif de WSL (ext4) cela fonctionne normalement,
- et enfin les watchers ne détectent plus les changements. Par exemple, la compilation d’un fichier typescript avec tsc, ou d’asset css ne se lance plus malgré le changement de fichier.
-
Cloner le projet
gristlabs/grist-widget.# Cloner le projet dans le répertoire projects $ cd projects $ git clone https://github.com/gristlabs/grist-widget.git $ cd grist-widget -
Cloner les sous-module git du projet. Ce dépôt git utilise des sous-modules (a.k.a. submodules), qui ne sont pas récupérer lors du clonage. Vous pouvez par exemple constater que le répertoire
./varamil/est vide. C’est justement un des sous-module du projet. Pour récupérer tous les sous-modules et leurs dépendances, exécuter la commande :$ git submodule update --init --recursive Vous avez dit git submodule ?Un submodule est un dépôt Git imbriqué à l’intérieur d’un autre dépôt git. Il permet d’inclure un projet externe tout en gardant son historique séparé. Chaque submodule pointe sur un autre dépôt git.
Vous pouvez consulter le fichier
./.gitmodulessitué à la racine du projet pour voir la liste complète des sous‑modules utilisés. Ce fichier indique pour chacun d’eux son chemin local, son dépôt d’origine et, le cas échéant, la branche suivie.
Installation des dépendances Node.js
Une fois le dépôt cloné et les sous-modules récupérés, vous devez installer les bibliothèques JavaScript nécessaires au fonctionnement du projet à l’aide de Yarn. Pour fonctionner, Yarn s’appuie sur le fichier package.json. Il y puise la liste des bibliothèques nécessaires au projet pour les télécharger et les organiser.
> wsl -d Ubuntu
$ cd projects/grist-core
$ yarn install
Une fois l’exécution terminée, un dossier ./node_modules/ sera généré à la racine de votre projet. Ce répertoire centralise l’ensemble des dépendances JavaScript requises pour du projet, tel que décrit dans le fichier yarn.lock.
package.jsonetyarn.lock?Le
package.jsonfait office de fiche d’identité et de manifeste d’un projet. Il liste les dépendances directes dont le projet a besoin en précisant une plage de versions autorisées (ex:^1.2.0).Alors que le fichier
yarn.lockest un instantané précis généré automatiquement par Yarn. Il indique ce que Yarn va (ou a) précisément installé. Il verrouille spécifiquement les versions exactes de chaque dépendance et de leurs propres sous-dépendances. Cette rigueur garantit le déterminisme du projet en s’assurant que les développeurs disposeront toujours d’un dossiernode_modulesstrictement identique.
Configuration réseau du serveur de développement grist-widget
Le projet gristlabs/grist-widget lance simultanément un serveur de widgets (port 8585) et une version légère de Grist (port 8484) dans un conteneur Docker. Dans une installation standard sous Linux natif, ces services communiquent simplement via localhost. Cependant, l’utilisation de WSL2 introduit une complexité réseau spécifique qu’il convient de résoudre pour assurer la communication entre ces services.
Le problème
Par défaut, WSL2 utilise son propre réseau virtuel.
Cette architecture crée une isolation réseau entre Linux et Windows. Le localhost de l’instance WSL reste confiné à l’intérieur de la machine virtuelle Linux. Vous pouvez observer cette distinction en comparant les adresses IP de ces deux environnements.
# Identifier l'@ IP de la machine hôte Windows
> ipconfig
Adresse IPv4: 172.30.240.1
# Identifier l'@ IP de l'instance Ubuntu WSL2
> wsl -d Ubuntu
$ hostname -I
172.30.253.221
En conséquence, un service lancé sur WSL ne sera pas accessible par le navigateur Windows ou par d’autres conteneurs Docker sans une configuration réseau spécifique. Autrement dit, puisque le serveur de développement de grist-widget écoute uniquement sur 127.0.0.1, il sera inacessible au conteneur Docker de Grist, ainsi que pour votre navigateur dans la machine hôte Windows, entraînant des erreurs de type ECONNREFUSED.
La solution broadcast
Pour permettre la communication entre ses services (service de widget 8585, instance, service Grist 8484 dans un conteneur Docker), vous devez forcer le serveur de développement à accepter les connexions provenant de l’extérieur de la boucle locale en utilisant l’adresse broadcast 0.0.0.0.
Pour ce faire, modifier la configuration du serveur de développement dans le fichier ./buildtools/dev-server.js en remplaçant localhost par 0.0.0.0 dans la méthode listen().
// Remplacer les dernières lignes du fichier ./buildtools/dev-server.js
}).listen(WIDGETS_PORT, '0.0.0.0', () => {
console.log(`Server running on: http://0.0.0.0:${WIDGETS_PORT}`);
});
Lancer l’environnement de développement grist-widget
La commande yarn run grist:dev initialise simultanément deux services : le serveur de widgets (port 8585) et une version légère de Grist embarqué dans un conteneur Docker (port 8484).
Pour que Grist puisse localiser le manifeste des widgets, vous devez impérativement définir la variable d’environnement GRIST_WIDGET_LIST_URL avec l’adresse IP de l’instance Ubuntu WSL2.
# Identifier l'@ IP de l'instance Ubuntu WSL2
> wsl -d Ubuntu
$ hostname -I
172.30.253.221
Exécutez la commande suivante (en remplaçant l’IP par la vôtre).
# Remplacez l'IP par la vôtre
GRIST_WIDGET_LIST_URL=http://172.30.253.221:8585/manifest.json
yarn run grist:dev
(...)
Starting local server and watching for changes.
> @gristlabs/grist-widget@0.0.5 serve:dev
> env PORT=8585 node ./buildtools/dev-server.js
Server running on: http://localhost:8585
(...)
Welcome to Grist.
In quiet mode, see http://localhost:8484 to use.
For full logs, re-run with DEBUG=1
2026-03-27 16:15:14.995 - info: Setting up database...
2026-03-27 16:15:15.042 - info: Database setup complete.
2026-03-27 16:15:15.043 - info: == Grist version is 1.7.11 (commit unknown)
Vous pouvez vérifier dans Docker que l’image gristlabs/grist a bien été récupérée.
— Récupération de l’image Docker gristlabs/grist
Here we go… L’environnement de développement est (normalement) démarré !
Contrôler le bon démarrage de l’environnement de développement
-
Vérifier que le serveur de widget est bien accessible sur le port 8585, en consultant dans un navigateur de la machine hôte, la page http://localhost:8585/manifest.json. Ce référentiel sert à déclarer chaque widget à charger dans une instance Grist.
-
Accéder à l’instance locale Grist, en ouvrant la page http://localhost:8484
-
Créer un nouveau document vide pour ajouter une nouvelle vue « Personnalisée ». Vous pouvez constater que les widget déclarés dans le
manifest.jsonsont bien accessible dans l’instance locale Grist !
EADDRINUSE), il est possible qu’un processus occupe déjà le port 8585. Voici comment l’identifier et forcer son arrêt.# Identifier le processus (PID) sur le port 8585 $ sudo lsof -i :8585 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 85588 v20100v 18u IPv4 811284 0t0 TCP *:8585 (LISTEN) # Tuer le processus $ sudo kill -9 85588
Conception d’un nouveau widget
Maintenant que l’environnement de développement local est opérationnel, passons à la création d’un nouveau widget, nommé « Startiflette ».
-
Initialiser le répertoire du widget.
Créez un nouveau répertoire dans Ubuntu dédié à votre widget à la racine du projet.> wsl -d Ubuntu $ cd /projects/grist-widget $ mkdir startiflette -
Décrire le widget dans le fichier
package.json.
Chaque widget doit être référencé et décrit par ce fichier. Il permet au serveur de l’inclure automatiquement dans le catalogue des vues « personnalisées ».Créez le fichier
./startiflette/package.jsonavec le contenu suivant.{ "name": "@badi/widget-startiflette", "description": "Dumb widget for poc.", "homePage": "https://github.com/gristlabs/grist-widget", "version": "0.0.1", "grist": { "name": "Startiflette", "url": "https://gristlabs.github.io/grist-widget/startiflette/index.html", "widgetId": "@badi/widget-startiflette", "published": true, "accessLevel": "none", "renderAfterReady": true, "description": "In tartiflette we trust", "authors": [ { "name": "Vincent BLAIN", "url": "https://github.com/v20100v" } ], "isGristLabsMaintained": true } }Une fois ce fichier enregistré, vérifiez sa prise en compte en consultant le manifeste local http://localhost:8585/manifest.json. Votre widget doit y apparaître.
-
Ouvrir le projet dans IDE via Remote Development
Pour ouvrir votre projet situé dans WSL avec un IDE Jetbrain, évitez absolument d’ouvrir votre projet via l’explorateur Windows, sous peine d’avoir une indexation extrêmement lente. Utilisez plutôt la fonction Remote Development. Dans ce cas, l’IDE gérera parfaitement les permissions de fichiers et les outils (Node.js, Git) installés à l’intérieur d’Ubuntu sans conflit avec Windows. -
Dévélopper votre widget (application web)
Créez le fichier./startiflette/index.htmlavec le code du widget, puis ajoutez l’image de votre choix.<html> <head> <title>Smoke widget GRIST</title> </head> <body> <h1>In startiflette we trust !</h1> <img src="r2d2.jpg" height="400"/> </body> </html> -
Rendu dans l’instance Grist locale
Dans l’instance http://localhost:8585, vous pouvez maintenant ajouter votre nouveau widget « Startiflette ».Et voila le rendu ! Si le code du widget est modifié, le navigateur se rafraîchit instantanément pour refléter les changements.
Conclusion
Mettre en place cet environnement de développement local pour vos custom widgets dans Grist transforme radicalement l’expérience de développement. En s’affranchissant des limites du Custom Widget Builder, vous gagnez non seulement en confort grâce au live reload, mais vous ouvrez surtout la porte à des pratiques d’ingénierie logicielle bien plus robuste.
Cette démarche ouvre la voie à l’utilisation de frameworks modernes (React, Angular, Vue.js …), et à l’emploi d’un code typé et sécurisé avec TypeScript. Elle permet aussi d’adopter des cycles de développement matures où la gestion de versions avec Git devient le pilier de la collaboration entre développeurs. Grâce aux pull requests, chaque modification est soumise à une revue de code rigoureuse avant son intégration. Il est même possible d’envisager d’y associer des tests automatisés et des plans de déploiement continue (CI/CD) de vos widgets!
Que vous souhaitiez créer une visualisation de données complexe ou une interface métier interactive, cet environnement est un tremplin pour transformer vos idées en application robuste, maintenable et évolutive.
Happy coding ^^.
Sources & lectures complémentaires :
Vite.js & HMR : Un rechargement HMR (hot module reload) qui préserve l’état de votre widget pendant la phase de dev (à la différence du livereload)
TypeScript : Pour un typage robuste de l’API Grist.
Docker-Ready : Lance une instance Grist locale pré-configurée pour tester vos widgets en conditions réelles.
Stratégies de Build : Support de deux stratégies de build : SPA (single page application) en un unique fichier HTML ou Standard (avec cache busting des assets)
Manifeste Automatisé : Le fichier 
Démarrage rapide :
Liens utiles :