I. Un peu d'histoire

Côté navigateur

L'évolution du web

• Page web statique : 1992-1996
• Page web dynamique : 1996-Aujourd'hui
• Single page application (SPA), 2005-Aujourd'hui, rendu possible grâce à AJAX

Côté serveur

• Côté Java/.NET les développeurs ont tentés de reproduire l'architecture client lourd
• Problème : HTTP n'est pas adapté
• Les langages de scripts se sont adaptés à HTTP (Ruby,Python, PHP)
• Le point commun : tous calculent intégralement la page à afficher et servent du HTML
• Le client ajoute juste quelques effets, validation, rechargement de certaines parties

II. La transition

Les écueils de l'architecture "serveur lourd“

• Complexification de l'architecture serveur
• Oblige à maintenir un minimum d'état côté serveur
• Page de plus en plus lourde en transfert de données
• Performance ressentie par l'utilisateur (rechargement complet)
• Les développements javascript sont souvent "secondaires" et difficilements maintenables(jQuery)

Qu'est-ce qu'une SPA ?

• Par définition il n'y a qu'une seule page web
• Les changements de "page" (en fait d'URL) sont prise en charge côté client
• Le contenu est changé dynamiquement sans rechargement de la page (ajax)

Facile !

Avec jQuery je met un peu d'ajax, des events et boum je passe en SPA

Les problématiques

• Déporter le rendu et sa logique sur le client signifie beaucoup de code client
• Ce code doit être clair, lisible, testé et maintenable comme n'importe quel code
• D'où l'apparition de framework Javascript

Architecture générale d'une SPA

Gestion des données

• Récupèrées/envoyées via AJAX généralement via une API REST
• Généralement en JSON, simple et léger

Gestion de la navigation

Comment fonctionne la navigation sur une seule page ?

• Changement d'URL via l'API pushState d'HTML5
• Généralement on utilisera plutôt la convention "#" > URL client
• # compatible ancien navigateur et demande aucune coopération du serveur

Gestion de la mémoire, des performances

Une seule page signifie, comme sur un client desktop

• Que chaque état est maintenu pendant toute la durée d'utilisation par défaut
• Qu'un traitement lourd peut bloquer l'interface

Autres considérations

• Comment synchroniser les données affichées avec celle du serveur de manière fiable ?
• Comment valider les données côté client, est-ce suffisant ?
• Quid de la gestion de droits, des formats d'affichage, de l'internationalisation etc..?

Une réponse possible : AngularJS

III. AngularJS

Kézako ?

• Framework "complet" SPA développé par Google
• Démarré en 2010, première version stable juin 2012
• De plus en plus utilisé

Principales fonctionnalités

• Synchronisation des données à double sens
• Injection de dépendance
• Concepts dédiés pour gérer le cycle de vie des objets (comme les scopes)
• Séparation de la manipulation du DOM de la logique de code (coucou jQuery)
• Orientation composant grâce aux directives
• Tout doit être testable

IV. Tour d'horizon des concepts

Controleur, scope et data binding

Exemple

Navigation

• Permet de faciliter la gestion des "pages"

Exemple

Filters

• Permet d'appliquer des transformations sur une donnée

Exemple

Services

• Encapsuler la logique métier
• Partage de données entre controleur
• Mise en cache
• Paramétrage de l'application via des providers

Directives

• Composants ré-utilisable

Exemple

Modules et injection de dépendance

• Découplage des composants, sépare les responsabilités
• Facilite l'écriture de tests
• Facilite le remplacement d'un composant par un autre