Pourquoi je n'aime plus trop faire du angular ?
Tags: angular, javascript, rxjs
Published: 2020-09-22 12:36:51

J'ai beaucoup fais de javascript, de toute sorte. Vanilla, jquery, react, angular, vue, mootools...

Faire du javascript c'est rarement expliqué et comprit par le client, lui tout ce qu'il veut c'est que son bouton bleu envoie un mail et affiche une notification verte.

Ok ! traduisons ça en langue de développeur :

- j'ai un bouton bleu
- au clic, faire un appel ajax
- à la réponse, si tout va bien, afficher une notification verte

Ok ça va ! c'est simple !

J'ai fais d'autres projets plus complexe, dont un qui m'a épuisé mentalement et quasi dégouté de faire des applis angular. Surtout pour éviter à devoir gérer tous les problèmes que ça implique.

C'était une appli pour gérer des voyages. Il fallait définir le pays, les lieux, en passant par la réservation d'hôtel, les tarifs, la location de véhicules, les visites groupées etc.

En soit, dit comme ça, le genre de projet très intéressant à faire !

En vrai, on a vu qu'on ne pourrait pas faire des pages php et des formulaires statiques. Il nous fallait du dynamique, de la réactivité, croiser les informations entre elles et afficher le tout...

Coup de bol, on avait eu droit à une formation angular et typescript peu de temps avant, et j'avais très envie d'en refaire.

Heureusement je ne m'occupais que de la partie angular et pas du code métier/api. 

# Organiser un voyage, comment ça se passe en coulisse ?

Il faut un jour d'arrivée et un jour de départ. C'est des personnes, adultes ou enfants. Un pays, un lieu et des activités.

Le client voulait une interface pour construire les étapes du voyage :

- sur la gauche de l'écran, une liste verticale composée de journée
- sur la droite, une liste de produits

Un produit c'était n'importe quoi, par exemple un safari en jeep, une balade sur le lac, une voiture de location etc.

Les journées pouvaient être drag&n drop comme on le voulait, en effet on pouvait décider d'inverser des produits par exemple. Ou bien décider de partir une semaine plus tard..

Certains produits étaient sur plusieurs jours, par exemple une sortie en mer pour faire le tour d'une île en 3 jours. Difficile d'inverser ces journées, il fallait les grouper.

Sur chaque journée, on pouvait cliquer et afficher un formulaire pour modifier encore des données. Celui-ci s'affichait dans une fenêtre qui venait de la droite, et on pouvait en superposer à l'infini (vu que tout est en asynchrone, si on voulait créer une donnée non disponible, il fallait garder néanmoins le contexte où on était).

Petite anecdote : je m'étais inspiré de google tag manager pour ceux qui connaissent, ça marchait bien et j'étais assez fier du résultat. J'étais même allé voir le javascript utilisé sur leur site...tiens tiens, du angular1. Oh tiens le code source non minifié. Bravo les gars ! Bon j'avais regardé comment ils avaient pensé la chose et je m'en suis sorti en angular2. Pas très professionnel de la part de Google.

## Les produits, tout et n'importe quoi !

La création des produits étaient très complexe. On pouvait louer des voitures, mais pour ça il fallait un fournisseur, et définir les prix par saison et par année.

Une sortie en mer, il fallait définir le prix, par groupe souvent, l'heure de départ et d'arrivée...

Un aspect complexe et non détaillé par le client, c'était la description des produits. En effet il fallait une description côté commerciale, une description côté devis et une description complète avec souvent des photos pour donner à la fin, une sorte de gros PDF qui ajoute un "+" à la satisfaction du client.

Je vous laisse imaginer les interfaces avec les formulaires.

## Les hôtels

Les hôtels...j'ai appris beaucoup de chose, mais le calcul des prix des hôtels ça peut faire mal à la tête.

Il y avait aussi la génération des vouchers. Quand vous réservez un hôtel, on vous donne des vouchers, avec le nom des personnes, date d'arrivée et départ et des informations sur l'hôtel...bref ! (à générer en pdf pour les imprimer)

