Les fonctionnalités de Twig avec AngularJS: angular-twig-pack

Depuis que je travaille avec AngularJS, j'ai entendu beaucoup de gens comparer le Framework avec divers moteurs de template... Et il en existe! La liste (non-exhaustive) de wikipedia: Template_engine_(web) en est la preuve. Malheureusement, Wikipedia ne nous numérote pas ce tableau, heureusement que la console est là:

> document.querySelectorAll('.wikitable tbody tr').length

89

Bon ... Trêve de plaisanterie, passons aux choses sérieuses. Je me suis dit pourquoi ne pas prendre un moteur de template existant et créer un pack de directives, filters et services pour ne pas trop dépayser les puristes.

Kezako

Pour cet exercice, j'ai choisi le Framework Twig (uniquement car je l'ai déjà utilisé et surtout car j'adore les couleurs du site: http://twig.sensiolabs.org/).

Les différentes façons de créer un service avec AngularJS

[Ajout du 02/01/2013] : tableau récapitulatif, et exemple d'utilisation des cinq méthodes (voir à la fin de l'article)

Les services dans une application AngularJS sont organisés en modules. Et chaque objet module dispose de cinq méthodes différentes permettant de créer un service : constant, value, factory, service et provider. Nous allons voir quelles sont leurs particularités, et dans quels cas utiliser l'une plutôt que l'autre.

Mais d'abord, qu'est-ce qu'un service AngularJS ? C'est un objet JavaScript quelconque, qui peut même être un type primitif comme un nombre ou une chaîne de caractères. Par exemple le numéro de version de l'application, ou un objet contenant les informations sur l'utilisateur connecté, ou encore un objet qui met un ensemble de méthodes à disposition des contrôleurs. Ce qui en fait un service, c'est le fait de le publier sous un certain nom, via une des cinq méthodes citées, dans le module auquel il appartient. Attention, le module ne sert pas d'espace de nommage, donc il faut éviter de publier deux services sous le même nom dans deux modules différents, sous peine de collision si ces deux modules sont chargés ensemble dans la même application.

Donc un service n'est rien de plus qu'un objet publié sous un certain nom, pour qu'il puisse être injecté comme dépendance dans un contrôleur ou un autre service. Sauf qu'en réalité c'est un peu plus compliqué que ça. Lorsqu'on charge un module, les services ne sont pas immédiatement créés, et pour chaque service ce qui est référencé dans l'injecteur de dépendances, ce n'est pas le service lui-même puisqu'il n'existe pas encore, mais son provider.

Mettre les contrôleurs d'AngularJS dans un module

Dans les petits exemples d'utilisation du framework AngularJS publiés sur le site officiel ou ailleurs, les services, filtres et directives sont organisés en modules, mais les contrôleurs sont des fonctions JavaScript globales.

Mais si c'est un raccourci acceptable pour un petit exemple, ce n'est pas une bonne pratique d'avoir des fonctions définies dans le contexte global, en l'occurrence l'objet window du navigateur. Le contexte global étant le même pour tous les fichiers JavaScript chargés dans une page web, moins on y met de choses, et moins on a de risques de collisions avec les bibliothèques qu'on charge. Donc une fonction globale, ce n'est certes pas aussi grave qu'une variable globale, mais quand on peut il vaut mieux éviter.

Et justement, contrairement à ce que laissent penser les exemples en question, une application AngularJS n'a en rien besoin de définir des fonctions dans le contexte global. Les contrôleurs peuvent être placés dans des modules, comme les services, les directives et les filtres. Dans une grosse application, il y a tout intérêt à les organiser en modules comme le reste.