---
sourceDocument: Interface utilisateur de la Now Platform Xanadu
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/xanadu/platform-user-interface

 Release :

    - xanadu

ft:locale :

    - fr-FR

ft:publication_title :

    - Interface utilisateur de la Now Platform Xanadu

ft:clusterId :

    - platux

bundleId :

    - platux

workflow :

    - Platform


---

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

# Directives générales pour le développement de widgets {#ariaid-title1}

* Rversion finale: Xanadu
* 
* Mis à jour 1 août 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes de lecture

Lors du développement de widgets personnalisés, gardez à l'esprit ces directives générales 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 provoquer une confusion. Si un widget nécessite une configuration initiale, assurez-vous que votre widget a un état par défaut qui indique à 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).
    {#general-guidelines-developing-widgets__ul_r3c_nsh_l1c}

    Pour en savoir plus : [Didacticiel : Créer un widget personnalisé](https://servicenow-prod.fluidtopics.net/cNDCoduY0Gs9dnIcSOUb_Q#adv-widget-tutorial "Suivez ce didacticiel pour créer un widget personnalisé qui affiche Catalogue de services des éléments. Utilisez ce didacticiel comme modèle pour vous aider à comprendre la puissance de scripting avancée du Portail de servicesfichier .").

Intégrer un widget plutôt que de le cloner lorsque cela est possible

:   L'intégration d'un widget existant dans votre widget personnalisé tire parti des fonctionnalités préexistantes sans clonage ni duplication de code. Vous pouvez toujours passer des paramètres dans le widget intégré pour contrôler son comportement.

    Pour en savoir plus : [Incorporer un widget existant](https://servicenow-prod.fluidtopics.net/cNDCoduY0Gs9dnIcSOUb_Q#embed-widget "Permettez à l’utilisateur d’afficher et d’acheter Catalogue de services des éléments dans le widget Commande rapide en incorporant le widget Élément de catalogue SC.")

É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 des 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 de grands ensembles de données :

    * Éléments de menu scriptés qui chargent de grandes quantités de données, ce qui peut entraîner la lenteur du chargement de chaque page du portail.
    * Fichiers et pièces jointes volumineux, tels que des fichiers multimédias haute définition ou des polices 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 notifiant le client qu'il existe une mise à jour de la fonction de rappel peut également améliorer les performances.
    * Scripts côté serveur avec requêtes GlideRecord sans la fonction `setLimit` . L'utilisation de la fonction `setLimit` permet de limiter le nombre d'enregistrements renvoyés et d'améliorer le délai de réponse aux requêtes. Pour plus de flexibilité, vous pouvez lier cette limite à une option d'instance plutôt que d'affecter une valeur codée en dur (par exemple : `gr.setLimit(options.limit || 100)`).

    {#general-guidelines-developing-widgets__ul_s3c_nsh_l1c}  
    Pour en savoir plus:

    * [Six pièges courants en matière de performances dans Service Portal et comment les éviter \[KB0634588\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0634588)
    * [spUtil : recordWatch](https://www.servicenow.com/docs/access?context=spUtilAPI&version=xanadu&pubname=xanadu-api-reference&ft:locale=en-US)
    * [Fonction setLimit GlideRecord](https://www.servicenow.com/docs/access?context=c_GlideRecordAPI&version=xanadu&pubname=xanadu-api-reference&ft:locale=en-US)
    {#general-guidelines-developing-widgets__ul_t3c_nsh_l1c}

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'ensemble du widget crée des frais généraux inutiles. Au lieu de cela, utilisez 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 conserver les composants complexes avec des fonctionnalités côté serveur et côté client en tant que widgets. Utilisez une directive au lieu d'un widget incorporé pour :

    * Partagez le comportement du périmètre ou personnalisez le périmètre avec plusieurs widgets.
    * Partager une sous-section légère et réutilisable d'un widget.
    * Partagez une fonctionnalité d'interface utilisateur courante, telle qu'une liste ou un avatar.
    * Améliorez le comportement des widgets.
    {#general-guidelines-developing-widgets__ul_u3c_nsh_l1c}

    Pour en savoir plus : [Réutiliser les composants avec les fournisseurs d'angle](https://servicenow-prod.fluidtopics.net/32JBcbRlzjcXeYvf9FOH5A "Les fournisseurs d’angle sont des composants réutilisables qui peuvent être injectés dans plusieurs widgets. Pour garantir un chargement rapide des widgets et un portail performant, créez des fournisseurs d’angle au lieu de surcharger vos contrôleurs clients avec des données persistantes et une logique supplémentaire. Avec les fournisseurs d’angle, vous pouvez conserver les données pendant toute la durée de vie de vos Portail de services données et réutiliser des composants et des objets de données dans plusieurs widgets.").

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

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

    * Maintenez les widgets synchronisés lors du changement d'enregistrements ou de filtres.
    * Partagez des données entre les widgets.
    * Développez des widgets plus performants.
    {#general-guidelines-developing-widgets__ul_v3c_nsh_l1c}

    Pour en savoir plus : [Réutiliser les composants avec les fournisseurs d'angle](https://servicenow-prod.fluidtopics.net/32JBcbRlzjcXeYvf9FOH5A "Les fournisseurs d’angle sont des composants réutilisables qui peuvent être injectés dans plusieurs widgets. Pour garantir un chargement rapide des widgets et un portail performant, créez des fournisseurs d’angle au lieu de surcharger vos contrôleurs clients avec des données persistantes et une logique supplémentaire. Avec les fournisseurs d’angle, vous pouvez conserver les données pendant toute la durée de vie de vos Portail de services données et réutiliser des composants et des objets de données dans plusieurs widgets.").

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

:   Évitez [d'utiliser $broadcast](https://docs.angularjs.org/api/ng/type/$rootScope.Scope#$broadcast) dans les DOM. $broadcast distribue le nom de l'événement à tous les champs d'application enfants pour notifier les écouteurs enregistrés, ce qui peut être un appel coûteux qui nécessite l'utilisation de l'objet global $rootScope .

    Utilisez plutôt un service de publication/d'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 les gestionnaires de rappel. Dans ce modèle, vous pouvez mieux contrôler l'état de vos événements.

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

:   Lorsque vous appelez `server.update(),` l'ensemble du widget est renvoyé par le serveur. Si votre widget inclut des chemins de code divergents, plusieurs appels pour 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.
    {#general-guidelines-developing-widgets__ul_w3c_nsh_l1c}
:   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 gardant à l'esprit la localisation, l'accessibilité et l'interface utilisateur

:   Pour créer la meilleure expérience pour vos utilisateurs, suivez les instructions suivantes :

    * Tenez compte de l'impact de votre widget dans un environnement mobile. Par exemple, évitez d'utiliser le pointage 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](https://servicenow-prod.fluidtopics.net/og2ctMtb82pVFZu~1MBs2Q#css-variables "Les variables SCSS sont un moyen de stocker des informations que vous souhaitez réutiliser dans votre feuille de style. Vous pouvez stocker des éléments tels que les couleurs, les piles de polices ou toute valeur CSS que vous souhaitez réutiliser. SCSS utilise le symbole $ pour faire de quelque chose une variable.").
    * Utilisez des noms de variables lorsque vous utilisez des couleurs.
    * Encapsulez les chaînes à traduire dans les API de localisation. Voir [Internationaliser un widget](https://servicenow-prod.fluidtopics.net/RKG1Hsb5xBS2Fu_Tz92frA "Utilisez la syntaxe ${} ou gs.getMessage() dans les champs Modèle HTML, Script client ou Script serveur d’un widget pour baliser les chaînes à traduire afin de localiser votre Portail de services contenu.").
    {#general-guidelines-developing-widgets__ul_x3c_nsh_l1c}

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 du script client.

Évitez d'utiliser \<script\> tags in HTML templates
:   Pour 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.