27 Avr 2015

Configurer ses routes sur une application AngularJS

Lors du développement d’une application hybride, nous avons eu besoin de mettre en place une gestion “avancée” des routes de notre application, en utilisant le composant de base fourni avec le framework AngularJS.

Dans notre contexte, et donc celui de cet article, nous avons utilisé angular 1.2.26, mais l’idée reste valable sur les versions suivantes!

Notre application étant bootstrappée à la main, nous disposions d’une méthode “launcheuse”.

Quand nous sommes en présence de quelques routes, cela fonctionne bien; en revanche, cela présente vite des soucis dés lors que les routes sont multiples:

  • Le code devient un fouillis complet
  • Les routes sont fixées en dur dans l’application
  • Il devient alors très difficile de les modifier sans prendre le risque d’introduire un bug

Pour corriger ce “défaut”, si l’on veux bien considérer que c’est en cela que nous sommes en présence, il existe une alternative simple, et sommes toutes efficace:

Déporter la configuration des routes dans un service provider dédié.

Comme certains l’auront remarqué, les routes sont gérées par un $routeProvider, ce qui veux dire que nous ne pourrons pas disposer d’un service pour le configurer au moment voulu (l’application n’étant pas encore démarrée, seuls les providers sont accessibles, les services le seront après).

Loin de nous ajouter un obstacle, cette constatation nous apporte déjà un élément de réponse: nous allons devoir passer par un provider maison pour configurer le $routeProvider d’angular.

Très simplement, cette méthode devra effectuer le boulot que nous réalisions avant dans le launcher.

Après simplification, le launcher devient donc

A partir de maintenant, nous avons déporté avec succès la configuration de nos routes vers un provider “maison”. Il reste néanmoins à permettre la modification des routes tout en limitant les impacts.

Imaginons une seule seconde que nous désirions modifier la route de la page d’accueil de “/” en “/home”.

Tout les endroits de l’application utilisant cette route devront alors être impacté. Sur notre projet, cela représente pas moins de 7k lignes de code à relire et éventuellement modifier.

Pour palier à ce souci, la seule solution qui nous est alors apparu envisageable est de ne plus utiliser de routes en dur, mais de demander à un service de nous renvoyer la bonne route en fonction d’une clé donné en paramètre: la clef ne changera jamais, la route devient d’un coup “flexible”.

Reprenons donc myAppRouteProvider, et ajoutons lui une méthode capable de nous fournir la bonne route.

Nous avons la une base pour pouvoir récupérer les bonnes url; néanmoins, notre méthode buildRoute est encore incapable d’accéder aux routes, il faut pour cela apporter une petite modification au code existant à ce stade.

A partir de maintenant, nous pourrons facilement accéder depuis n’importe ou dans l’application à la bonne route, tout en disposant d’une gestion des routes centralisée qui permet dorénavant de les modifier sans impact dans le code, il suffira pour se faire d’injecter myAppRouter – qui sera alors le service récupéré lors de l’appel à $get (automatique) -, et de faire appel à la méthode buildRoute avec l’identifiant de la route demandé.

Il est possible d’aller un peu plus loin dans l’usage de ce myAppRouter, mais cela fera l’objet d’un article ultérieur!

Share