AngularJS : architecture et bonnes pratiques

Un document que je ne saurai trop recommander pour les développeurs désireux de connaitre les bonnes pratiques sous AngularJS : https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/

C’est rempli de bonnes idées pour présenter sa solution, ainsi que sur les bonnes pratiques comme le nommage etc.

Architecture par fichier, répertoire ou bien modulaire ?

On a souvent l’habitude de voir des exemples d’applications AngularJS qui sont architecturés par ce que l’on appelle le « file pattern »:

AngularArchi02

 

L’ensemble des contrôleurs directives, services etc sont regroupés dans des fichiers.

Le problème avec cette approche, c’est qu’en terme d’évolution, on pourra vite se trouver avec des fichiers JS de taille importante… Imaginez que l’on ai une vingtaine de directives dans un même fichier ! Pour retrouver une directive spécifique il faudra prendre du temps pour scroller et la chercher…

Afin d’éviter cela, on préférera une architecture modulaire ou par features. Dans laquelle un ensemble de contrôleurs vues, services et directives seront répertoriées.

AngularArchi01
Dans cet exemple nous avons deux modules « bar » et « foo » qui ont des services et directives distincts. On préconise en général : 1 controlleur = 1 fichier .js etc
L’idéal ensuite est de créer un répertoire dans chaque module par type (Filters, Controllers, Directives, Partials etc.) afin d’avoir un classement des fichiers clair et lisible.

Il existe une démo qui applique de façon correcte ce pattern : https://github.com/angular-app/angular-app

Partagez:

AngularJS : authentification « token-based API »

Une question qui revient régulièrement dans la sécurité des applications SPA : comment gérer au mieux l’authentification des utilisateurs ?

Récemment, j’ai pu expérimenter ce que l’on appelle l’authentification « token-based API ». Le principe ? L’utilisateur fait une demande d’authentification à un controlleur de l’API (par ex « Authenticate »), si l’API confirme que l’utilisateur existe et que les identifiants sont corrects, alors il va renvoyer à l’utilisateur un token géneré. C’est ce token qui servira de moyen d’identifier l’utilisateur.

Ce token est conservé côté client, on pourra soit le mettre en sessionStorage ou bien en localStorage.

 

Les avantages sont assez nombreux : l’application web n’est pas fortement couplé à la méthode d’authentification (si demain je veux pouvoir authentifier les utilisateurs via une API Facebook par exemple), en terme de « Scalability » des serveurs, le token côté client contient les infos nécessaires pour identifier l’utilisateur. Enfin, on gagne en performance en comparaison de l’utilisation des traditionnels cookies.

Exemple concret

Côté serveur (Web API)

Nous allons créer une Web API sous Visual Studio, y ajouter un controlleur d’authentification, et une méthode « Login ».

WebAPI_Token

 

Ce que va faire notre méthode ici, c’est de vérifier si l’utilisateur dont le login a été spécifié existe en base de données. Si oui, on vérifier que son mot de passe haché correspond, si c’est le cas, on va générer un nouveau token et le renvoyer.

Voilà c’est tout pour la partie serveur !

Continuer la lecture de AngularJS : authentification « token-based API »

Partagez:

AngularJS : binding et utilisation de watch

Travaillant actuellement pas mal avec HTML5 et CSS3, j’en ai aussi profité pour me remettre à AngularJS 🙂

Ici, je vais présenter au travers d’un exemple, 2 concepts de ce framework que je trouve assez intéressants : le binding et la fonction watch.

Le projet

Nous allons créer une simple application web, capable de faire en temps réel des conversions de températures. Et ce, dans plusieurs sens.

Temperature Converter

Vous pouvez trouver les sources complètes ici : http://1drv.ms/1oZqTwS

Binding (two-way)

En reprenant le schéma du site AngularJS, voici ce que l’on peut comprendre :

En effet, le binding entre notre vue et contrôleur est dans 2 sens :

  • si je mets à jour la valeur depuis le contrôleur, elle le sera dans la vue ;
  • si je mets à jour la valeur depuis ma vue, elle le sera dans le contrôleur

Dans notre exemple, au niveau de la vue, on représente cela ainsi :

<input type= »text » class= »form-control » id= »valueInput » value= »{{valueConverted}} » readonly>

Le texte « valueConverted » présente entre accolades, est une variable qui sera accessible par le contrôleur.

Au niveau du contrôleur, nous aurons la syntaxe suivante pour mettre à jour la variable :

 $scope.valueConverted = 12;

Continuer la lecture de AngularJS : binding et utilisation de watch

Partagez: