AngularJS

Accéder à un service AngularJs depuis la console

Quand on débogue une application Angular il est bien pratique de pouvoir accéder et utiliser ses services depuis la console.
Si vous n’avez pas violemment injecté tous vos modules et services dans des variables globales, il n’est pas évident au premier abord de les récupérer.

Le bout de code suivant vous permet de récupérer l’instance du DI et donc de récupérer les services de notre application :

// récupération de l'injecteur de dépendances
// dans cet exemple, élément root (`ng-app`) affecté au noeud `html`.
var injector = angular.element("html").injector();

Une fois l’instance du DI récupérée, on peut utiliser la méthode get(...) associée :

// récupération du service GouzigouzaService
// dans cet exemple, élément root (`ng-app`) affecté au noeud `html`.
var monService = angular.element("html").injector().get('GouzigouzaService');

monService.plop(); // exécuter `plop`
monService.value; // accéder à la valeur `value`
600px-JavaScript-logo

Utilisez la méthode Function.prototype.bind() de Javascript

Chaque développeur javascript a un jour ou l’autre rencontré un problème avec le contexte associé à this.

Prenons l’exemple de code simpliste suivant :

var myObject = {

  crazyMessage: 'gouzigouza',

  doSomethingCrazy: function() {
    alert(this.crazyMessage);
  }
};

myObject.doSomethingCrazy();

Mon objet contient une propriété crazyMessage et une méthode doSomethingCrazy qui utilise la propriété crazyMessage.
Jusqu’ici tout va bien, le contexte de this au sein de la méthode doSomethingCrazy est bien l’objet myObject.

Maintenant, dans un élan de folie, je veux implémenter la méthode doSomeAsyncCrazyness :

var myObject = {

  crazyMessage: 'gouzigouza',

  doSomethingCrazy: function() {
    alert(this.crazyMessage);
  },

  doSomeAsyncCrazyness: function() {
    setTimeout(function() {
      this.doSomethingCrazy();
    }, 1000);
  }
};

myObject.doSomeAsyncCrazyness();

Aussi surprenant que cela puisse paraître, je récupère une erreur dans ma console :

Uncaught TypeError: undefined is not a function 

Cette erreur est due à this qui est désormais associé au contexte global et non plus à mon objet myObject, à cause de l’appel à setTimeout.

Mettre this en « cache »

Pour pallier ce problème, l’approche très souvent adoptée par le développeur est d’assigner this à une variable intermédiaire temporaire de type that ou self de la manière suivante :

var myObject = {

  crazyMessage: 'gouzigouza',

  doSomethingCrazy: function() {
    alert(this.crazyMessage);
  },

  doSomeAsyncCrazyness: function() {

    var that = this;
    setTimeout(function() {
      that.doSomethingCrazy();
    }, 1000);
  }
};

myObject.doSomeAsyncCrazyness();

De cette manière, l’appel à la méthode doSomeAsyncCrazyness fonctionne en effet comme prévu.

Une méthode bien plus élégante existe cependant et ce depuis ECMAScript 5.

.bind() magic

La méthode .bind() disponible sur le prototype de Function résoud notre problème en permettant, entre autres choses, de définir explicitement le contexte associé à this.

Nous pouvons donc réécrire notre code précédent de la manière suivante :

var myObject = {

  crazyMessage: 'gouzigouza',

  doSomethingCrazy: function() {
    alert(this.crazyMessage);
  },

  doSomeAsyncCrazyness: function() {
    setTimeout(function() {
      this.doSomethingCrazy();
    }.bind(this), 1000);
  }
};

myObject.doSomeAsyncCrazyness();

Avouez que c’est quand même plus joli.

Support des vieux navigateurs

Et si mon code doit s’exécuter dans un navigateur qui ne supporte pas ES5 ? Internet Explorer < 9 pour ne pas le nommer.
Dans ce cas, plusieurs solutions.

  • Continuer avec la technique de mise en cache de this
  • Utiliser la méthode .bind implémentée dans la plupart des frameworks JS (Angular.bind() par exemple)
  • Implémenter un fallback quand la méthode n’est pas disponible

Mozilla notamment propose le fallback suivant (Mozilla polyfill Function.prototype.bind()) :

if (!Function.prototype.bind) {
  Function.prototype.bind = function (oThis) {
    if (typeof this !== "function") {
      // closest thing possible to the ECMAScript 5
      // internal IsCallable function
      throw new TypeError("Function.prototype.bind - 
           what is trying to be bound is not callable");
    }

    var aArgs = Array.prototype.slice.call(arguments, 1), 
        fToBind = this, 
        fNOP = function () {},
        fBound = function () {
          return fToBind.apply(this instanceof fNOP && oThis
                 ? this
                 : oThis,
                 aArgs.concat(Array.prototype.slice.call(arguments)));
        };

    fNOP.prototype = this.prototype;
    fBound.prototype = new fNOP();

    return fBound;
  };
}

Pour aller plus loin

Quelques ressources pour aller plus loin :

AngularJS

AngularJs logicless templates : limitez la logique métier au sein de vos templates

Ceux qui ont utilisé un moteur de template logicless comme Mustache ou Handlebars savent immédiatement de quoi je parle. Un template doit contenir le minimum possible de logique métier. Et avec Mustachejs ou Handlebarsjs, le concept est poussé loin puisque c’est tout simplement impossible.

Logic-less templates – Semantic templates

J’ai découvert Handlebars sur mon premier projet EmberJs et son utilisation m’a paru bien déroutante au début. Voici un exemple de template Handlebars :

{{#if person.isAdmin}}
Welcome in admin area, <strong>{{person.firstName}} {{person.lastName}}</strong>!
{{/if}}

Jusque là, rien d’anormal ! Comment faire maintenant si je veux modifier un peu ma condition pour afficher ce bloc si la personne est Admin ou si elle est Super Admin ? L’extrait de code suivant semble tout indiqué :

{{#if person.isAdmin or person.isSuperAdmin}}
Welcome in admin area, <strong>{{person.firstName}} {{person.lastName}}</strong>!
{{/if}}

Pourtant c’est impossible ! Nous sommes dans un moteur de template logicless et nous n’avons pas la possibilité d’utiliser ce type de condition complexe.
Nous sommes dès lors obligés d’extraire la logique de notre template et d’injecter une condition simple, calculée en dehors. Exemple :

{{#if isAdminAreaAuthorized}}
Welcome in admin area, <strong>{{person.firstName}} {{person.lastName}}</strong>!
{{/if}}

Cela semble très contraignant au début mais on s’y fait finalement vite.
Ce type de template est en revanche parfaitement possible au sein d’une application AngularJs :

<p ng-show="person.isAdmin || person.isSuperAdmin">
    Welcome in admin area, <strong>{{person.firstName}} {{person.lastName}}</strong>!
</p>

Sur l’extrait de code précédent, la logique implémentée au sein du template reste assez concise. Mais je suis trop souvent tombé sur ce genre de templates sur des applications AngularJS :

<p ng-show="!isWorkInProgress && currentItem.price > 1000 && (user.id == currentItem.authorId || user.isAdmin || user.isSuperAdmin)">
  {{ currentItem.title }}
</p>

<p>Un paragraphe qui s'affiche toujours</p>

<p ng-show="!isWorkInProgress && currentItem.price > 1000  && (user.id == currentItem.authorId || user.isAdmin || user.isSuperAdmin)">
  {{ currentItem.description }}
</p>

Problèmes

Nous avons ici plusieurs problèmes :

  • Les conditions sont assez obscures et difficiles à comprendre
  • Les conditions sont répétées en plusieurs endroits au sein du même template
  • Mélange de logique métier et de logique d’affichage
  • La logique business est probablement dispatchée en différents endroits du code (des controllers, des services, des templates, …)

Difficile pour un intégrateur de travailler sur un template de ce type. Et quid du changement de condition pour l’affichage de nos blocs ? Nous sommes bons pour un chercher / remplacer douloureux.

Les moteurs de templates logic-less tels que que Mustache ou Handlebars sont loin de faire l’unanimité parmi les développeurs. En cause, leur aspect trop contraignant et l’obligation d’extraire la logique purement de présentation en même temps que la logique business. C’est vrai que finalement, la condition isWorkInProgress est liée uniquement à l’affichage et peut trouver légitimement sa place au sein du template.
Néanmoins, ces moteurs de templates logicless ont le mérite de forcer le développeur à extraire la logique business du template pour la centraliser au sein du controller ou de services dédiés.

Pour avoir le point de vue de personnes se positionnant contre les moteurs de templates logic-less, je vous conseille la lecture de The Case Against Logic-less Templates et de cet autre article dans la même veine : Cult of logicless templates.

AngularJS : extraction de la logique vers les controllers et services

En ce qui concerne vos applications AngularJS, de même qu’il est important de simplifier au maximum les controllers, il est important de limiter le plus possible la logique métier implémentée au sein des templates.

Dans les faits, le template précédent pourrait être repensé de la sorte :

<p ng-show="isItemViewableByUser(currentItem, user)">
  {{ currentItem.title }}
</p>

<p>Un paragraphe qui s'affiche toujours</p>

<p ng-show="isItemViewableByUser(currentItem, user)">
  {{ currentItem.description }}
</p>

Notre template est plus clair. Le nommage sémantique de la fonction qui conditionne l’affichage (isItemViewableByUser) rend le code compréhensible immédiatement. De plus, si la logique métier qui conditionne l’affichage change, le template n’a plus à changer.

Nous injectons cette logique dans le scope via le controller associé. Et pour ne pas faire l’erreur de remonter telle quelle une condition métier au sein du controller, n’oubliez pas d’extraire à son tour la logique métier de ce dernier vers un service dédié, rendant le tout plus facile à tester unitairement, plus facile à comprendre et donc plus facile à maintenir :

function MyCtrl($scope, UserService) {
    $scope.isWorkInProgress = false;
    // [...]
    $scope.isItemViewableByUser = function(item, user) {
        // Au choix, logique remontée au sein du Model
        // cf http://blog.overnetcity.com/2014/03/15/angularjs-models-donnees-model-data
        return !isWorkInProgress && user.canSeeItem(item);
        // ou au sein d'un service dédié
        return !isWorkInProgress && UserService.doesUserCanSeeItem(user, item);
    };
}

Pour aller plus loin

Quelques ressources pour aller plus loin :

ElasticSearch

ElasticSearch – Réindexation sans interruption de service grâce aux alias (zero downtime)

Lorsqu’un cluster ElasticSearch contient plusieurs nœuds, indexes, shards, replicas et surtout des millions, voire des milliards, de documents, il peut parfois être très long de réindexer tout le contenu.

En effet, il peut parfois arriver que l’on ait besoin de changer d’infrastructure technique (machine, virtualisation,…) ou que l’on veuille changer l’architecture du cluster ElasticSearch. Dans ce cas, comment maintenir notre service de recherche opérationnel 24h/24 et 7j/7 (SLA) tout en réalisant les opérations de maintenance désirées (zero downtime) ?

L’utilisation des alias ElasticSearch

Une fois encore les alias vont nous permettre de résoudre notre problématique. Un alias ElasticSearch peut être configuré de manière à pointer vers un ou plusieurs indexes d’un cluster tout en spécifiant des filtres ou des clés de routage.

Le point le plus important réside dans le fait que l’on peut changer la configuration d’un alias en une seule requête vers notre service d’indexation, et ainsi faire pointer un alias vers un ou plusieurs nouveaux indexes que l’on vient de reconstruire ou dont l’architecture vient de changer.

Ainsi, en utilisant systématiquement (bonne pratique) des alias (nom logique) à la place des noms d’indexes (nom physique) dans le code de nos applications clientes des services d’indexation, on pourra très facilement changer le ou les indexes cibles de nos recherches.

Exemple :

L’alias « produits » pointe vers les indexes « produits catégorie A » et « produits catégorie B » depuis que l’instance ElasticSearch a été démarrée. En une seule requête vers le cluster, on peut instantanément faire pointer notre alias « produits » vers les indexes « nouveaux produits catégorie A », « nouveaux produits catégorie B1″ et « nouveaux produits catégorie B2″ et sans interruption de services. On vient de changer par la même occasion notre découpage des indexes.

curl -XPOST localhost:9200/_aliases -d '
{
    "actions": [
        { "add": {
            "alias": "produits",
            "index": "produits_catégorie_A"
        }},
        { "add": {
            "alias": "produits",
            "index": "produits_catégorie_B"
        }}
    ]
}
'

puis

curl -XPOST localhost:9200/_aliases -d '
{
    "actions": [
        { "remove": {
            "alias": "produits",
            "index": "produits_catégorie_A"
        }},
        { "remove": {
            "alias": "produits",
            "index": "produits_catégorie_B"
        }},
        { "add": {
            "alias": "produits",
            "index": "nouveaux_produits_catégorie_A"
        }},
        { "add": {
            "alias": "produits",
            "index": "nouveaux_produits_catégorie_B1"
        }},
        { "add": {
            "alias": "produits",
            "index": "nouveaux_produits_catégorie_B2"
        }}
    ]
}
'

L’alias est la solution à privilégier pour garantir la haute disponibilité d’une application. Les alias permettent également d’organiser logiquement les indexes.

Voici un article sur le blog d’elasticsearch expliquant plus en détail ces problématiques et solutions : http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/