React et Redux sont pour beaucoup deux faces d'un tout immutables. Il est difficile de trouver une formation ou un projet où redux n'a pas été choisi comme outil de gestion d'état. Pourtant, force est de constater qu'il est la plupart du temps très mal utilisé. Nous allons d'abord voir pourquoi j'estime que son usage dépasse son objectif, et nous verrons quelles meilleures solutions existent.

The single source of truth

Redux est conçu pour gérer l'état global d'une application. Il est prévu pour permettre de partager des informations entre différentes parties de l'application mais il incite surtout à faire passer absolument toutes les informations d'une app par ce store. En théorie, les composants react ne contiennent absolument aucune logique métier de traitement des données et se consacrent strictement à l'interface pendant que redux met à disposition des actions qui sauront manipuler les modèles et les publier dans ce store.

Les limites à cette description idyllique arrivent quand on commence à vouloir découper son application en modules réutilisables. Redux fonctionne avec un seul et unique store. Pour permettre de greffer des reducers provenant de modules extérieurs, il faudra donc combiner le reducer supplémentaire au store de son application. Bref, en plus de devoir importer les composants du module, il faut aussi aller câbler les actions et les reducers de ce module. Pas très plug'n'play. Nous verrons dans la seconde partie comment cela pourrait être bien plus simple avec des techniques standards. Ma quête vers la modularité a été grandement motivée par le fait qu'il semble pour beaucoup obligatoire de faire passer par redux la moindre des données, même si une requête est faite par un seul et unique composant dans toute l'app et qu'elle n'a évidemment aucun besoin de partager son résultat avec le reste de l'app.

Un constat que j'ai pu faire aussi est que redux semble trop souvent utilisé comme outil pour faire passer des infos dans des composants sans les faire passer de parents à enfants. Tout simplement car Redux est bâti depuis toujours sur l'API context de react, qui était jusqu'au mois de Mars 2018, officiellement déconseillée d'usage par l'équipe de React. Un développeur cherchant une solution pour contextualiser des données et se tournant vers la doc de React context se voyait afficher un message anxiogène lui indiquant que cette API était vouée à disparaitre et qu'il ne fallait absolument pas l'utiliser. Redux était ainsi une solution plus sereine (alors que pourtant tout aussi dangereuse) pour arriver à ces fins.

Et c'est ainsi que redux est utilisé pour stocker tout plein de trucs dans un gros store global. Autant balancer des variables globales dans window, ça reviendrait à peu près au même.

Modularité

Je suis très souvent confronté à des architectures où plusieurs sites se partagent de nombreux modules d'accès aux données et une API identique. J'ai donc un regard un peu plus global que : "un projet" => "une app". C'est pourquoi j'ai toujours perçu redux comme un frein. J'avais besoin de contextualiser des données, mais dans des scope limités. Et surtout, j'avais envie que mes modules soient utilisables en ne faisant rien de plus qu'importer les composants de ce module. J'ai donc, dès Mars 2018, regardé du côté de React Context. Celui-ci permet de générer un Provider et un Consumer dont le but est justement de faire passer des données à travers un arbre de composants. J'ai donc par exemple un module Authentification publiant un composant AuthProvider et un hoc withAuth qui permettront à mes apps de gérer l'authentification de la même manière. Je peux de plus placer mon <AuthProvider> au niveau le plus cohérent avec mon app : soit à la racine si toute mon app doit changer de comportement selon l'auth, soit uniquement au niveau des routes privées.

L'autre aspect qui me plait beaucoup avec cette approche, c'est qu'on peut le plus simplement du monde gérer ses actions et les mises à jour de l'état du Provider avec async/await sans se taper un immonde reducer.

Je vous laisse jeter un œil à cet exemple qui montre un provider de compteur asynchrone qui est consommé par un composant qui affiche la valeur du compteur, et un autre composant qui appelle l'action d'incrémentation asynchrone.

Cet usage de Context et de async/await me permet de plus facilement découper mes fonctionnalités par modules et de garder côte à côte les composants et leurs stores. Ce qui rend évidemment bien plus simple la publication de chacun de ces modules dans des packages npm afin qu'ils soient réutilisés en toute simplicité dans d'autres applications.

Et ce qui me permet d'écrire cet article alors que mon expérience en react/redux est largement plus courte que la plupart de la communauté (j'ai commencé en décembre dernier), c'est que le futur du React va s'orienter officiellement vers ce genre de pratique grâce aux hooks useContext et useReducer qui permettront, en natif, sans lib supplémentaires, de gérer des stores modulaires tout en gardant la liberté de choisir le pattern de reducer ou de l'async/await.

J'ai eu besoin de monter un rapide backend pour un petit site statique auquel je devais ajouter une API de blog légère. On est en 2018, j'ai donc décidé de monter cette API avec GraphQL. GraphQL, c'est un protocole proposé par facebook permettant de construire des requêtes complexes, particulièrement efficace lorsqu'il s'agit de récupérer une arborescence de données. Dans mon cas, j'aurais pu me contenter d'un rapide REST mais qu'aurais-je appris alors ? Pour la petite histoire, mon cas s'est finalement arrêté sur Firebase de Google, qui méritera lui aussi un bel article, mais ma recherche n'aura pas été vaine car elle aura au moins servi à produire cet article.

Nous allons donc construire un backend en nodejs qui servira une API GraphQL à l'aide de express-graphql. Vous pouvez déjà consulter les sources de mon exemples.

