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

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 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).

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

    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

    É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)).
    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’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.

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

    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.

    Pour en savoir plus : Réutiliser les composants avec les 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 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.
    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.
    • Utilisez des noms de variables lorsque vous utilisez 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 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.