• Accueil / Salesforce / Blog Bob Buzzard :…
, Blog Bob Buzzard : JavaScript pour les programmeurs Apex, partie 1<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Blog Bob Buzzard : JavaScript pour les programmeurs Apex, partie 18 minutes de lecture


, Blog Bob Buzzard : JavaScript pour les programmeurs Apex, partie 1<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Fond

Lorsque j’ai commencé à travailler avec Salesforce en 2008, j’avais une
affinité pour le langage de programmation Apex, comme j’avais passé la décennie précédente
travailler avec des langages orientés objet – d’abord C++, puis 8 ans environ avec
Java. Visualforce a également été une transition très facile, car j’avais passé beaucoup de
le temps de construire des frontaux personnalisés à l’aide des technologies Java – les servlets d’abord
avant de passer aux pages JavaServer (maintenant
Pages du serveur Jakarta), qui chevauchait énormément avec la balise personnalisée Visualforce
approcher.

Un domaine où je n’avais pas beaucoup d’expérience était JavaScript. Bizarrement
J’ai eu quelques années d’expérience avec JavaScript côté serveur en raison de la maintenance
et l’extension de la
OpenMarket TRANSACT
produit, mais il s’agissait principalement de petits ajustements ajoutés aux fonctionnalités existantes, et
rien qui m’ait obligé à apprendre beaucoup sur la langue elle-même, comme elle
était à l’époque.

J’ai parfois utilisé JavaScript dans Visualforce pour faire des choses comme
l’actualisation d’un détail d’enregistrement à partir d’une page Visualforce intégrée,
Traitement en charge
ou
Cartes des dojos. Tous ces éléments avaient quelque chose en commun, ils étaient des extraits de
JavaScript qui ont été rendus par le balisage Visualforce, y compris les données qui
ils ont opéré. Il n’y avait aucune connexion avec le serveur, ni aucun type de
logique métier digne de ce nom – tout a été compris serveur
côté.

Puis vint
JavaScript à distance, que j’ai utilisé relativement rarement pour Visualforce pur, car je n’ai pas
particulièrement comme répartir la logique métier entre le contrôleur et le
frontal, jusqu’à ce que le
Application mobile Salesforce1
est venu avec. Utilisation de Visualforce, avec ses allers-retours de serveur et son re-rendu
de gros morceaux de la page se sont soudainement sentis maladroits par rapport à en faire autant que
possible sur l’appareil, et je fus saisi du zèle des nouveaux convertis.
Je suis presque sûr que mon JavaScript ressemblait toujours au code Apex qui avait été
par un processus de traduction automatique, car j’étais encore en train de comprendre
avec le langage JavaScript, dont une grande partie était tout simplement déconcertante pour mon serveur
yeux conditionnés côté.

Il n’a pas fallu longtemps avant que je regarde
jQuery Mobile à
produire
Applications d’une seule page
où le maintien de l’état est entièrement le travail du frontal, qui rapidement
m’a conduit à Knockout.js comme je pourrais utiliser
liaisons à nouveau, plutôt que d’avoir à mettre à jour manuellement les éléments lorsque les données
modifié. Cette période a culminé ma session Dreamforce 2013 sur
Mobiliser votre application Visualforce avec jQuery Mobile et
Knockout.js
.

Puis en 2015,
Composants Lightning (maintenant Composants Aura)
est arrivé, où tout à coup JavaScript est devenu réel. Plutôt que de rendre via
Visualforce ou y compris à partir d’une ressource statique, mes pages ont été assemblées à partir de
composants JavaScript réutilisables. Bien qu’Aura n’ait pas vraiment encouragé, c’est
développeurs sur la route JavaScript moderne, c’est le successeur –
Composants Web Lightning
– certainement.

Tout ceci est plutôt une longue introduction à l’objet de cette série de
blogs, qui sont destinés à (essayer d’) expliquer certaines des différences et
défis lors du passage à JavaScript à partir d’un arrière-plan Apex. Ce n’est pas un tutoriel JavaScript, c’est plus sur ce que j’aurais aimé savoir quand j’ai commencé. C’est aussi basé sur mon
expérience, qui, comme vous pouvez le voir d’en haut, a été quelque peu
chemin sinueux. N’importe qui
commencer leur voyage devrait le trouver beaucoup plus simple maintenant, mais
il y a encore de quoi déconcerter !

Dactylographie forte ou faible (lâche)

Le premier défi que j’ai rencontré avec JavaScript était la différence de
dactylographie.

Sommet

Apex est un langage fortement typé, où chaque variable est déclarée avec le
type de données qu’il peut stocker, et qui ne peut pas changer au cours de la vie du
variable.

    Date dealDate;

Dans la ligne ci-dessus, dealDate est
déclaré de type Date, et ne peut que
dates de magasin. Tente de l’attribuer
DateHeure ou
booléen les valeurs seront explicitement
provoquer des erreurs de compilation :

    dealDate=true;         // Illegal assignment from Boolean to Date
    dealDate=System.now(); // Illegal assignment from DateTime to Date