Il faut aussi contacter l'hôtel pour lui soumettre la réservation, et qu'il puisse y répondre favorablement ou non. Si l'hôtel était indisponible, il fallait automatiquement switcher vers un autre hôtel, ainsi de suite...

## Itinéraire d'un voyage..

Souvent les gens n'ont pas de GPS ou leur téléphone à l'étranger...donc il fallait pouvoir générer un itinéraire entre les produits, dans un PDF. (itinéraire généré via google maps). Ca veut dire que sur chaque produit, il fallait ajouter un lieu avec des coordonnées précises.

## Et pour finir, le devis !

Tout ça c'est pour générer un devis au final, avec le détail des prix de tous les produits.
Avec des calculs alambiqués, des calculs de marges etc etc..

Le devis pouvait s'afficher de manière complexe pour le commercial, ou simple pour le client. On pouvait aussi dupliquer des devis pour proposer plusieurs choix. Dupliquer un devis ça revenait à dupliquer le voyage, c'était pas anodin comme action.

# Côté technique

Beaucoup de données à gérer implique beaucoup de code ! pour le meilleur comme pour le pire...

## RXJS

Heureusement que cette librairie existe, c'est sûrement une des plus cool ! On peut vraiment gérer toutes les sources de données comme on le souhaite. Mélanger, mixer, trier, attendre, grouper... une pépite ! De plus elle est adoptée par angular.

## Redux...ou plutôt NGRX

Aie, ouille...Super librairie également, par contre bourrée de BC breaks à l'époque, et pas du genre facilement résolvable sur un gros projet. 

Ils ont été capable de complètement changer leur api entre deux versions majeur et complètement délaisser l'ancienne version. Ce qui veut dire que pour continuer à utiliser les nouvelles versions d'angular, il fallait utiliser la nouvelle version de ngrx. 

C'est dommage d'avoir fait ça, bon nombre de gens ont été déçu. La migration, malgré leur fichier d'update, étaient très très compliqué..

## Typescript

Typescript est un super language, je ne reviendrai pas dessus pour vous dire pourquoi. 

## Un projet Angular

Mais un gros projet comme celui-là impliquait d'avoir une organisation et une structure robuste !

Angular raisonne en module, c'est très bien et on s'y retrouve facilement. Là où ça devenait plus épineux, c'était NGRX, parce qu'il fallait gérer la mise à jour du state, voir...des states.

Le fichier devenait assez gros, il fallait gérer les erreurs etc. Dans l'ensemble tout fonctionnait bien, le state également. Mais dans le sous-sol, derrière la porte d'où sortait une petite lumière verte, on entendait un bruit incessant. Celui de tous ces rouages qui tournaient, et qu'il fallait connaître par coeur pour ne pas s'y perdre.

Parce que finalement, des gros projects, aussi bien structuré qu'ils le soient, on s'y perds un jour ou l'autre. On se demande comment on a pu laisser ce fichier dépasser les 500 lignes, pourquoi ce template a été mal pensé et que fait ce Subject (rxjs) exactement déjà dans cette classe ?

C'était mon premier gros projet angular, et on pouvait vraiment faire ce qu'on voulait avec. Ca implique de gagner en connaissance et d'en apprendre encore et encore.

Angular est une grosse boîte à outils. Dedans il y a plein de chose à utiliser, les templates, les directives, le routing, l'authentification...

# Conclusion

Ce projet datait de 2017, depuis je n'ai plus refais d'angular, par crainte de devoir gérer des choses hallucinantes en javascript et typescript.

Oui rien que de penser à l'idée de maintenir un projet angular sur le temps me pousse à fuir !


Maintenant je fais un peu de vuejs, ça me semble plus simple. ReactJS, déjà fait, déjà re-fait...non merci ! faut aimer ça.

Bref, voilà, c'était ma petite histoire et je voulais la partager...ça fait du bien d'en parler !