Atomic design

La notion d’Atomic design a été introduite par Brad Frost. Le constat est le suivant : on ne conçoit pas des pages mais des systèmes de composants. On ne peut plus penser en termes de pages mais plutôt en éléments d’interface qui trouvent leur place au sein d’environnement aussi petit qu’une Apple Watch ou aussi grand qu’un écran 17 pouces.

Le besoin de réfléchir en termes de systèmes de composants est aussi motivé par une volonté d’harmoniser les équipes design et les équipes de dev.

Pour faire court, l’Atomic design peut se voir comme un patron de conception graphique. Il permet entre autres de composer une page à l’aide d’éléments indépendants et réutilisables.

Le principe est simple, par conséquent, nous conserverons cet aspect tout au long de cet article.

La problématique est la suivante, imaginons que les équipes design aient transmis la maquette de page ci-dessous :

Les devs pourraient parfaitement découper la page en 3 :

Similaire au code suivant : https://github.com/olivierGitHub/react-soat/blob/master/src/components/presentation/Presentation.js

Ou bien la découper en 4 :

Code correspondant : https://github.com/olivierGitHub/react-soat/tree/master/src/components/formation

Tout dépendra de l’appétence du dev pour le découpage. Cette question ne se posera pas si les équipes design fournissent aux devs le découpage de la maquette en système de composants.

L’Atomic design se compose de 5 niveaux :

Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. Brad Frost

L’atome

L’atome constitue la plus petite partie d’un élément simple. Il est indissociable et est souvent composé de tag html bas niveau d’un point de vue dev.

Exemple : un bouton

import React from 'react';

function TheButton(props) {
  return (
    <button className="btn btn-info">{props.buttonText}</button>
    )
}

export default TheButton;

La molécule

La molécule se compose principalement de plusieurs atomes. C’est un assemblage d’éléments qui réalise une fonction simple. La molécule, coté dev, peut intégrer des tags html simples. Elle doit déjà être pensée responsive.

C’est-à-dire qu’une molécule permet d’agencer des atomes les uns par rapport aux autres ainsi que par rapport à la molécule elle-même.

Exemple : une recherche (champ de recherche + bouton)

import React from 'react';
import TheInput from '../../atoms/input/TheInput';
import TheButton from '../../atoms/button/TheButton';

function Search(props) {
  return (
      <form className="form-inline">
        <TheInput className="form-control" type="text" placeholder="rechercher" />
        <TheButton buttonText="Recherche" />
      </form>
    )
}

export default Search;

L’organisme

L’organisme est constitué de plusieurs molécules (et accessoirement plusieurs atomes) pour former un élément d’interface plus complexe. L’organisme est une partie de l’interface finale. À l’image des molécules, des tags html simples peuvent en faire partie.

Exemple : la navbar (navigation + recherche)

import React from 'react';
import Navigation from '../../molecules/navigation/Navigation';
import Search from '../../molecules/search/Search';
import './css/navbar.css';

function Navbar(props) {
  return (
        <nav className="navbar navbar-expand-sm navbar-color">
          <div className="container">
            <Navigation />
            <Search />
          </div>
        </nav>
  );
}

export default Navbar;

La différence entre les molécules et les organismes est souvent sujet à débat au sein de l’équipe, en fonction de la complexité de l’élément en question. Disons qu’il existe 3 solutions à cette controverse : la bonne, la mauvaise et la solution de l’équipe 😉

Le template

Le template est constitué de plusieurs organismes afin de donner un aperçu de la page cible. On l’utilise aussi pour tester l’aspect responsive des différents organismes qui le composent.

import React, { Component } from 'react';
import Navbar from '../../organisms/navbar/Navbar';
import Footer from '../../organisms/footer/Footer';
import InfoTypeB from '../../organisms/info-type-b/InfoTypeB';

function TemplateFormation(props) {

  return (
        <React.Fragment>
          <Navbar />
          <InfoTypeB title={props.title}
                    description={props.description}
                    additionalDescription={props.additionalDescription}
                    src={props.src}
                    buttonText={props.buttonText} />
          <Footer />
        </React.Fragment>
      )

}

export default TemplateFormation;

La page

C’est tout simplement l’élément final. La page seule possède les données véritables, venant du serveur. D’un point vue dev, la page représentera le niveau contrôleur qui pourrait par exemple se connecter à un strore (redux) afin de distribuer les datas à ses composants enfants. Elle expose également une majorité des méthodes qui utilisent le serveur (connexion, recherche…)

Le Storybook

Le Storybook est un catalogue référençant tous les composants présents dans l’appli web. Il est très utile lorsque l’on choisit l’Atomic design comme design pattern UI.

Ci-dessous la représentation de la navbar dans le storybook :

import React from 'react';
import { storiesOf } from '@storybook/react';
import Navbar from './Navbar';
import { BrowserRouter, Route } from 'react-router-dom'

storiesOf('Organisms|Navbar', module)
    .addDecorator(cmpnt => (
      <BrowserRouter>
        <Route path="/" component={() => cmpnt()} />
      </BrowserRouter>
    ))
    .add('navbar', () => <Navbar />);

Le storybook s’exécute dans un environnement isolé de l’application. Il est compatible avec React, Angular, Vue… Tous les éléments de l’atomic design doivent y figurer hormis les pages. Ces dernières n’ont pas leur place car le storybook doit rester le plus générique possible.

Doc officielle : https://www.learnstorybook.com/react/en/get-started

Settings en React : https://www.youtube.com/watch?v=va-JzrmaiUM

Quelques exemples de Storybook :

• Grommet : https://storybook.grommet.io/?path=/story/
• Airbnb : https://airbnb.io/react-dates/?path=/story/daterangepicker-drp–default
• Officiel : https://storybooks-official.netlify.com/?path=/story/basics-form-field–field

Retour d’expérience :

Ayant développé 2 petites applications Web identiques l’une après l’autre, une respectant la philosophie Atomic design (+ Storybook) et l’autre sans, voici un “pros VS cons” correspondant à mes observations.

Pros

• Évite la duplication de composants
• Permet de partager la même logique de conception entre les Devs et les UI
• Simplifie la conception et le découpage graphique
• Permet de développer des composants, sans backend, de façon isolée, peu importe la taille de l’application. Le Storybook permet de visualiser l’ensemble des composants rapidement (et avec du live reload)
• Fournit un catalogue de composants, pouvant servir de référence ou de documentation

Cons

• Coût d’entrée élevé niveau code
• Overkill pour les petits projets du fait du nombre de composants

Liens du code :

Avec atomic design :https://github.com/olivierGitHub/react-soat-atomic

Sans atomic design :https://github.com/olivierGitHub/react-soat

By creating design systems, being deliberate in how you construct user interfaces, establishing a collaborative and pattern-driven workflow, and setting up processes to successfully maintain your design system, I hope you and your team can create great things together. Go forth and be atomic! Brad Frost

©SOAT
Toute reproduction interdite sans autorisation de l’auteur