tout en essayant d’attribuer quelque chose qui pourrait être un
Date, mais s’avère ne pas être à
runtime lèvera une exception :

    Object candidate=System.now();
    dealDate=(Date) candidate; // System.TypeException: Invalid conversion from runtime type Datetime to
    Date

JavaScript

JavaScript est un langage faiblement typé, où les valeurs ont des types mais des variables
non. Vous déclarez simplement une variable en utilisant var ou laisser, puis attribuez
tout ce que vous voulez, en changeant le type selon vos besoins pour :

    let dealDate;
    dealDate=2;            // dealDate is now a number
    dealDate='Yesterday';  // dealDate is now a string
    dealDate=Date();       // dealDate is now a date

L’interpréteur JavaScript suppose que vous êtes satisfait de la valeur que vous avez
attribué la variable et l’utilisera de manière appropriée. Si vous l’utilisez
de manière inappropriée, cela sera parfois détecté au moment de l’exécution et une TypeError
jeté. Par exemple, en essayant d’exécuter le
en majuscule() méthode de chaîne sur un
nombre primitif :

    let val=1;
    val.toUpperCase();
    Uncaught TypeError: val.toUpperCase is not a function

Cependant, tant que la façon dont vous essayez d’utiliser la variable est légale,
une utilisation inappropriée ne vous donne souvent qu’un résultat inattendu. Prendre la
suivant, basé sur un exemple simplifié de quelque chose que j’ai fait un certain nombre de
fois – j’ai un tableau et je veux trouver la position de la valeur 3.

    let numArray=[1,2,3,4];
    numArray.indexOf[3];

qui revient indéfini, plutôt que la position attendue de 2.

Avez-vous repéré l’erreur ? J’ai utilisé la notation entre crochets au lieu de rond
crochets pour délimiter le paramètre. Ainsi, au lieu d’exécuter le Indice de
fonction, JavaScript était assez heureux de traiter la fonction comme un tableau et
retournez-moi le troisième élément, qui n’existe pas.

JavaScript fait également beaucoup plus de conversions automatiques de types,
faire des hypothèses qui pourraient ne pas être évidentes. Pour utiliser le
+ opérateur par exemple, cela peut
signifie concaténation pour les chaînes ou addition pour les nombres, il y a donc quelques
décisions à prendre :

gauche + droite

1. Si l’un des lhs/rhs
est un objet, il est converti en une chaîne primitive, un nombre ou un booléen

2. Si l’un des lhs/rhs
est une chaîne primitive, l’autre est convertie en chaîne (si nécessaire) et
ils sont concaténés

3. lhs et
rhs sont convertis en nombres (si
nécessaire) et ils sont ajoutés

Ce qui semble parfaitement raisonnable en théorie, mais peut vous surprendre en pratique :

1 + vrai

résultat: 2, true est converti en le nombre 1

5 + ‘4’

résultat ’54’, rhs est une chaîne donc 5 est converti en chaîne et
concaténé.

faux + 2

résultat: 2, false est converti en le nombre 0

5 + 3 + ‘5’

résultat ’85’ – 5 + 3 additionne les deux nombres pour donner 8, qui est alors
converti en une chaîne à concaténer avec ‘5’

[1992, 2015, 2021] + 9

résultat ‘1992,2015,20219’ – lhs est un objet (tableau) qui est
converti en une primitive à l’aide de la méthode toString, donnant la chaîne
‘1992,2015,2021’, 9 est converti en la chaîne ‘9’ et les deux chaînes sont
concaténé

Ce qui est mieux?

Est-ce mon premier rodéo ? Nous ne pouvons même pas nous mettre d’accord sur ce que signifient réellement les frappes fortes et faibles, donc décider si l’une est préférée à l’autre est une tâche impossible. Dans ce cas, cela n’a pas d’importance, car Apex et JavaScript ne vont pas changer !

Les langages fortement typés sont généralement considérés comme plus sûrs, en particulier pour
débutants, car plus d’erreurs sont piégées au moment de la compilation. Là peut aussi
des avantages en termes de performances car vous avez garanti au compilateur que
il peut utiliser lors de l’application de l’optimisation, mais cela devient de plus en plus difficile à quantifier
et en réalité, il est peu probable qu’il soit un facteur de performance majeur dans tout code qui
vous écrivez.

Les langages faiblement typés sont généralement plus concis, et la possibilité de transmettre n’importe quel type en tant que paramètre à une fonction peut être très utile lors de la création d’éléments tels que les enregistreurs.

Personnellement, je pense que le code est écrit pour les ordinateurs mais lu par des humains, donc tout ce qui clarifie l’intention est bon. Si je n’ai pas de typage fort, je choisirai une convention de nommage qui rend le type de mes variables clair, et j’éviterai de réutiliser des variables pour contenir différents types même si le langage me le permet.





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer