La technologie évolue vite, particulièrement dans le monde du développement front-end. Il en est de même pour les trends et solutions en webdesign. C’est une sorte de challenge continu auquel Superhuit aime prendre part.

Il y a quelques mois nous avons eu l’opportunité de travailler sur un projet passionnant, la promotion d’un projet immobilier de standing (Les jardins de la Poudrière). Un site vitrine limité dans le temps, qui s’oriente autour d’une expérience web riche; l’occasion rêvée pour nous de tester de nouvelles technologies! Nous partons donc sur un trend prometteur et très “edge” en début de projet: l’isomorphisme.

Notre passion du web nous encourage à envisager
le challenge technologique !

 

Pourquoi nous avons choisi un stack isomorphique

Nous poussons l’équipe graphique à stimuler l’équipe technique, et inversement. Ainsi, en plus de l’envie de s’essayer à ce récent trend de “Javascript Isomorphic Application” et après une première review du concept et esquisses du design, voici quelques raisons ayant motivé notre choix:

  1. Une quantité importante d’interactions visuelles Le site est une visite guidée virtuelle à l’intérieur du monde des “Jardins de la Poudrière”, l’utilisateur doit être guidé par des animations rapides et des interactions réactives.
  2. Une expérience définie par son timing et sa perception par les utilisateurs Réduire et maîtriser le délai de transition des pages afin de fluidifier l’expérience est primordial. Pour ceci, une architecture type “Single Page Application” est nécessaire.
  3. Un référencement optimal Une promotion immobilière digitale a pour vocation d’être rapidement visible à large échelle, ainsi le SEO (ou référencement naturel) s’impose comme une priorité dès les première réflexions du projet. Une solution isomorphique possède un réel avantage à ce niveau.

Chez Superhuit, nous mettons le design et le développement au même niveau

Transition de page – Jardins de la Poudrière

Un routing isomorphique nous a permis une meilleure gestion des transitions de pages.

Partie technique / Innovation

 

Durant cette période de grande fragmentation de la communauté des frontend dév. – le nombre de nouveaux patterns, librairies et frameworks chaque mois ne décroit pas! – une architecture React/Flux nous semble très intéressante à plusieurs niveaux (nous y reviendrons).

SEO / Graceful degradation

 

Avec un stack isomorphique, nous avons pu résoudre les problèmes de l’application liées au SEO et à la partie clients; la page est générée une première fois par le serveur et ainsi le contenu nécessaire au SEO est immédiatement intégré dans la page. C’est un problème commun à beaucoup de sites JS une solution pas si commune pour une application web. Nous avons aussi opté pour une stratégie appelée “graceful degradation”: ainsi les navigateurs modernes peuvent “apprécier” au mieux le site avec l’ensemble des interactions, alors que ceux plus anciens ont un accès au contenu mais dans une version plus légère, par exemple sans les animations, permettant de ne pas perdre des utilisateurs armés de machines plus anciennes. Et grâce à sa nature isomorphique, il est aussi possible de naviguer sur le site sans avoir le javascript activé. Vous pouvez essayer!

La confiance et la collaboration

 

Finalement, et ce n’est pas des moindres! Nous avons eu la possibilité d’envisager cette nouvelle technologie grâce à la confiance que nous a offerte notre mandant pour ce projet, et c’est une chance de pouvoir collaborer dans ces conditions !

C’est sans regret que nous avons donné carte blanche à l’agence Superhuit qui représente bien cette ADN d’innovation et de qualité Suisse !
Nicolas Duvoisin, Valgérance Sàrl

La technologie React

React est une librairie Javascript développée par l’équipe dév. de Facebook/Instagram qui permet de générer des interfaces web, basées sur un état de données changeant (appelé “state”), le tout organisé par composants réutilisables.

En plus d’Instagram et certaines parties de Facebook, de plus en plus de sites web et applications utilisent React. Facebook a d’ailleurs mis en place une liste non-exhaustive sur son github.

Composants hiérarchiques

 

React permet de designer tous les éléments d’interface comme un ensemble de composants. Tous ces composants respectent une hiérarchie utilisant un schéma commun parent/enfant. C’est une approche très utilisée lors du développement d’une application web: nous avons voulu maintenir cette philosophie pour ce projet, bien que notre site consiste plus en une forme de portfolio/site de présentation.

Etat des composants

 

Chaque composant possède une collection de variables déterminant sont état (state). Cet état peut changer après une interaction de l’utilisateur avec l’interface ou lors d’une manipulation des données. Si nous prenons l’exemple d’un composant “Ampoule”, nous pouvons imaginer qu’il aura un état qui décrit si l’ampoule est ON ou OFF. Il est aussi possible que le composant ait un bouton qui permette de passer de ON à OFF et inversement.

Chaque fois qu’il y a un changement d’état, React va générer un nouveau rendu de tous les composants qui partagent le même état en utilisant la technique du “Virtual DOM”

Virtual DOM

 

React garde une trace du “DOM tree” généré en utilisant un modèle DOM de javascript (Virtual DOM par Matt Esch sur github).

De cette manière, à chaque changement d’état générant un nouveau rendu, nous pouvons exécuter des opérations et des comparaisons de « diff » entre le « DOM tree » actuel et le nouveau « DOM tree » virtuel pour y insérer dans la page seulement les élément qui ont été changés. Un réel gain de performances donc!

Principe du virtual DOM Diffing

Source: http://techblog.constantcontact.com/software-development/reactive-component-based-uis

Event handling

 

Chaque composant React est livré avec une liste intégrée d’événements DOM pris en charge. React offre un « cross browser wrapper » permettant de gérer tous les événements DOM de manière solide, dès lors on simplifie le job de Mr Ducky!

React est aussi intéressant pour gérer:

  1. Les liaison automatique des « event’s callbacks » pour le bon contexte (généralement le contexte du composant);
  2. Un haut niveau de la délégation de l’événement. Les événements ne sont pas liés directement à DOM mais sont gérés d’une manière plus globale, afin que nous puissions monter/démonter nos composants sans se soucier de fuites de mémoire ou de zombies.

 

Nativement généré du côté serveur

 

Une application « single page » en Javascript passe habituellement par une phase de “bootstrapping” responsable d’un premier chargement particulièrement lent puisqu’il s’agit de charger la page html (vide ou presque), puis l’application JS, pour finalement générer le rendu à l’exécution du Javascript. D’un point de vue SEO, le temps de rendu ainsi que la nécessité de Javascript peuvent être pénalisants.

React vient nous aider à nouveau: par une prise en charge du rendu côté serveur avec Node.js (grâce à la technologie Virtual DOM), la page demandée est premièrement générée par le serveur puis envoyée telle quelle au navigateur client.

Le navigateur affiche donc immédiatement la page reçue, puis charge le javascript qui reprend la main sur l’exécution de l’application en commençant par détecter les différences éventuelles de “states” entre la première génération (côté serveur) et la page actuelle, et lier les événements au DOM – clic, scroll, etc.

jQuery free

 

Bien que cette librairie incontournable nous sauve encore bien souvent la vie ne serait-ce que pour des questions de compatibilités navigateurs, elle ne nous a pas manqué pour ce projet, React forçant une logique “data-driven” – le DOM est généré à partir de données JS – à l’inverse de la logique jQuery qu’on peut qualifier de “DOM-driven”.

ET LA SUITE ?

Nous reviendrons dans deux semaines avec une deuxième partie qui traitera de l’architecture Flux et d’ici-là, c’est avec plaisir qu’on discute de vos expériences isomorphiques, avec React ou autre!

Quelques ressources pour aller plus loin avec React: