Bonnes pratiques relatives à l’écriture de scripts client

9 minutes

Bien que le développement de scripts client puisse avoir l’air d’une tâche apparemment facile pour un développeur JavaScript chevronné, il est important de garder à l’esprit nos bonnes pratiques lorsque vous envisagez de les utiliser. Souvent, les développeurs oublient également que les utilisateurs peuvent accéder aux données à l’aide d’autres moyens. Par exemple, ils peuvent utiliser l’importation ou l’exportation de données, le studio de création, les applications canevas, les applications de bureau tierces, les scripts d’environnement d’exécution, etc. Vous devez résoudre des problèmes spécifiques liés à l’IU côté client et améliorer l’expérience utilisateur dans une application pilotée par modèle à l’aide de scripts client. Il ne s’agit ni d’une mesure de sécurité, ni d’une solution à tous les problèmes. Vous devez souvent combiner une approche côté client avec une approche côté serveur (par exemple un plug-in Dataverse) pour vous assurer que tous les points d’accès implémentent le besoin métier.

Utiliser le Vérificateur de solution

Le Vérificateur de solution peut effectuer des vérifications d’analyse statique sur vos solutions par rapport à un ensemble de règles de recommandation et identifier rapidement les modèles problématiques. Cette vérification comprend le code JavaScript utilisé pour les scripts client. Le Vérificateur peut identifier les problèmes de performance, de stabilité et de fiabilité pouvant nuire à l’expérience utilisateur dès leur survenue. Il peut également détecter l’utilisation de méthodes déconseillées. Lorsqu’il est exécuté régulièrement, vous pouvez identifier et résoudre de manière proactive les problèmes avant que les utilisateurs n’en aient connaissance. Vous pouvez exécuter le Vérificateur de solution à la demande depuis Maker Portal ou dans le cadre d’un processus de création automatisé. Cette automatisation lui permet d’être exécuté régulièrement et intégré à votre processus Application Lifecycle Management continu.

Pour en savoir plus sur l’utilisation du Vérificateur de solution, consultez Valider vos applications dans Power Apps à l’aide du Vérificateur de solution dans la documentation produit.

Règles métier et script client

Les règles métier sont une fonctionnalité disponible dans les applications pilotées par modèle qui permettent aux utilisateurs d’effectuer des actions fréquemment requises sur un formulaire en fonction de certaines exigences et conditions. Plus précisément, les règles métier peuvent effectuer les tâches suivantes :

Configurer des valeurs de champ
Effacer des valeurs de champ
Définir des niveaux requis de champ
Afficher ou masquer des contrôles de colonne de formulaire
Activer ou désactiver des contrôles de colonne de formulaire
Valider des données et afficher des messages d’erreur
Créer des recommandations métier basées sur le décisionnel.

L’une des fonctionnalités distinctes des règles métier est que les règles à étendue de table peuvent appliquer automatiquement la logique sur le back-end, le cas échéant. Cette étendue assure l’homogénéité de l’application, qu’une action soit exécutée au moyen de l’interface utilisateur, de l’importation de données ou d’un appel de méthode API. Le script client seul ne serait pas un équivalent complet dans ces scénarios.

Bien que l’infrastructure des règles métier disponible soit robuste, il peut exister des scénarios où les règles métier ne peuvent pas implémenter pleinement un besoin donné. Dans ces cas, les scripts client peuvent réduire les différences entre les règles métier et un besoin plus exigeant. Voici certaines limitations courantes que les utilisateurs rencontrent avec les règles métier où le script client peut être une meilleure solution :

Si vous devez référencer des données d’une table associée, par exemple l’adresse du contact principal d’un compte, vous devez utiliser un script client et l’API web.

Logique à exécuter lors de l’événement d’enregistrement de formulaire

Les règles métier s’exécutent uniquement lors du chargement d’un formulaire et lors de la modification d’un champ, sauf si vous définissez l’étendue sur Table. Vous devez utiliser un script client si vous devez exécuter la logique métier lors de l’événement de formulaire OnSave.

Conditions complexes

Si votre condition comporte plusieurs instructions and ou nécessite des instructions or, l’écriture de ces conditions dans le script client peut être plus efficace que dans les règles métier.

Effacer des valeurs de données de formulaire

L’effacement de données d’une colonne de formulaire n’est pas facile à réaliser dans une règle métier. Bien qu’il existe des solutions de contournement que vous pouvez utiliser, comme l’affectation d’une colonne « factice » qui comporte toujours des valeurs NULL, vous pouvez accomplir cette opération plus élégamment à l’aide d’un script client.

Colonnes calculées et script client

