Améliorez l'expérience globale de vos utilisateurs en suivant ces guides de conception de modules complémentaires.
Bonnes pratiques générales
Nous vous encourageons à suivre les bonnes pratiques suivantes pour tous les modules complémentaires que vous développez.
Déterminez la propriété du module complémentaire avant de commencer
Les modules complémentaires sont définis par des projets Apps Script, qui doivent appartenir à un compte spécifique ou être placés dans un Drive partagé. Avant de coder un module complémentaire, déterminez quel compte doit être propriétaire du projet et quel compte agit en tant qu'éditeur. Déterminez également les comptes qui agiront en tant que collaborateurs, et assurez-vous que ces comptes ont accès au projet de script et au projet Cloud Platform associé.
Étendre les fonctionnalités de Google Workspace, sans les dupliquer
Ils sont destinés à fournir de nouvelles fonctionnalités aux applications Google Workspace qu'ils étendent ou à automatiser des tâches complexes. Ceux qui se contentent de répliquer les fonctionnalités déjà présentes dans l'application ou ceux qui n'apportent pas d'améliorations significatives à un workflow ne seront probablement pas soumis à l'examen complémentaire pour la publication.
Limiter les champs d'application
Lorsque vous définissez vos champs d'application explicitement, choisissez toujours l'ensemble de champs d'application le moins permissif possible. Par exemple, n'accordez pas à votre demande de module complémentaire un accès complet à l'agenda de l'utilisateur avec le champ d'application https://www.googleapis.com/auth/calendar s'il n'a besoin que d'un accès en lecture. Pour l'accès en lecture seule, utilisez le champ d'application https://www.googleapis.com/auth/calendar.readonly.
Éviter de trop vous appuyer sur les bibliothèques
Si vous utilisez des bibliothèques Apps Script, votre module complémentaire risque de s'exécuter plus lentement que si tout le code Apps Script était contenu dans un seul projet de script. Bien que les bibliothèques Apps Script fonctionnent dans des modules complémentaires, vous risquez de réduire les performances si vous les utilisez. Évitez d'inclure des bibliothèques inutiles dans votre projet et réfléchissez à des moyens de réduire la dépendance de votre module complémentaire à celles-ci.
La latence décrite ci-dessus ne s'applique qu'aux projets Apps Script utilisés en tant que bibliothèques côté serveur. Vous pouvez utiliser librement les bibliothèques JavaScript côté client telles que jQuery, sans vous soucier de cette latence.
Bonnes pratiques concernant les modules complémentaires d'éditeur
Les bonnes pratiques suivantes ne s'appliquent qu'au module complémentaire Editor}.
Placer le code HTML de l'interface et le code JavaScript côté client dans leurs propres fichiers de script
Vous pouvez créer plusieurs fichiers de script dans un projet Apps Script. Il est plus facile de gérer un module complémentaire complexe si vous placez le code HTML et JavaScript qui définit les barres latérales et les boîtes de dialogue correspondantes dans des fichiers de script qui leur sont dédiés.
Effectuer des tests complets dans différents modes d'autorisation
Lorsque vous testez votre module complémentaire, veillez à essayer des configurations comportant différents fichiers et différents états d'autorisation.