On vous l’avait annoncé, il est là, voici le deuxième article concernant l’isomorphisme en production. Cette fois on s’intéresse à comment ça marche techniquement, afin de vous aider à comprendre pourquoi ça fonctionne si bien et pourquoi on est super fan de cette technologie.

3.0 Architecture Flux

 

Flux est une architecture applicative développée par Facebook (à nouveau) et qui fonctionne parfaitement avec React. Elle diffère des modèles de MVC classiques en faveur d’un flux de données unidirectionnel. Flux est basé sur trois composants majeurs :

  1. Stores – Utilisé pour gérer les données
  2. Dispatcher – Permet de propager les actions
  3. Views – Nos composants React

 

À chaque fois qu’un utilisateur interagit avec une vue (view) une action est déclenchée. Le dispatcher redirige le flux dans le store correspondant, là ou les données et les logiques sont situées. La modification des données déclenche un changement des vues concernées et termine le processus.

Implémentation Flux

À noter que tous les concepts et guidelines proposés par Facebook dans leur documentation utilisent cette approche. Ensuite de ça, la responsabilité est laissée aux développeurs d’implémenter une architecture Flux dans les règles de l’art.

4.0 Quelques détails sur notre implémentation

Ressources techniques (non exhaustif)

4.1 Une vue d’ensemble globale

 

Le site est créé avec 5 sections différentes :

  • Accueil
  • Le projet
  • Les points forts
  • Les résidences
  • Localisation

Toutes les pages (type A), excepté “Les résidences”, ont une structure et des interactions similaires: un scroll harmonieux proposant des transitions entre chaque section de la page et des animations rapides.

La page “Les résidences” (type B) est différente des autres car elle donne à l’utilisateur la possibilité de naviguer dans les détails des différentes résidences.

Le changement de page par le menu de navigation déclenche une animation de transition, ayant inspiré un article intéressant sur codyhouse.co (en anglais : http://codyhouse.co/gem/animated-page-transition/).

4.2 Le composant de page

 

Toutes les pages de type A sont implémentées selon la structure suivante:

Le composant de page du site jardins-poudriere.ch

La page est représentée par un composant principal, une sorte de main-view-controller. Chaque enfant correspond à un composant de section qui contient une quantité multiple de subviews. Les subviews diffèrent de page en page.

Toute page de type A implémente un scroll de section (smooth-scroll). Ce dernier est partagé entre les composants des différentes pages comme un mixin qui est activé/désactivé selon le type de page.

La page de type A, qui utilise cet effet de scroll, va enregistrer un callback après chaque événement de scroll. Les vues parentes communiqueront à chacun de leurs enfants que le scroll a été exécuté et vont démarrer leurs animations ou exécuter leur logique si nécessaire.

4.3 Transition entre les pages

 

Une caractéristique intéressante du site internet correspond aux transitions entre les pages ! Cette animation se produit chaque fois que l’on change de page, donc chaque fois que l’url est modifiée.

Nous avons développé un SPA, c’est à dire qu’une transition ne va pas réellement charger une nouvelle page (avec une requête http), mais simplement rafraichir le DOM et générer un nouveau composant de page.

Pour le routing, nous avons implémenté react-router.

Nous avons, dans la mesure du possible, maintenu tous les processus d’animation dans une logique Flux, avec quelques légères exceptions. Voici comment ça fonctionne :

Transition des animations

  • Une route est déclenchée (A)
  • Le routeur reçoit l’événement et déclenche une action “startAnimation” (B)
  • La « Curtain view » (nous l’avons appelé ainsi pour son animation type “rideaux”) attend sur cette action pour démarrer l’animation
  • Quand l’animation se termine, une action “endAnimation” est déclenchée
  • Le routeur – qui était jusqu’à présent en attente – est averti de la fin de l’animation. Il récupère la fonction de handler (équivalent de l’action en MVC) pour l’URL courante et génère la nouvelle vue.

Nous aimons penser qu’une animation est comme une sorte d’interlude/transition entre deux états globaux de l’application, chacune est décrites par une url différente.

Une chose similaire se produit lorsque sur la page ‘Le projet’ le visiteur clique pour voir le détail. L’animation et la manière de gérer la transition est différente mais la philosophie est la même : il y a un transfert entre deux états différents where the animation is our ‘glue’.

4.4 Composants réutilisables

 

Pour faire les choses dans les règles de l’art nous avons pensé nos composants pour être le plus réutilisable possible. Ce n’est pas chose aisée avec un site tel que “Les Jardins de la Poudrière”, où tout se joue dans les détails.

Nous avons atteint notre objectif par notre manière de gérer le composant de page, comme expliqué dans le chapitre « Composant de page ». Il est possible de découvrir d’autres composants partagés dans le site :

  • La troisième section de la page d’accueil est la même que la page “Localisation”
  • The composant d’introduction des pages “Le projet”, “Localisation” et “Points forts” sont des extensions du même objet de base
  • Chacun des rectangles de subviews dans les différentes sections sont des extensions du même composant.

5.0 Feedback & fin

 

Avec “Les Jardins de la Poudrière” nous pensons avoir atteint l’objectif de proposer un design sophistiqué et très épuré avec une application web bien structurée et organisée.

Associer la technologie et le design est souvent un challenge délicat que nous aimons considérer: ajouter toutes les animations et interactions qui permettront aux designers d’être fier de leur création tout en réduisant au maximum la quantité de code.

Dans les showcases de sites il est fréquent de trouver des réalisations magnifiques mais avec de réelles problématiques d’implémentation, difficile à maintenir et à faire évoluer. Nous avons choisi de réaliser ce projet dans “une philosophie d’ingénieur” (certains diront que le projet est over-engineered et ils n’ont pas complètement tord) mais nous sommes fiers du résultat final!

Et tout ce travail et cet engagement a porté ses fruits car nous avons eux la bonne surprise de gagner un Awwwards SOTD et un CSS design AWARDS SOTD.

CSSDA - JardinsLogo Awwwards