Les colonnes calculées exécutent la logique lors de l’extraction, donc les modifications côté client ne sont pas reflétées dans la valeur de la colonne calculée tant qu’un formulaire n’est pas actualisé. Si vous souhaitez que les données soient mises à jour instantanément sur le formulaire, le script client est la méthode préférée. Souvent, le script client complète une implémentation back-end utilisant des colonnes calculées ou cumulatives, des plug-ins, etc. Cette approche combinée peut fournir une expérience utilisateur homogène dans l’application, tout en garantissant la cohérence et l’intégrité des données au niveau du back-end.

Normes et recommandations relatives au codage

Les sections suivantes couvrent les bonnes pratiques et normes relatives au codage.

Définir des noms de fonction de script uniques

Les fonctions que vous écrivez sont très probablement dans un formulaire avec de nombreuses autres bibliothèques. Si une autre bibliothèque comporte une fonction portant le même nom que celle que vous fournissez, la fonction chargée en dernier est celle que le formulaire utilise. Pour éviter un conflit potentiel, veillez à utiliser des noms de fonction uniques. Vous pouvez utiliser les stratégies suivantes si vous ou votre organisation n’en avez pas encore établi une :

Préfixe de fonction unique : définissez chacune de vos fonctions à l’aide de la syntaxe standard avec un nom cohérent comprenant une convention d’affectation de noms unique, comme indiqué dans l’exemple suivant.
```
  function MyUniqueName_performMyAction()
  {
  // Code to perform your action.
  }
```

Bibliothèques avec espaces de noms : associez chacune de vos fonctions à un objet de script pour créer un espace de noms à utiliser lorsque vous appelez vos fonctions, comme illustré dans l’exemple suivant.

  //If the MyUniqueName namespace object isn’t defined, create it.
  if (typeof (MyUniqueName) == "undefined")
     { MyUniqueName = {}; }
     // Create Namespace container for functions in this library;
     MyUniqueName.MyFunctions = {
   performMyAction: function(){
   // Code to perform your action.
   //Call another function in your library
   this.anotherAction();
     },
     anotherAction: function(){
   // Code in another function
    }
  };

Lorsque vous utilisez votre fonction, indiquez le nom complet, comme illustré dans l’exemple suivant.

    MyUniqueName.MyFunctions.performMyAction();

Conseil

Si vous appelez une fonction dans une autre fonction au sein du même espace de noms, vous pouvez utiliser le mot clé this comme raccourci vers l’objet contenant les deux fonctions. Cependant, si vous utilisez votre fonction en tant que gestionnaire d’événements, le mot clé this fait référence à l’objet sur lequel l’événement se produit.

Éviter les méthodes non prises en charge

Bien que quelques ressources tierces en ligne puissent suggérer ou avoir des exemples de la façon dont des méthodes non prises en charge vous permettent d’effectuer certaines actions, cela n’est ni pris en charge, ni conseillé. Le fonctionnement de ces méthodes ne peut pas être garanti dans les futures versions de votre application et pourraient contribuer à l’instabilité de votre implémentation. Vous devez également éviter les méthodes que vous découvrez en inspectant les objets API dans le débogueur si les méthodes découvertes ne figurent pas dans la documentation officielle pour l’API client.

Rechercher l’utilisation de méthodes déconseillées dans votre code

L’API client est développée et améliorée continuellement. Il est important de rechercher l’utilisation de méthodes déconseillées dans votre base de code et de suivre les recommandations de la documentation pour leur remplacement. Si vous utilisez le Vérificateur de solution, il signale ces méthodes comme des problèmes.

Éviter d’utiliser jQuery dans les formulaires et les commandes du ruban

jQuery et d’autres bibliothèques de manipulation directe d’objets DOM HTML ne sont pas prises en charge dans les scripts de formulaire ou les commandes de la barre de commandes. Vous devez limiter vos scripts uniquement à l’utilisation des méthodes du modèle d’objet API client. Pour en savoir plus, consultez Comprendre le modèle d’objet API client.

Écrire du code non bloquant

Vous devez garantir une expérience utilisateur non bloquante à l’aide de modèles asynchrones lors de l’exécution de requêtes ou d’activités gourmandes en traitement.

Tentez d’éviter les méthodes bloquant l’IU comme les boîtes de dialogue de confirmation, le blocage des indicateurs de progression, etc. La méthode d’interaction préférée avec l’utilisateur consiste à utiliser des mécanismes de notification non intrusifs tels qu’une zone d’alerte très visible dans l’application ou le formulaire.

Écrire du code pour plusieurs navigateurs

Assurez-vous que tous les scripts que vous implémentez ont été testés pour fonctionner avec tous les navigateurs et facteurs de forme d’appareil que vos utilisateurs utilisent avec vos applications pilotées par modèle. Pour en savoir plus, consultez Navigateurs web et appareils mobiles pris en charge.

Continuer