Un widget n’a pas d’options d’instance définies lors de son ajout initial à 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.

Des 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 :

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

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

Pour en savoir plus : Incorporer un widget existant

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 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 ralentir le chargement de chaque page du portail.
• Fichiers et pièces jointes volumineux, tels que les fichiers multimédias haute définition ou les 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 informant le client qu’il y a 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 sur les 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)).

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. Utilisez une directive au lieu d’un widget intégré pour :

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

Les services de données et les usines maintiennent et conservent l’état dans un widget sans nécessiter plusieurs appels au serveur, ce qui vous permet de :

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

Évitez d’utiliser $broadcast dans les DOM. $broadcast répartit le nom de l’événement à tous les périmètres enfants en informant les écouteurs 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/d’abonnement pour gérer les événements. Lorsque vous utilisez 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.

Lorsque vous appelez server.update(), l’intégralité du widget est renvoyée par le serveur. Si votre widget comprend 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 les API REST basées sur un script qui appellent des includes de script sur votre instance. Cette pratique :

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