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éterminer qui est le propriétaire du module complémentaire avant de commencer
Les modules complémentaires sont définis par des projets Apps Script, qui doivent être la propriété d'un compte spécifique ou placés dans un drive partagé. Avant de coder un module complémentaire, déterminez le compte qui doit en être le propriétaire et celui qui en est l'éditeur. Déterminez également les comptes qui doivent jouer le rôle de collaborateurs et assurez-vous qu'ils ont accès au projet de script et au projet de plate-forme Cloud associé.
Étendre Google Workspace, pas le dupliquer
Les modules complémentaires sont destinés à fournir de nouvelles fonctionnalités aux applications Google Workspace qu'ils étendent ou à automatiser des tâches complexes. Les modules complémentaires qui ne font que reproduire des fonctionnalités déjà présentes dans l'application ou qui n'apportent pas d'améliorations significatives à un workflow ne sont pas susceptibles de passer l'examen des modules complémentaires pour la publication.
Limitez 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, ne demandez pas à votre module complémentaire d'accéder entièrement à 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 un accès en lecture seule, utilisez le champ d'application https://www.googleapis.com/auth/calendar.readonly
.
Éviter de trop dépendre des bibliothèques
L'utilisation de bibliothèques Apps Script peut entraîner l'exécution plus lente de votre module complémentaire que si tout le code Apps Script était contenu dans un seul projet de script. Bien que les bibliothèques Apps Script fonctionnent dans les modules complémentaires, vous risquez de constater une baisse des performances si vous les utilisez. Évitez d'inclure des bibliothèques inutiles dans votre projet et envisagez de réduire la dépendance de votre module complémentaire à ces bibliothèques.
La latence décrite ci-dessus ne s'applique qu'aux projets Apps Script utilisés comme bibliothèques côté serveur. Vous pouvez utiliser librement des bibliothèques JavaScript côté client comme jQuery sans rencontrer cette latence.
Bonnes pratiques concernant les modules complémentaires de l'éditeur
Les bonnes pratiques suivantes ne s'appliquent qu'au module complémentaire Editor.
Placer l'interface HTML 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 du module complémentaire dans des fichiers de script qui leur sont dédiés.
Effectuez des tests approfondis dans différents modes d'autorisation.
Lorsque vous testez votre module complémentaire, veillez à essayer des configurations avec des fichiers et des états d'autorisation différents.