Directives générales pour le développement de widgets

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 5 minutes de lecture

    • Lors du développement de widgets personnalisés, gardez ces directives générales à l’esprit pour des performances optimales, un développement évolutif et une bonne expérience utilisateur.

    Créer un état par défaut qui fournit un exemple à l’utilisateur final

    Un widget n’a pas d’options d’instance définies lorsqu’il est initialement ajouté à une page. Un widget dans cet état vide peut apparaître vide et prêter à confusion. Dans les situations où un widget nécessite une configuration initiale, assurez-vous que votre widget a un état par défaut qui communique à l’administrateur quelle configuration est nécessaire.

    Les widgets peuvent également être créés avec des données de démonstration. Les données de démonstration peuvent également être utilisées pour :

    • Démontrez clairement la fonctionnalité du widget à l’utilisateur.
    • Fournissez des données lors de l’aperçu du widget dans l’éditeur de widget. (Les données de démonstration ne sont pas visibles dans le concepteur).

    Pour en savoir plus : Didacticiel : Créer un widget personnalisé.

    Incorporer un widget plutôt que de cloner lorsque cela est possible

    L’intégration d’un widget existant dans votre widget personnalisé tire parti des fonctionnalités préexistantes sans cloner ni dupliquer le code. Vous pouvez toujours transmettre des paramètres dans le widget incorporé pour contrôler son comportement.

    Pour en savoir plus : Incorporer un widget existant

    Évitez d’utiliser des ensembles de données volumineux pour améliorer les performances

    L’interrogation des données, l’évaluation des ACL, l’exécution de règles métier et le traitement des données prennent du temps et peuvent ralentir les performances. Déterminez la quantité de données dont les utilisateurs du portail ont besoin, puis appliquez les limites et les filtres appropriés à vos scripts et requêtes. Isolez les widgets qui nécessitent des données ou un traitement importants dans leurs propres pages distinctes dans le portail. Évitez d’implémenter les éléments suivants qui utilisent des ensembles de données volumineux :

    • Éléments de menu scriptés qui chargent de grandes quantités de données, ce qui peut entraîner un chargement lent de chaque page du portail.
    • Fichiers et pièces jointes volumineux, tels que des fichiers multimédias haute définition ou des polices de caractères de la table Pièces jointes [sys_attachment].
    • Actualisation automatique des widgets. Chaque fois que le contrôleur client d’un widget appelle server.update(), spUtil.update(), server.refresh() ou spUtil.refresh(), l’application exécute le script serveur du widget et renvoie un objet de données au client.
    • Observateurs d’enregistrements non filtrés. La fonction recordWatch() surveille les mises à jour d’une table ou d’un filtre et renvoie la valeur de la fonction de rappel. L’ajout de filtres pour des champs spécifiques à surveiller réduit le nombre d’appels qu’un widget effectue vers le serveur. Spécifier quand actualiser les widgets en réponse à un créateur d’enregistrement informant le client qu’une mise à jour de la fonction de rappel est en cours peut également améliorer les performances.
    • Scripts côté serveur avec des requêtes GlideRecord sans la fonction setLimit . L’utilisation de la fonction setLimit peut limiter le nombre d’enregistrements renvoyés et améliorer le délai de réponse sur les requêtes. Pour plus de flexibilité, vous pouvez lier cette limite à une option d’instance plutôt que d’attribuer une valeur codée en dur (par exemple : gr.setLimit(options.limit || 100)).
    Pour en savoir plus:
    Créer une directive au lieu d’intégrer un widget complexe

    Lorsqu’un widget incorporé est appelé à partir du serveur, tous les scripts associés à ce widget sont renvoyés. Si vous n’avez besoin que d’une sous-section d’un widget, l’intégration de l’intégralité du widget crée des frais généraux inutiles. Utilisez plutôt des directives pour partager du code léger entre les widgets. Les directives sont utiles, par exemple, lors de la création de composants d’interface utilisateur. Il est préférable de laisser les composants complexes avec des fonctionnalités côté serveur et côté client sous forme de widgets. Utilisez une directive au lieu d’un widget incorporé pour :

    • Partagez le comportement du champ d’application ou du champ d’application personnalisé avec plusieurs widgets.
    • Partagez une sous-section légère et réutilisable d’un widget.
    • Partagez une fonctionnalité d’interface utilisateur commune, telle qu’une liste ou un avatar.
    • Augmentez le comportement des widgets.

    Pour en savoir plus : Réutiliser les composants avec des fournisseurs d’angle.

    Utiliser un service ou une usine pour partager des données et conserver l’état

    Les services de données et les instanciateurs conservent et conservent l’état d’un widget sans nécessiter plusieurs appels au serveur, ce qui vous permet d’effectuer les opérations suivantes :

    • Synchronisez les widgets lors de la modification des enregistrements ou des filtres.
    • Partager des données entre les widgets.
    • Développez des widgets plus performants.

    Pour en savoir plus : Réutiliser les composants avec des fournisseurs d’angle.

    Gérer les événements avec un service de publication/d’abonnement

    Évitez d’utiliser $broadcast dans les DOM. $broadcast distribue le nom de l’événement à tous les champs d’application enfants en notifiant les auditeurs enregistrés, ce qui peut être un appel coûteux nécessitant l’utilisation de l’objet global $rootScope .

    Utilisez plutôt un service de publication/abonnement pour gérer les événements. Lors de l’utilisation d’un service de publication/abonnement, une relation claire se forme entre vos widgets via des gestionnaires de rappel. Dans ce modèle, vous pouvez mieux contrôler l’état de vos événements.

    Utilisez les appels REST ou server.get pour extraire les données du serveur

    Lorsque vous appelez server.update(), l’intégralité du widget est renvoyée par le serveur. Si votre widget inclut des chemins de code divergents, plusieurs appels à mettre à jour le serveur peuvent affecter les performances. En règle générale, utilisez votre script serveur pour configurer l’état initial de votre widget. Pour les mises à jour ultérieures, utilisez des API REST scriptées qui appellent des includes de script sur votre instance. Cette pratique :

    • Sépare la logique métier des éléments d’interface utilisateur.
    • Centralise votre code, ce qui permet d’apporter des modifications en un seul endroit.
    Vous pouvez également utiliser server.get pour transmettre des informations au serveur. Utilisez cette fonction avec input.action pour exécuter des parties spécifiques du script serveur.
    Développez en tenant compte de la localisation, de l’accessibilité et de l’interface utilisateur

    Pour créer la meilleure expérience pour vos utilisateurs, suivez ces directives :

    • Tenez compte de l’impact de votre widget dans un environnement mobile. Par exemple, évitez d’utiliser le pointage de la souris et d’autres événements qui ne se traduisent pas sur un appareil mobile.
    • Utilisez des variables SCSS pour réutiliser des éléments. Voir Variables SCSS.
    • Utilisez des noms de variables lors de l’utilisation des couleurs.
    • Encapsulez les chaînes à traduire dans les API de localisation. Voir Internationaliser un widget.
    Supprimer les fournisseurs d’angle inutilisés du script client
    Pour faciliter la maintenance, supprimez tous les fournisseurs Angular inutilisés qui ont été injectés dans l’instruction de fonction de script client.
    Éviter d’utiliser <script> tags in HTML templates
    Réduire la probabilité de problèmes de production dans Portail de services, évitez d’utiliser des modèles en ligne à l’aide de <script> tags in a widget's HTML template. Instead, create a related Angular ng-template record for the widget.