Je ne vais pas traduire la doc de express-graphql qui est vraiment très claire. Je vais simplement approfondir les sujets les plus importants (ceux pour lesquels j'ai du relire plusieurs fois la partie dédiée de la doc 😅)

Usage

Il est bon de commencer par comprendre comment on va utiliser notre API. Ça peut être pratique pour la tester, surtout si, comme moi, vous n'avez encore jamais utilisé ce type d'API.

On communique avec un serveur GraphQL par le biais de requêtes POST. Dans le body de ces requêtes, on attache un objet qui va décrire notre requête. Cet objet contient deux paramètres importants : query et variables. Le premier, c'est notre requête GraphQL, le second, c'est une liste de variables qui seront passées à la requête. Une fois qu'on a compris ça, on peut s'en foutre puisqu'on va utiliser des libs qui gèrent ça très bien toutes seules.

Ce qui est très pratique avec express-graphql, c'est qu'il inclut en option une webui permettant de se requêter lui même. Lorsque vous construisez votre serveur GraphQL, vous avez la possibilité d'activer ce serveur via le paramètre graphiql :

const graphql = graphqlHTTP({  
  schema,
  rootValue,
  graphiql: true,
});

Dans ce cas, lorsque vous taperez votre API d'un GET, vous obtiendrez une page html matérialisant une console grâce à laquelle vous allez pouvoir jouer avec votre API en cours de construction :

Pensez à la désactiver en prod.

Query

Le serveur s'attend donc à recevoir une query dans un format particulier. D'où le QL de GraphQL. Cette requête va donc décrire précisément la structure de données que vous espérez recevoir. Imaginons que nous voulons recevoir le user connecté ainsi que ses 10 derniers posts publiés. Avec une API REST, on va faire deux requêtes, la première pour avoir le user, la seconde pour avoir les posts du user. Sauf si côté backend on a pensé à faire un endpoint pour avoir ça d'un seul coup. Mais c'est pas documenté alors on sait pas. Et puis les posts, on les veut juste pour afficher le titre donc si on pouvait se passer de charger tout leur contenu, ça serait mieux. Bon. Avec GraphQL, on va juste demander ce dont on a besoin. On veut le prénom du user pour lui dire bonjour, et les titres et le slug de ses 10 derniers posts pour lui faire une liste de liens :

{
  me {
    firstName
    posts(page: 1, perPage: 10, orderBy 'publishedAt') {
      title
      slug
    }
  }
}

Et je recevrais alors un objet de ce genre :

{
  firstName: 'Georges',
  posts: [{
    title: 'Monde de merde',
    slug: 'monde-de-merde',
  }, /*x10*/]
}

Avouez que c'est assez pratique.

Côté backend, on va donc devoir définir un schéma pour pouvoir cadrer nos requêtes et renvoyer automatiquement les erreurs qui permettront au consommateur de l'API de corriger sa requête tout seul comme un grand. Ensuite, nous n'aurons plus qu'à lui attacher des resolvers, des méthodes qui vont répondre à chacune de nos définitions de requêtes.

Schema

La première étape est donc de définir un schéma d'API. On va définir des structures typées et des structures de requêtes. On pourra voir par la suite qu'on peut utiliser tous les outils qu'offrent tous langages de programmation typés telles que les interfaces par exemple, mais on va rester simple pour le moment. Notre schéma pour la requête du dessus va contenir 3 type : User, Post et Query. Les deux premiers vont décrire toutes les propriétés que peuvent avoir ces deux entités. Le dernier va décrire les méthodes qui peuvent être appelées dans une requête, leurs paramètres et le format de leurs réponses.

Ça donnera un truc dans ce genre :

{
  type Post {
    id: String!
    title: String!
    content: String!
    slug: String!
  }

  type User {
    id: String!
    firstName: String
    lastName: String
    posts: [Post]
  }

  type Query {
    me: User
    user(id: String!): User
  }
}

Donc on voit que chaque attribut de chaque type est typé. On voit aussi que certains types ont un !. Ça signifie juste que la valeur doit être non nulle. On voit aussi que certains type peuvent faire appel à d'autres. Ainsi, User possède un attribut dont la valeur est un tableau de Post. Pour finir le type Query propose deux exemples différent. Le premier est en fait une méthode sans paramètre. On va juste demander à recevoir me (donc "moi") et on recevra un objet de type User me représentant. Le second prend un paramètre nommé id et obligatoire (!) et retournera un objet de type User représentant la ressource correspondant à l'ID demandé.

Tout cela est en réalité bien plus complexe et puissant, mais le but était juste d'avoir une idée globale du concept.

Résolveurs

Oui j'adore traduire le maximum de termes anglais. On va pour finir écrire des fonctions qui seront exécutées pour récupérer les données. Ainsi, quand on demande un user et ses posts, on ira peut être chercher le user dans un PostGreSQL, et les posts dans un MongoDB : les deux types de données seront récupérées en parallèle. Avec express-graphql, c'est donc le second attribut de la fonction graphqlHTTP : rootValue. Il s'agit d'un objet listant les méthodes du type Query spécifiés dans le schema passé en premier paramètre.

Ces méthodes prendront deux paramètres : le premier est un objet contenant les variables passées à la requête. Ainsi, si je demande :

{
  user(id: 42) {
    firstName
  }
}

Alors :

{
  user({ id }) {
    return UserService.getById(id);
  }
}

id vaudra 42.

On pourra grâce au second paramètre accéder à l'objet de requête express afin d'aller récupérer des infos sur la requête et notamment la session d'authentification :

{
  me(_, { user }) {
    return UserService.getById(user.id);
  }
}

Et du coup, pour finir avec en bonus, comment gérer l'auth, même si ça sort du sujet de l'article : petit rappel pour ceux qui n'ont pas fait d'express depuis bien trop longtemps comme moi.

Auth et autres middleware

Pour gérer l'authentification, on utilise un middleware et on va ajouter des données dans l'objet req qui sera passé de middleware en middleware jusqu'à arriver à GraphQLHTTP. Ainsi, si on veut qu'un token soit passé à la requête en querystring, celui-ci permettant de décoder un ID de user, alors on configurera notre app de la sorte :

Le middleware d'authentification :

function auth(req, res, next) {  
  const { query: { token } = {} } = req;

  if (token !== '1234') { // le token est hardcodé parce que la sécurité c'est pas très important de nos jours
    return res.sendStatus(401);
  }

  req.user = UserService.getByToken(token);

  return next();
}

Qu'on placera donc avant GraphQL :

const app = express();  
app.use('/', auth, graphql);  

Et voilà, si le token "1234" n'est pas passé, alors on n'accèdera pas du tout à GraphQL. Dans le cas contraire, GraphQL aura accès à la propriété user savamment placée dans req.

Conclusion

Il est finalement possible d'architecturer à loisir votre code. Dans mon exemple, j'ai fait le choix d'avoir un seul endpoint (/) pour accéder à toutes mes données et de découper mon schema en plusieurs morceaux. On peut faire autant de endpoints qu'on veut (allez donc lire la doc d'express si vous ne savez pas comment faire), ce qui peut être notamment pratique si on veut donner à accès à certaines requêtes en public et on peut aussi n'avoir qu'un seul gros fichier pour définir le schéma complet. Et il est aussi possible d'exporter le schema définitif grâce à des outils dédiés pour servir de documentation.

Il est évidemment aussi possible de construire un serveur GraphQL avec n'importe quel autre langage qui s'exécute sur un serveur.

Tester son code est une étape primordiale quand on vise une base de code pérenne. Les tests permettent de détecter en même temps que le développement les éventuels bugs et régressions que les nouvelles fonctionnalités pourraient apporter. Mais écrire des tests, c'est long et c'est pas très rigolo, surtout quand on est développeur de guichet (front-end pour les non initiés à l'Académie Française). Et puis bon, je donne des leçons, mais moi aussi il m'arrive de ne pas tester mon code. Voici pourquoi.

Parce que j'ai pas le temps !!!!

Oui, souvent la date de livraison du projet est très courte et il faut aller très vite. Tester son code en live dans son navigateur, puis sur d'autres navigateurs est déjà très chronophage. Rédiger des tests avant d'être sur que le DOM généré sera celui qui correspondra à la maquette sur tous les navigateurs supportés peut aussi être une source de perte de temps. Oh et puis, on est agile, donc quand on commence un développement, il est très probable qu'avec l'agilité de la biche, on nous demande de changer des trucs en cours de route. Du coup, j'ai plutôt tendance à rédiger les tests à la fin. Mais à la fin, souvent, j'ai plus le temps parce qu'il fallait livrer hier.

Parce que c'est moche !!!!

Alors ici, c'est un argument vraiment typique du développeur front. Ce qui fait la différence entre un développeur de guichet et d'arrière guichet (back end), c'est sa sensibilité aux belles choses. Le backend lui, il s'en fout du rendu. Tant que sa donnée est correctement transformée comme il l'a décidé ou que sa commande agit tel qu'il le lui a ordonné, un terminal fera aussi bien l'affaire qu'un design léché. Et donc, finalement, les tests, c'est même carrément sexy pour lui. Le front dev, lui, il développe du design, du graphique, du visuel, de l'ergonomie, du feeling, des choses difficilement appréciable autrement qu'à l'usage. C'est d'ailleurs souvent pendant le développement qu'on se rend compte que certains détails de la maquette figée en jpg ne sont pas cohérents et qu'on fait alors appel aux instincts de biche du développeur pour modifier et améliorer la situation. Donc finalement, on est déjà en alternance entre dev et tests du simple fait d'aller voir le résultat de son dev sur son navigateur. Et une fois le résultat accompli, on est content de voir ces belles choses s'afficher et on a pas vraiment envie de doubler l'effort pour voir des trucs moches dans un terminal qui ne correspondent à rien de concret.

Parce que c'est compliqué !!!!

Cette fois, ça vaut aussi pour le dev d'arrière guichet, mais moins, car lui n'a pas vraiment le choix finalement. Il est obligé de passer par des tests s'il veut constater que son code fonctionne. Donc pour les raisons évoquée au dessus, le front dev arrive à se passer de tests, et donc, il en fait peu et donc n'apprend pas à en faire 😅 Et donc c'est compliqué, et paf, une nouvelle excuse ! Faut avouer aussi que ça ne s'apprend pas en claquant des doigts de déterminer quoi tester, comment le tester, savoir délimiter la portée de son test, savoir ce qu'est un mock, comment l'écrire, etc.

Parce que je suis le seul dev !!!!

Bah je dois déjà m'occuper tout seul de l'intégration, du SEO, de l'architecture front et puis aussi aider à l'infrastructure parce que AWS c'est pas si simple que le boss le pensait alors pfiou… je vais pas m'emmerder avec des tests. Oui certes, le jour où je me retrouve face à une régression, je vais encore perdre plus de temps, mais je suis certain que d'ici là on aura enfin embauché quelqu'un pour s'occuper du support !

Parce que je le vaut bien !!!!

C'est bien connu, celui qui teste doute. Moi je code comme un Dieu, j'ai pas besoin de test. J'ai vu mon dev fonctionner dans mon navigateur donc works4me. Si on vient me remonter un bug, c'est probablement parce qu'un autre dev est passé derrière et code moins bien, je vais plutôt aller lui donner des coups de fouets et l'insulter, ensuite, on pourra aller voir pourquoi ça merde sous IE depuis l'ajout de cette nouvelle fonctionnalité.

PARCE QUEEEEEEEEE

Dans les faits, il n'y a que peu d'excuses valables pour ne pas faire de tests. C'est plus naturel pour un développeur d'arrière guichet qui n'a pas beaucoup d'autre moyen pour constater que son code fonctionne. Pour un développeur de guichet, c'est le navigateur qui joue ce rôle et les tests sont une étape supplémentaire à rajouter au worflow qui est déjà très copieux. Cependant, les outils pour mettre en place les tests sont aujourd'hui fournis clé en main à l'aide d'un simple npm i. Il faut s'y mettre et prendre cette habitude. Même si parfois les circonstances font que c'est un peu plus compliqué. Il faut l'assumer et faire tout son possible (en tant que dev et en tant que manager) pour permettre d'améliorer la situation dans les projets futurs.

(le titre est vraiment à chier 😅)

Aujourd'hui, je travaille sur un projet consistant à produire une codebase capable de générer des dizaines de sites très semblables au niveau de la structure mais qui possèdent chacun leurs particularité. Jusqu'à maintenant, ce travail s'est fait essentiellement en forkant le précédent site et donc en produisant des sites jetables très difficiles à maintenir. React m'a aidé à mettre en place des composants configurables à plusieurs niveaux et ainsi à générer un site contenant simplement un composant et une configuration. Ce composant génèrera toutes les pages communes à tous les sites, les routes, etc tout en injectant les composants spécifiques au site. Mais comment arriver à injecter tout ça dans les tréfonds de cet énorme composant ?

Ce que je trouve vraiment très puissant avec React, c'est l'usage quasi illimité qu'on peut faire avec les props. Les props sont les entrées du composant qui vont être utilisées pour générer une sortie. Ces props sont passées au composant lors de son implémentation, mais là où ça devient très puissant, c'est qu'on peut aussi passer ces props par le biais de HOC, des fonctions qui vont se placer de façon transparente au dessus du composant ou alors via la définition des props par défaut (defaultProps). Avec ces 3 outils, on est capable de faire des composants à l'implémentation ultra simpliste mais pourtant très facilement réutilisable ou configurables.

Injection par les props

La grosse difficulté que j'ai pu découvrir lors de l'apprentissage de React est venue de la volonté de vouloir reproduire ce que je connaissais d'autres framework plus proches de la spec des WebComponent. Notamment, mon premier gros pédicode a été de vouloir reproduire des slots pour pouvoir passer plusieurs éléments enfants à mon composant. Quelqu'un avait cherché à faire la même chose et avait obtenu une réponse sur StackOverflow, j'ai donc pensé que c'était légitime de procéder de la sorte. Puis plus tard, j'ai compris qu'il était possible et surtout bien plus pratique de passer des composants directement via les props. Il devenait ainsi possible d'injecter absolument ce qu'on voulait à un composant à condition que celui-ci soit conçu de façon à être à l'écoute de ces injections.

Un autre des défauts que je trouvais à React était sa non séparation du rendu et de la logique dans la plupart des tutos. Et c'est ici que j'ai pu trouver une réponse à cette problématique et concevoir tous mes composants sous la forme de deux fichiers : un index.js et un render.js. Le premier s'occupant de récupérer toutes les données nécessaires à passer au render qui lui n'était qu'une bête fonction retournant directement et sans la moindre logique du VDOM. J'injecte ce render à mon index via les props, ce qui me permet de pouvoir changer le rendu du composant simplement en passant une autre fonction à la prop render de mon composant.

Voici donc le modèle de composant que j'utilise :

// MonComposant/index.js
import React from 'react';

import render from './render';

export class MonComposant extends React.Component {  
  static defaultProps = {
    render,
  };

  render() {
    const { render: Render, ...nextProps } = this.props;
    // On peut ici générer ou altérer des props à passer au render
    const label = 'World';
    const props = {
      ...nextProps,
      // On ajoute ici les props générés à passer au render
      label,
    };

    return <Render {...props} />;
  }
};

export default MonComposant;  

// MonComposant/render.js
import React from 'react';

export const MonComposantRender = ({ label }) => (  
  <p>Hello {label}</p>
);
export default MonComposantRender;  

Premier avantage : on se retrouve avec un modèle de séparation rassurant quand on vient du MVC, le template est à part du code. Mais le second avantage, c'est que cette fonction de rendu devient très facilement remplaçable. Ainsi, je pourrais implémenter mon composant de ces multiples façons pour avoir autant de résultats différents sans toucher au code du composant :

<MonComposant />  
<MonComposant  
  render={({ label }) => (
    <h1>Yo {label}</h1>
  )} />
<MonComposant  
  render={({ prefix, label }) => (
    <h1>{prefix} {label}</h1>
  )}
  prefix="Yo" />
<MonComposant  
  render={HelloComponent} />

Toute la logique est préservée, et je peux même injecter d'autres props à mon render personnalisé via le scope parent.

Je peux aussi utiliser ce modèle pour injecter des composants à mon render tout en facilitant leur modification ou leur mocking. En effet, dans le cas suivant où mon render va implémenter le composant MonHeader, je vais avoir tendance à importer MonHeader dans le render. Ce composant est alors figé dans le marbre, rendant la personnalisation impossible :

// render.js
import React from 'react';  
import MonHeader from './MonHeader;

export default () => (  
  <div>
    <MonHeader />
  </div>
)

Alors qu'il est tout à fait possible d'injecter ce composant via l'index.js et même de le rendre configurable :

// index.js
import React from 'react';  
import MonHeader from './MonHeader;  
import render from './render;

export default class MonComposant extends React.Component {  
  static defaultProps = {
    render,
    HeaderComponent: {
      component: MonHeader,
      title: 'Foo bar',
    },
  };

  render() {
    const { render: Render, HeaderComponent, ...nextProps } = this.props;
    const Header = () => <HeaderComponent.component {...{...HeaderComponent, ...this.props}};
    // Là c'est la version complexe dans le cas où on veut faire transiter directement des props depuis MonComposant jusqu'à HeaderComponent
    // Mais si on veut juste injecter un composant, on peut faire beaucoup plus simplement :
    // const Header = HeaderComponent.component;
    const props = {
      ...nextProps,
      Header,
    };
    return <Render {...props} />;
  }
}

// render.js
import React from 'react';

export default ({ Header }) => (  
  <div>
    <Header />
  </div>
)

// app.js
// Remplace complètement le composant
<MonComposant  
  HeaderComponent={{
    component: CustomHeader
  }} />
// Remplace uniquement la valeur du `title` passé au composant par défaut
<MonComposant  
  HeaderComponent={{
    title="Bar foo"
  }} />
// Remplace uniquement la fonction de render du composant par défaut, qui va donc prendre en props les props par défaut
<MonComposant  
  HeaderComponent={{
    render={({ title }) => <p>{title}</p>},
  }} />

Je peux juste tester mon render.js en lui passant un mock de Header en prop, je peux tester le composant entier en passant aussi un mock de Header en prop, et je peux passer un Header personnalisé si j'ai besoin d'afficher quelque chose de différent dans certains cas.

Configuration par contexte

Maintenant, allons plus loin avec les hoc et context. Le plan pour que mon objectif soit atteint était d'arriver à générer un site avec seulement ceci :

render() {  
  return (
    <SiteComponent
      config={config} />
  );
}

Rien de plus, rien de moins. Cependant, comment faire si sur l'un des sites, on ne veut pas afficher l'avatar dans le cadre des informations utilisateurs de la vue Dashboard accessible depuis la route /dashboard ? Grâce au context, et aux hoc.

Mon composant est accompagné d'un Provider qui se charge de récupérer la configuration et de la ranger dans un Context. Ainsi, chacun de mes composants passe par un hoc withSiteConfig donnant accès à la configuration. Mais j'ai aussi un hoc withAutoConfig(path) prenant en paramètre le chemin vers la configuration du composant. Les props du composant seront alors automatiquement remplies en piochant dans la config passée au Provider.

Ainsi, si je veux personnaliser le composant UserCard de la vue Dashboard, je pourrais implémenter mon site de la sorte :

render() {  
  return (
    <Provider
      config={{
        Dashboard: {
          UserCardComponent: {
            component: CustomUserCard,
          },
        },
      }}>
      <SiteComponent />
    </Provider>
  );
}

ou bien plus simplement :

render() {  
  return (
    <Provider
      config={{
        Dashboard: {
          UserCardComponent: {
            render: ({ user }) => <p>Hello {user.name}</p>,
          },
        },
      }}>
      <SiteComponent />
    </Provider>
  );
}

ou encore plus simplement, si le composant le permet, en modifiant ses props :

render() {  
  return (
    <Provider
      config={{
        Dashboard: {
          UserCardComponent: {
            displayAvatar: false,
          },
        },
      }}>
      <SiteComponent />
    </Provider>
  );
}

Mon composant UserCard, lui, sera implémenté de la sorte :

import React from 'react';  
import { withAutoConfig } from '../config';

export class UserCard extends React.Component {  
  /**/
}

export default  
  withAutoConfig('views.Dashboard.UserCardComponent')(
    UserCard
);

Je ne vous présente pas le code de withAutoConfig, mais en gros son fonctionnement est le suivant : il récupère la config du contexte, les propTypes et les defaultProps du composant passé en paramètre, et pour chaque propType, il va ajouter la valeur correspondant à la prop prise par ordre de priorité dans la config, dans la config par défaut du projet puis dans le defaultProps.

En conclusion de cet article, je voudrais saluer la créativité que permet React. C'est probablement pour cet aspect que je m'y suis plu si rapidement. Il est possible d'architecturer ses projets de pleins de façons différentes, que ça soit par des hocs, par des renderProps, des context, autour de redux, etc. Il n'y a pas qu'un seul modèle à suivre bêtement comme une IA. Avec les effets négatifs qui sont qu'on peut aussi produire un énorme plat de pâtes impossible à maintenir 😅

Waw… quasiment deux ans que je n'ai rien rédigé sur ce blog… Il est temps de rémédier à ça. Avant de repartir sur des posts techniques et classique, je vais juste raconter un peu ma vie concernant ces deux années passées.

En Septembre 2016, je démarrais une nouvelle expérience chez Sport Heroes Group, chez qui j'apportais mes connaissances du framework Aurelia afin de remettre à neuf les architectures vieillissantes de leurs sites, basés sur un AngularJS orchestré par Grunt. J'ai conçu plusieurs sites qui ont pivoté très fréquemment en mode agile extreme grâce à Aurelia. Tout n'a pas été simple, il a fallu forker parfois, et la mutualisation des composants n'a pas pu être faite autrement qu'en dupliquant du code entre projets. Cependant, j'ai réussi à obtenir une base de code commune à plusieurs projets clients et un projet en SaaS, ce qui n'était pas une mince affaire compte tenu des spécificités de chaque projet, tant en terme produit qu'en terme d'hébergement.

Expérience très enrichissante, mais assez épuisante de part le nombre de projets à suivre et maintenir en même temps.

Malgré cela, Aurelia n'a pas su convaincre mon équipe avec qui je travaillais à distance à plein temps. C'est probablement ce point qui m'a empêché de suffisamment éduquer et faire adopter ce framework au reste de l'équipe qui est majoritairement resté fidèle (par la force des délais incompressibles aussi) à AngularJS. Ces mêmes délais qui ne me laissaient que peu de temps pour améliorer l'existant, m'empêchant par exemple de migrer les sites Aurelia à webpack, ce qui nous aurait très probablement permis de mutualiser très simplement des composants entre plusieurs projets.

C'est face à cet objectif non atteint que fut décidé en Décembre 2017 que toute l'équipe se mette à React. React, librairie que j'abhorrais depuis toutes ces années pour des principes relatif au respect des standards du web : syntaxe jsx non standard, pattern fonctionnels très éloignés de ce que j'avais eu l'habitude d'utiliser depuis des années : MVC, MVVM… je préférais utiliser des outils se rapprochant au plus des spécifications des web components : aurelia, évidemment, mais aussi vuejs par exemple. Et donc, j'ai été forcé de développer avec cet outil, finalement bien méconnu de ma part.

Et j'ai adoré.

Cela fait maintenant sept mois que je ne fais plus que du React, mon seul regret sera de ne pas m'y être mis bien plus tôt. Sans pour autant renier mes autres frameworks de prédilection, je reconnais sans soucis pourquoi React a réussi à prendre sa place de leader dans l'univers du développement web. Parmi les avantages que je peux retenir, voici les principaux :

• Réutilisabilité de toutes les parties du code
• Atomisation des composants à l'extreme
• Simplicité à personnaliser des composants grâce aux props et aux infinies façons de les utiliser
• JSX inclus dans Babel : il est plus facile de démarrer un projet React que n'importe quel autre framework
• REACT NATIVE

Évidemment, tout n'est pas rose : React apporte aussi quelques désagrément qu'il faudra détecter le plus rapidement possible pour éviter de générer des tas de legacy impossibles à maintenir. En effet, l'un des arguments qui me poussaient à utiliser Aurelia plutôt que React était la séparation claire entre la logique et les templates html. Quand l'équipe est constituée de développeurs javascript, ce n'est pas un problème. Mais quand des intégrateurs partagent notre dure tâche, ils ont des réflexes tout à fait justifiables qui ne sont pas possible (et même extrêmement dangereux) en react. Ils vont taper dans le DOM, tenter de le manipuler, intégrer des plugins jquery… Mais attention ! L'intégrateur n'est pas le seul à commettre des erreurs. Le développeur expérimenté trouvera aussi des obstacles à affronter. Il sera coupable de produire des composants beaucoup trop complexes ou trop spécifiques. C'est plus un problème général, certes : le soucis de généricité du code est, à mon avis, l'une des plus grosses lacunes des développeurs. Mais la façon dont React permet de résoudre ces problématique quand on comprend son fonctionnement ne donne plus droit à l'excuse.

Vous aurez donc compris que j'ai véritablement retourné ma veste concernant React et que j'ai rejoint cette communauté avec plaisir. C'est mon blog qui n'est pas très content : j'arrive après la bataille et j'ai la sensation qu'il n'y a plus rien à dire. En effet, si j'ai pu progresser sur cette techno aussi rapidement, c'est aussi parce que je n'ai eu aucune difficulté à trouver de la doc et des tutos sur le web. Ainsi, j'ai beaucoup de mal à trouver des sujets à rédiger sur cette thématique sans passer pour un gros noob 😅 Mais j'ai quand même un sujet qui me semble très intéressant qui arrivera dans les prochains jours.
J'espère aussi pouvoir tester d'autres outils dans le prochain poste que je démarrerais dans un futur proche : vuejs, stenciljs, etc.

Bon allez, j'ai des composants à refacto !

Pour déployer une application, il existe pas mal de solutions, mais celle que j'ai trouvé la plus pratique est Capistrano. Seul soucis, c'est du ruby, et quand on est dev fullstack javascript et qu'on veut déployer une app node.js ou simplement une SPA, ça la fout mal de devoir se coltiner du ruby. Heureusement, il existe une alternative en javascript qui offre le même principe de fonctionnement : ShipitJS.

Cet outil va vous permettre de cloner votre dépôt git dans le dossier local de votre choix, d'effectuer des tâches puis enfin d'envoyer sur votre ou vos serveurs les fichiers de votre choix, avec la possibilité de rollback à n'importe quel moment. On pourra alors utiliser les commandes :

shipit <env> deploy

et

shipit <env> rollback

Pour deployer sur l'environnement configuré, puis pour revenir à la version précédente. On pourra créer autant d'environnements que nécessaire.

Alors comment ça marche ?

Installation

On va commencer par installer shipit-cli et shipit-npm. Le premier étant la commande à utiliser et le second, une liste de tâches qui vont s'ajouter à shipit-deploy(inclus dans shipit-cli) et qui permettront de lancer automatiquement npm install. Mais nous le verrons plus loin en détail.

$ npm install --save-dev shipit-cli shipit-npm

Vous pouvez bien entendu installer shipit-cli en global, mais c'est moche, je préfère le garder en local et utiliser npm run pour lancer la commande. Nous le verrons par la suite.

Configuration

Il nous faut maintenant un fichier shipitfile.js à la racine de votre projet dans lequel nous allons configurer ce qui doit être fait.

module.exports = function (shipit) {  
  require('shipit-deploy')(shipit);
  require('shipit-npm')(shipit);

  shipit.initConfig({
    default: {
      repositoryUrl: 'git@github.com:you/yourproject.git',
      workspace: '/tmp/your-project',
      deployTo: '/home/deploy/your-project',
      deleteOnRollback: false,
      keepReleases: 2,
      npm: {
        remote: false
      }
    },
    staging: {
      servers: 'deploy@192.168.33.42',
      branch: 'feature/deploy'
    },
    production: {
      servers: 'deploy@your-project.com',
      branch: 'master'
    }
  });
};

Nous commençons par charger shipit-deploy qui est une liste de tâches pré-configurées pour permettre un fonctionnement à la Capistrano : le dépôt git est d'abord cloné dans un dossier temporaire, puis la branche spécifiée est sélectionnée, puis l'ensemble du dossier est copié sur le serveur distant en gardant les précédentes releases. Le dossier deployTo contient un dossier releases ainsi qu'un lien symbolique nommé current qui pointe vers le dossier dans releases correspondant à la version courante. On peut ainsi spécifier combien de versions précédentes on souhaite garder et facilement revenir à la version précédente en créant un autre lien symbolique.

On charge ensuite shipit-npm qui va se charger de lancer la commande npm install au bon moment.

Il ne reste qu'à configurer les différents paramètres que vous retrouverez dans la doc mais dont les principaux sont les suivants :

• repositoryUrl : indique l'url du dépôt à déployer
• workspace : emplacement du dossier de travail, attention à ne surtout pas indiquer le dossier courant car la première étape est de tout y supprimer. Privilégiez un dossier dans /tmp.
• deployTo: le chemin sur le serveur distant où copier les fichiers.
• deleteOnRollback : est-ce-qu'on supprime la version la plus récente après un rollback ?
• keepReleases : le nombre de versions qu'on garde

Ensuite, on peut surcharger ces paramètres selon les environnements. On va d'abord y spécifier le ou les serveurs où deployer et on peut aussi indiquer la branche à sélectionner. Par défaut, c'est master, mais on peut en choisir une autre pour le staging par exemple.

Une fois tout ça fait, il faut encore configurer son serveur. Tout ce dont il a besoin, c'est d'un user deploy (ou ce que vous voulez finalement, puisque vous pouvez le spécifier au niveau du host) et d'un accès ssh avec clé publique. On met ça en place très facilement :

# useradd deploy -m  

# mkdir /home/deploy/.ssh  
# cat my_id_rsa.pub >> /home/deploy/.ssh/authorized_keys  
# chown -R deploy:deploy /home/deploy/.ssh  
# chmod 700 /home/deploy/.ssh  
# chmod 600 /home/deploy/.ssh/authorized_keys

Si vous pouvez vous connecter d'un simple ssh deploy@myhost.com alors c'est bon.

Et là, vous pouvez deployer d'un simple :

$ ./node_modules/.bin/shipit staging deploy

Ou mieux :

$ npm run deploy-staging

Après avoir ajouté à package.json les scripts suivant :

"scripts": {
    // […]
  "deploy-staging": "shipit staging deploy",
  "rollback-staging": "shipit staging rollback",
  "deploy-production": "shipit production deploy",
  "rollback-production": "shipit production rollback"
}

Tâches personnalisées

Mais il manque encore quelque chose !! Deux cas de figures : le premier : vous avez besoin de lancer une commande de compilation avant d'envoyer sur le serveur distant. Typiquement un gulp export par exemple qui va se charger de générer la version combinée et optimisée de votre application dans un dossier non versionné. Le second cas, c'est quand vous avez besoin de lancer une commande sur votre serveur distant après avoir envoyé les fichier, par exemple un petit forever restart myproject.

Dans les deux cas, il faut d'abord créer une tâche, puis écouter l'évènement correspondant au moment où on veut lancer cette tâche. Il existe deux types de taches : les taches simples et les tâches bloquantes. Le second type permet d'attendre la fin de celle-ci avant de continuer la liste de tâches. On va donc utiliser soit shipit.task(name, taskFn) soit shipit.blTask(name, taskFn).

Lancer une commande en local

On va partir de l'exemple de la tâche gulp export qui génère un dossier export avec la version compilée de l'application. On veut donc lancer cette commande après avoir chargé le projet dans l'espace de travail local. Il s'agit donc de l'évènement fetched. Puisqu'on a chargé shipit-npm, notre tâche se fera après la tâche npm install. Ça tombe bien. Voici notre tâche :

shipit.blTask('jspm:install', () => {  
  return shipit.local(`cd ${shipit.config.workspace} && ./node_modules/.bin/jspm install`);
});
shipit.blTask('gulp:deploy', () => {  
  return shipit.local(`cd ${shipit.config.workspace} && ./node_modules/.bin/gulp deploy`);
});

shipit.local permet donc d'exécuter une commande sur la machine locale. Par défaut, nous sommes situé à l'emplacement où le script shipit staging deploy a été lancé, c'est pourquoi il faut commencer par se déplacer dans l'espace de travail.

Ensuite, on attache notre tâche à l'évenement concerné :

shipit.on('fetched', () => shipit.start(['jspm:install', 'gulp:deploy']));  

Dans la cas d'un client SPA, sans backend, on n'a que le dossier compilé à envoyer, on peut donc utiliser l'attribut dirToCopy dans la configuration de shipit pour spécifier le dossier en question au lieu d'envoyer le dépôt entier.

Lancer une commande à distance

Maintenant que nous avons envoyé notre code sur la machine distante, nous voudrions pouvoir redémarrer le serveur node afin qu'il fonctionne avec la dernière version du code. On va prendre comme exemple l'utilisation de forever qui propose la commande forever restart <name> afin de facilement redémarrer une application node. Nous allons donc créer la tâche suivante :

shipit.blTask('forever:restart', () => {  
  return shipit.remote('forever restart myproject');
});
shipit.on('published', () => shipit.start('forever:restart'));  

Et c'est parti pour du deploy à volonté sur n'importe quel serveur avec accès ssh. Il est même possible de deployer sur du AWS ou de sauvegarder ses bases de données.

Je vous présente la nouvelle interface de Reverb.

Conçue avec le framework Aurelia.io, j'ai pu rapidement reprendre les composants existants dans la précédente itération et ainsi me concentrer sur l'intégration. J'ai ainsi pu m'attarder sur les notions d'animations et rendre l'interface extrêmement fluide et vivante. Elle sera en production dès Mardi 14 Juin, si tout va bien :x

Et bien entendu, vous êtes vigoureusement invité à essayer Reverb !

Animer une application Aurelia est extrêmement simple. Vous pouvez en apprendre pas mal sur la théorie sur le blog de l'auteur mais ici, on va voir comment rapidement mettre en place une animation sur une liste d'éléments.

La première chose à faire est d'activer le plugin aurelia-animator-css dans votre fichier main.js :

export function configure(aurelia) {  
  aurelia.use
  .standardConfiguration()
  .developmentLogging()
  .plugin('aurelia-animator-css');

  aurelia.start()
  .then(() => aurelia.setRoot());
}

À partir de ce moment là, Aurelia va s'intéresser aux éléments comportant la classe au-animate et agir en conséquence. Lorsque l'élément sortira du DOM, la classe au-leave lui sera ajouté, puis la classe au-leave-active et enfin lorque l'animation sera terminée, l'élement sera retiré. Même principe pour l'entrée d'un élément dans le DOM avec au-enter et au-enter-active mais aussi lors de l'ajout ou le retrait d'une classe à un élément. Dans ces deux derniers cas, la transition se fera à l'aide de <nom de la classe>-add et <nom de la classe>-remove.

Vous aurez donc compris qu'avec tout ça, tout ce qu'il reste à faire, c'est écrire la css qui va bien à notre liste.

Commençons par mettre en place notre liste :

view.html

<template>  
<ul  
  class="animated-collection au-stagger">
  <li
    repeat.for="item of items"
    class="au-animate">
    <span
      click.trigger="remove(item)">X</span>
    ${item}
  </li>
</ul>  
</template>  

view.js

export class View {  
  items = ['foo', 'bar'];
  remove(item) {
    this.items.splice(this.items.indexOf(item));
  }
}

styles.css

@-webkit-keyframes swipeRight {
  0%   { -webkit-transform: translate3d(-120%, 0, 0); }
  100%   { transform: translate3d(0, 0, 0); }
}

@keyframes swipeRight {
  0%   { transform: translate3d(-120%, 0, 0); }
  100%   { transform: translate3d(0, 0, 0); }
}

@-webkit-keyframes swipeLeft {
  0%   { -webkit-transform: translate3d(0, 0, 0); }
  100%   { transform: translate3d(-120%, 0, 0); }
}

@keyframes swipeLeft {
  0%   { transform: translate3d(0, 0, 0); }
  100%   { transform: translate3d(-120%, 0, 0); }
}
.animated-collection {
  overflow: hidden;
  padding: 1em;
  margin: -1em;

  -webkit-animation-delay:50ms;
  animation-delay:50ms;
}
.animated-collection>li.au-enter {
  transform: translate3d(-120%, 0, 0);
}

.animated-collection>li.au-enter-active {
  -webkit-animation: swipeRight .4s;
  animation: swipeRight .4s;
}

.animated-collection>li.au-leave-active {
  -webkit-animation: swipeLeft .4s;
  animation: swipeLeft .4s;
}

Et c'est tout.

animated-collection est une classe arbitraire qui me permet de définir le style d'animation pour ma liste. Évidemment, vous pouvez vous en passer si vous préférez utiliser la même animation partout.

Il faudra donc définir les animations activées par .au-enter-active correspondant à l'entrée d'un nouvel élément dans le DOM et .au-leave-active correspondant à sa sortie.
Il faudra aussi penser à définir l'état de départ de l'élément grâce à .au-enter pour que l'animation se passe correctement. Par exemple ici, je fais une translation horizontale, si je n'indique pas que l'élément doit d'abord être caché, alors il apparaitra immédiatement à sa place donc sans animation.

Il reste encore un petit truc, c'est la classe au-stagger appliqué au conteneur. Grâce à cette classe, Aurelia comprend qu'il doit appliquer les animation sur les éléments les uns après les autres plutôt que sur chacun en même temps. Donc selon l'effet que vous voulez afficher, vous pourrez donc soit afficher tous les items en même temps, ou les afficher l'un après l'autre comme sur la vidéo d'exemple.