Hard Delete vs Soft Delete : que choisir ?

Hola, je vais vous présenter le début d'une nouvelle série d'articles dédiées à la construction d'un projet Web et Mobile en mettant à profit l'Architecture Hexagonale. Durant toute cette série, nous allons explorer comment la logique métier peut être partagée et gérée efficacement à travers différentes plateformes.

‍

Nos objectifs

‍

Nous allons avoir plusieurs objectifs à atteindre au fil de ce projet :

• Apprendre comment développer une application Web et Mobile à la fois en mettant à profit les technologies modernes (Nx, Expo, Remix, Vitest, etc.)
• Comprendre les principes de l'Architecture Hexagonale et comment l'appliquer pour optimiser le partage de la logique métier
• Gagner en compétence et en confiance pour lancer votre propre projet multi-plateforme, tout en développant une base de code propre et maintenable

‍

‍

La structure de la série

‍

Comme je l'ai dis au début de ce premier article, ce projet donnera lieu à une série d'articles qui sera structurée de cette manière :

• Partie 1 (cet article) : présentation du projet et mise en place d'un monorepo avec Nx
• Partie 2 : développer sans UI avec l'Architecture Hexagonale
• Partie 3 : partager de la logique métier et des composants entre le Web et le Mobile
• Partie 4 : refactor serein avec les tests et l'Architecture Hexagonale
• Partie 5 : déploiement Web et Mobile avec Netlify et EAS

‍

Le projet

‍

Le projet qui va nous aider à mettre en avant l'Architecture Hexagonale est un outil de gestion de budget que l'on appellera broney (le bro qui t'aides à gérer ta money 😎). Cet outil sera composé de deux applications, une première, web, développée avec Remix et une deuxième, mobile, développée avec Expo. Nous aurons donc 2 applications React et React Native avec un package TypeScript qui contiendra la logique métier partagée entre ces 2 applications.

‍

Stack

La Stack que j'ai choisi est très subjective, on y trouve quelques frameworks qui mérite selon moi plus de lumière (Remix notamment et Nx face à NextJS et Turborepo). Néanmoins il est important de comprendre que peu importe les frameworks et libraires utilisées, le coeur de l'application sera complètement agnostique et réutilisable dans n'importe quel contexte.

• Monorepo avec Nx
• Application mobile avec Expo
• Application web avec Remix
• Testing avec Vitest
• Style avec Tailwind pour le web et twrnc pour le mobile
• Animation avec Framer Motion pour le web et React Native Reanimated pour le mobile
• Déploiement de l'application web avec Netlify
• Base de données, authentification, etc. avec Supabase
• Formatage du code avec Prettier
• Validation du code avec ESLint
• CI/CD avec les GitHub Actions
• Gestion d'état avec Zustand
• Gestion des formulaires avec React Hook Form
• Validation des types avec Zod
• Logging avec Sentry
• Traductions avec FormatJS
• Utilitaire de date avec date-fns

‍

Fonctionnalités

Pour mettre en avant l'Architecture Hexagonale nous allons avoir besoin de développer quelques fonctionnalités pour avoir de la logique métier. Nous allons nous focus sur les fonctionnalités suivantes :

• Mettre en place le storage : react native mmkv pour le mobile et localStorage pour le web
• Gérer les catégories : lister, ajouter, modifier et supprimer
• Gérer les portefeuilles : lister, ajouter, modifier et supprimer
• Gérer les transactions d'un compte : lister, ajouter, modifier et supprimer
• Authentification avec Supabase
• Dynamiser toute l'app avec Supabase

‍

Modèle de données

Pour mettre en place les fonctionnalités nous allons avoir besoin des entités suivantes :

• Wallet, un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€)
• Category, des catégories servant à préciser le contexte des transactions faites (par exemple on a les catégories "Maison", "Restaurants" et "Divertissements")
• Transaction, les transactions sont liées à un portefeuille et à une catégorie pour savoir où l'argent est transférée (par exemple on a une transaction du portefeuille "Compte Principal Julien" de 50€ sur la catégorie "Restaurants")

‍

Mise en place du monorepo avec NX

‍

Initialisation du projet

Nous allons utiliser les commandes de Nx pour initialiser notre projet.

➜ npx create-nx-workspace@latest

✔ Where would you like to create your workspace? · broney
✔ Which stack do you want to use? · none
✔ Package-based monorepo, integrated monorepo, or standalone project? · package-based
✔ Enable distributed caching to make your CI faster · Yes

Avec cette commande nous avons le projet Nx configuré de base et sans libs pour le moment. Nous allons travailler avec le style Package-Based Repos qui nous offre plus de liberté en limitant le couplage avec Nx si jamais on souhaite changer facilement d'outil de monorepo. Cela permet également d'avoir des node_modules différents pour chaque app ou lib du projet. En savoir plus sur les différents style d'implémentation de Nx.

‍

Création de la lib core

Nous allons maintenant ajouter notre première lib, la plus importante : core. En effet, c'est dans cette lib que nous allons mettre notre Architecture Hexagonale et la logique métier qui sera utilisée par nos applications Web et Mobile.

➜ nx g @nx/js:lib libs/core

✔ Which unit test runner would you like to use? · vitest
✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · rollup

‍

Cette commande nous a généré une lib avec le framework de test Vitest, une config eslint et prettier que l'on peut adapter à nos preferences que je ne détaillerai pas ici.

Il est possible de compiler notre lib avec la commande nx core build et d'executer les tests avec nx core test.

‍

‍

Mise en place de la CI

Maintenant que nous avons les tests setup ainsi que prettier et eslint, il est pertinent de mettre en place une CI pour avoir du feedback régulier sur la bonne tenue du code. Pour la CI nous allons simplement suivre la documentation de Nx et utiliser les GitHub Actions.

Nous allons donc simplement ajouter un fichier .github/workflows/ci.yml assez simple qui peut être étoffé.

name: CI
on:
	push:
	branches:
	- main
	pull_request:

jobs:
	main:
		runs-on: ubuntu-latest
		steps:
			- uses: actions/checkout@v4
				with:
					fetch-depth: 0
			# Cache node_modules
			- uses: actions/setup-node@v3
				with:
					node-version: 20
					cache: 'yarn'
			- run: yarn --no-progress --frozen-lockfile
			- uses: nrwl/nx-set-shas@v4.0.4

			- run: npx nx format:check
			- run: npx nx affected -t lint,test,build --parallel=3

‍

Cette simple CI permet vérifier le bon formatage prettier, d'effectuer les validations eslint et de build et de s'assurer que les tests sont sans erreurs.

‍

‍

Structure du projet

‍

Rentrons plus en détails dans ce que l'on vise comme structure de projet une fois les apps mise en place et notre lib core développée avec l'architecture hexagonale.

- apps

    - mobile : notre application React Native développée avec Expo
    - web : notre application React développée avec React

- libs
    - ui : nos composants React et React Native utilisés par les apps web et mobile
    - tailwind : notre configuration tailwind utilisée par les apps web et mobile ainsi que la lib ui
    - core : notre architecture hexagonale qui contient le coeur de notre application et toute la logique métier réutilisable par les apps web et mobile

‍

Pour aller plus loin, on peut très bien envisager d'avoir une app en plus pour un Storybook.

La lib qui va nous intéresser et la lib core évidemment. Elle sera structurée de cette manière :

- libs
    - core
         - src
              - wallet
                   - tests
                        - wallet.service.test.ts : la logique métier testées
                        - wallet.test.ts : les règles métiers testées
                   - domain
                        - wallet.ts : l'entité qui représente les portefeuilles et qui contient des règles métiers
                        - wallet.repository.ts: le contrat qui détermine comment manipuler l'entité pour lister, ajouter, etc.
                        - wallet.service.ts : le service qui consume une implémentation de contrat‍
                   - infrastructure
                        - in-memory-wallet.repository.ts : une implémentation du contrat
                        - local-storage-wallet.repository.ts : idem
                        - supabase-wallet.repository.ts : idem
                   - user-interface
                        - wallet.store.ts : un store zustand vanilla, utilisable dans n'importe quel environnement javascript et qui sera utilisé dans nos apps
              - category
                   - ...
           - ...

‍

Nous verrons le contenu de chaque fichiers ainsi que les détails du fonctionnement de ces derniers dans le prochain article !

‍

‍

Conclusion

‍

Nous avons terminé le premier article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette première partie nous avons vu comment mettre un place un monorepo et nous avons pourquoi et comment ce monorepo va nous aider à partager la logique métier entre nos différentes applications. Nous avons également bien délimité le périmètre et les fonctionnalités attendues pour notre première version, le MVP, de broney.

Enfin, à la fin de cet article nous avons commencé à entrevoir la structure du projet en mettant en évidence l'Architecture Hexagonale, ce sera le thème de la deuxième partie : Développer sans UI avec l'Architecture Hexagonale.

‍

Si vous développez une application SaaS, un réseau social, une marketplace ou encore une application métier, il est fort probable que vous aillez besoin d’envoyer des e-mails ou des SMS transactionnels à vos utilisateurs.

‍

Si vous vous demandez ce qu’est un message transactionnel, c’est un message automatisé qui fournit aux utilisateurs des informations utiles qui visent à l’aider et améliorer son expérience. Parmi les exemples les plus courants, on retrouve les confirmations de commande, les rappels de rendez-vous et l'authentification à deux facteurs.

‍

L’envoi d’e-mails et de SMS transactionnels avec Laravel est un jeu d’enfant, cette simplicité nous la devons au composant Notifications.

‍

Laravel embarque le support de certains canaux : SMTP, Vonage et Slack. Les développeurs peuvent ensuite intégrer leurs propres canaux et les partager à la communauté sous forme de librairies.

‍

C’est ce que nous avons fait chez Yield Studio en développant des packages pour Brevo, Mailjet et Expo !

‍

Dans ce tutoriel, nous allons vous expliquer étape par étape comment envoyer des e-mails et des SMS transactionnels avec yieldstudio/laravel-brevo-notifier !

‍

Étape 1 : Créer un compte Brevo

Pour commencer, vous devez vous créer un compte sur Brevo et vérifier votre adresse e-mail. Après ça vous pourrez vous rendre sur le tableau de bord.

‍

Le plan Gratuit de Brevo vous permet d’envoyer jusqu’à 300 e-mails par jour, quant au SMS vous devrez charger votre compte avec des crédits SMS, à titre d’exemple le pack de 100 crédits SMS à destination de la France est facturé 4,5€.

‍

Étape 2 : Installer Laravel Brevo Notifier

Après avoir créé votre compte Brevo, nous pouvons continuer l’installation.

composer require yieldstudio/laravel-brevo-notifier

‍

Une fois l'installation terminée, nous pouvons éditer le fichier .env et ajouter les variables suivantes avec vos propres valeurs.

BREVO_KEY=your-brevo-key
BREVO_SMS_SENDER=Yield

# Laravel variables
MAIL_FROM_ADDRESS=hello@yieldstudio.fr
MAIL_FROM_NAME=Yield Studio

‍

La valeur de BREVO_KEY peut être obtenue sur votre tableau de bord dans SMTP et API.

Quant à la valeur de BREVO_SMS_SENDER, elle est limitée à 11 caractères alphanumériques ou 15 caractères numériques. Il s’agit de l’expéditeur que verra votre utilisateur lors de l’envoi SMS (Yield, Amazon, IKEA)

‍

Étape 3 : Authentifier vos expéditeurs

Avec Brevo comme avec de nombreux fournisseurs, les adresses e-mail qui servent à envoyer des e-mails doivent être une adresse authentifiée. Vous pouvez authentifier une adresse e-mail en particulier ou bien directement un nom de domaine.

‍

Vous devez vous rendre dans Expéditeurs, domaines et IP dédiées et ajouter les adresses e-mails ou les domaines qui vous serviront à envoyer des e-mails.

Étape 4 : Générer la Notification

Vous devez ensuite créer une classe pour votre notification, vous pouvez utiliser la commande Artisan ci-dessous, par exemple nous créons une notification OrderShipped

php artisan make:notification OrderShipped

Cette commande génère la classe dans le dossier App\Notifications. Si ce dossier n’existe pas encore, Laravel le créera pour nous.

‍

Étape 5 : Envoyer un e-mail et un SMS

Assurez ensuite vous de changer le retour de la méthode via pour y ajouter notre BrevoSmsChannel  et/ou BrevoEmailChannel

<?php

namespace App\Notifications;

use Illuminate\Notifications\Notification;
use YieldStudio\LaravelBrevoNotifier\BrevoSmsChannel;
use YieldStudio\LaravelBrevoNotifier\BrevoEmailChannel;

class OrderShipped extends Notification
{
    public function via(): array
    {
        return [BrevoSmsChannel::class, BrevoEmailChannel::class];
    } 
}

‍

Vous pouvez ensuite préparer votre notification en ajoutant la méthode toBrevoSms et/ou toBrevoEmail :

<?php

namespace App\Notifications;

use Illuminate\Notifications\Notification;
use YieldStudio\LaravelBrevoNotifier\BrevoSmsMessage;
use YieldStudio\LaravelBrevoNotifier\BrevoEmailMessage;

class OrderShipped extends Notification
{
    public function __construct(private Order $order) {
    }

    // ...
    
    public function toBrevoSms($notifiable): BrevoSmsMessage
    {
        return (new BrevoSmsMessage())
            ->to($notifiable->phone)
            ->content('La commande n°' . $this->order->number . ' a été expédiée.');
    }

    public function toBrevoEmail($notifiable): BrevoEmailMessage
    {
        return (new BrevoEmailMessage())
            ->templateId(1)
            ->to($notifiable->firstname, $notifiable->email)
            ->params(['order_number' => $this->order->number]);
    }
}

‍

Pour envoyer un e-mail transactionnel avec Brevo, vous devez créer des Templates.

‍

Vous pouvez maintenant envoyer votre notification depuis votre controller, un listener ou l’endroit le plus approprié dans votre cas :

<?php

namespace App\Http\Controllers;

use App\Notifications\SendSMSMessageNotification;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

final class MarkOrderAsShipped extends Controller
{
    public function __invoke(Request $request, Order $order)
    {
        // ...
        $request->user->notify(new OrderShipped($order));
        // ...
    }
}

‍

Et voilà vous avez envoyé votre première notification avec Brevo ⚡

‍

Conclusion

Et voila, envoyer un e-mail ou un SMS transactionnel avec Brevo à partir d'une application Laravel c’est relativement simple. Créez d'abord un compte Brevo, installez la librairie yieldstudio/laravel-brevo-notifier, configurez et envoyez votre superbe notification.

‍

Vous pouvez aller encore plus loin en ajoutant des destinataires en copie, des pièces jointes (une facture par exemple) et bien plus.

‍

Sentez-vous libre de tester ce package et d’y contribuer sur Github.

‍

Introduction

‍

En tant que développeurs, nous savons que les projets évoluent constamment : les besoins changent, les designs se métamorphosent et les spécifications initiales peuvent rapidement devenir obsolètes.

Face à cet environnement mouvant, nos composants traditionnels montrent parfois leurs limites. Ils ne sont pas tous adaptés pour faire face de manière flexible et robuste à cette évolution constante.

Qui n'a jamais été frustré par un composant trop rigide pour s'accommoder d'un changement de maquette ou d'une mise à jour des exigences du projet ?

‍

Examinons ensemble, deux exemples, pour illustrer le Design Pattern : Compound Components.

‍

‍

‍

Exemple d’un composant d’UI simple ✏️

Supposons que nous devons créer un composant Card tout ce qu’il y a de plus classique. On a besoin d’affiche un title, une description et un thumbnail.

Voilà une implementation simple de ce que pourrait être ce composant :

// card.tsx

type CardProps = {
	title: string;
	description: string;
	thumbnail: string;
}

function Card({ title, description, thumbnail }: CardProps) {
	return (
		<View>
			<Image source={{ uri: thumbnail }} />
			<Text>{title}</Text>
			<Text>{description}</Text>
		</View>
	)
}

‍

Ainsi que son usage :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
			/>
		</View>
	)
}

‍

Jusque là, tout va bien, notre composant est simple à développer, simple à utiliser et facile à relire.

‍

Maintenant, comme dans tous les projets, le besoin évolue et le design de nos composants avec. Admettons, que notre besoin a évolué de façon à ce qu’on ai besoin d’ajouter un bouton sur notre composant Card. Mais, ce bouton ne doit pas apparaître à tous les endroits de mon application.

‍

Ce que l’on va retrouver dans la plupart des projets professionnels aujourd’hui, c’est une surcharge de propriétés sur le composant. Le plus souvent, notre composant serait comme suit :

‍

// card.tsx

type CardProps = {
	title: string;
	description: string;
	thumbnail: string;
	buttonLabel?: string;
	showButton?: boolean;
	onPressButton?: () => void;
}

function Card({ 
	title, 
	description, 
	thumbnail,
	buttonLabel,
	showButton = false,
	onPressButton
}: CardProps) {
	return (
		<View>
			<Image source={{ uri: thumbnail }} />
			<Text>{title}</Text>
			<Text>{description}</Text>
			{showButton && <Button label={buttonLabel} onPress={onPressButton} />}
		</View>
	)
}

‍


NB : c’est volontairement exagéré pour mettre en avant le problème. Même sans Compound Components que l’on verra après, on pourra avoir un composant bien plus propre !

‍

Et l’usage du composant serait comme suit :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
			/>
			<Card
				title="Lorem ipsum"
				description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				thumbnail="https://picsum.photos/200/300"
				buttonLabel="Lorem"
				onPressButton={() => { /* ... */}}
				showButton
			/>
		</View>
	)
}

‍


Observations

Que peux-tu observer sur cet exemple de composant “traditionnel” qui ne représente que de l’UI ?

‍

1. Structure rigide
   ‍Le composant Card a une structure définie, il contient toujours une image, un titre, une description et un bouton. Il n’y a flexibilité pour changer la structure d’un composant en fonction des besoins.
   ‍
2. Passage de props
   ‍Toutes les données dont le composant Card a besoin sont passées via les props. Cela peut devenir encombrant et difficile à maintenir à mesure que nous ajoutons plus de props au composant.
   ‍
3. Moins de réutilisabilité
   ‍Les sous-composants ne peuvent pas être réutilisés indépendamment. Par exemple, si nous voulons utiliser seulement le bouton ou l'image de la carte dans un autre composant, cela ne serait pas possible.
   ‍
4. Peu extensible
   ‍Ajouter de nouvelles fonctionnalités à la carte nécessite une modification de l'implémentation de la carte elle-même, augmentant potentiellement le risque de créer des bugs non liés.
   ‍
5. Simplicité
   ‍Cependant, dans certains cas, cette approche peut être préférable pour sa simplicité. Si votre composant est très simple et n'a pas besoin des avantages offerts par le pattern de Compound Components, le surcoût en complexité peut ne pas en valoir la peine.

‍

‍

Exemple d’un composant plus complexe ✏️

Supposons maintenant que nous devons créer un composant plus complexe, des composants mêmes, qui ont besoin de travailler ensuite pour mettre en oeuvre une fonctionnalité de Todo-list.

‍

Pour cela, nous allons avoir les composants TodoList (pour afficher une liste d’item de todo), TodoItem (qui représente un item de todo), TodoForm (qui représente le formulaire d’un item de todo) et TodoStats (qui affiche des statistiques pour une liste de todo donnée).

‍

Voilà une implementation de ce que pourrait être ces composants :

‍

// todo-list.tsx

type TodoListProps = {
	todos: Array<{ id: string; content: string }>;
	onPressDelete: (id: string) => void;
}

function TodoList({ todos, onPressDelete }: TodoListProps) {
	return (
		<View>
			{todos.map((todo) => (
				<TodoItem 
					key={todo.id} 
					id={todo.id} 
					content={todo.content}
					onPressDelete={onPressDelete}
				/>
			)}
		</View>
	)
}

// todo-item.tsx

type TodoItemProps = {
	id: string;
	content: string;
	onPressDelete: (id: string) => void;
}

function TodoItem({ id, content onPressDelete }: TodoListItemProps) {
	return (
		<View>
			<Text>{content}</Text>
			<Button label="Delete" onPress={() => onPressDelete(id)} />
		</View>
	)
}

// todo-form.tsx

type TodoFormProps = {
	onPressSubmit: (content: string) => void;
}

function TodoForm({ onPressSubmit }: TodoFormProps) {
	const [value, setValue] = useState<string>('')
	
	return (
		<View>
			<TextInput value={value} onChangeText={setValue} />
			<Button label="Add" onPress={() => onPressSubmit(value)} />
		</View>
	)
}

// todo-stats.tsx

type TodoStatsProps = {
	todos: Array<{ id: string; content: string }>;
}

function TodoStats({ todos }: TodoStatsProps) {
	return (
		<View>
			<Text>Sum of todos: {todos.length}</Text>
			{/* average number of characters */}
			{/* ... */}
		</View>
	)
}

‍


Ainsi que l’usage de ces composants :

‍

// home.tsx

function HomeScreen() {
	const [todos, setTodos] = useState([])
	
	return (
		<View>
			<TodoList 
				todos={todos} 
				onPressDelete={(id) => 
					setTodos((state) => state.filter(todo) => todo.id !== id
				}
			/>
			<TodoStats todo={todos} />
			<TodoForm 
				onPressSubmit={(content) =>
					setTodos((state) => [...state.todos, { id: uuid(), content }])
				} 
			/>
		</View>
	)
}

‍


Observations

Que peux-tu observer sur cet exemple de composant “traditionnel” qui ne représente cette fois une fonctionnalité plus complexe ?

‍

1. Rigidité
   ‍Dans l'état actuel, la structure est assez rigide. Par exemple, si vous voulez une autre variante de TodoItem qui a un bouton pour marquer une tâche comme terminée, ou peut-être une variante de TodoForm qui a des champs supplémentaires, l'adaptation de ces composants à ces scénarios serait plus complexe.
   ‍
2. Passage de props
   ‍Les fonctions de suppression et d'ajout sont transmises en tant que props aux composants enfants TodoItem et TodoForm depuis le composant parent HomeScreen. Cela peut devenir compliqué à gérer à mesure que l'application s'agrandit, car chaque fois que vous voulez utiliser ces fonctions, vous devez les transmettre à travers tous les composants intermédiaires.
   ‍
3. Manque d’encapsulation
   ‍Les composants TodoItem et TodoForm exposent trop de détails d'implémentation. Par exemple, TodoItem a besoin de connaître non seulement le contenu de la tâche, mais aussi son id et comment traiter une action de suppression. De même, TodoForm doit gérer son propre état et savoir comment gérer une action de soumission. Cela pourrait être évité avec une version composée qui masquerait ces détails.
   ‍
4. Peu extensible et peu lisible
   ‍Ce point est suffisamment explicite je pense !

‍

‍

Le Design Pattern : Compound Components 👀

‍

Le Design Pattern : Compound Components s’applique à n’importe quel langage fonctionnant avec des composants et de la gestion d’états. Il s’agit d’une approche qui offre :

‍

1. Structure
   ‍Le terme "Compound Components" décrit une relation "a un" entre les composants. Un composant comporte plusieurs sous-composants qui travaillent ensemble pour former une unité cohérente. Le composant parent sert de composant de mise en page tandis que les sous-composants déterminent le contenu.
   ‍
2. Flexibilité
   ‍Les Compound Components offrent une grande flexibilité dans l'arrangement des sous-composants. Les utilisateurs de cette API de composant peuvent contrôler l'organisation, la structure et la présentation d'un composant.
   ‍
3. Abstraction
   ‍Ils permettent une bonne séparation des préoccupations car chaque sous-composant traite une fonctionnalité particulière. Cela permet une meilleure réutilisation des composants et simplifie le test et la maintenance.
   ‍
4. Pas de passage de props
   ‍Un avantage majeur du modèle de Compound Components est l'évitement du prop-drilling, qui est un problème où des props doivent être passés à travers de nombreux niveaux de composants. Les Compound Components résolvent ce problème en utilisant le contexte React pour partager la valeur entre les composants.
   ‍
5. Encapsulation
   ‍Avec les Compound Components, nous pouvons exposer ce qui est nécessaire et masquer les détails d'implémentation spécifiques. Cela aide à produire un code plus clair et plus facile à maintenir.

‍

Mise en pratique

‍

Maintenant, voyons ensemble un refactor de nos composants précédents en version Compound Components.

‍

‍

Le composant d’UI simple en Compound Components

Reprenons notre composant d’UI simple et convertissons les props title, description, etc. en sous-composants pour en faire une composition comme suit :

‍

// card.tsx

type CardProps = PropsWithChildren

function Card({ children }: CardProps) {
	return <View>{children}</View>
}

Card.Title = CardTitle
Card.Description = CardDescription
Card.Thumbnail = CardThumbnail
Card.Button = CardButton

// card-title.tsx

type CardTitleProps = {	title: string }

function CardTitle({ title }: CardTitleProps) {
	return <Text>{title}</Text>
}

// card-description.tsx

type CardDescriptionProps = {	description: string }

function CardDescription({ description }: CardDescriptionProps) {
	return <Text>{description}</Text>
}

// card-thumbnail.tsx

type CardThumbnailProps = {	source: string }

function Card({ source }: CardThumbnailProps) {
	return <Image source={{ uri: thumbnail }} />
}

// card-button.tsx

type CardButtonProps = {
	label: string;
	onPress: () => void;
}

function CardButton({ label, onPress }: CardButtonProps) {
	return <Button label={label} onPress={onPress} />
}

‍


Et maintenant l’usage :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
			</Card>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
				<Card.Button label="Lorem" onPress={() => { /* ... */}} />
			</Card>
		</View>
	)
}

‍


Observations

Quelles observations peux-tu faire cette fois ci ?

‍

1. Flexibilité
   ‍Le Compound Components donne un plus grand contrôle sur l'organisation des éléments dans le rendu. Dans le deuxième exemple d'utilisation, nous avons de l'information supplémentaire et une absence de bouton, ce qui ne serait pas possible avec une version non composée du composant qui limiterait strictement la structure.
   ‍
2. Réutilisabilité
   ‍Les sous-composants, comme CardTitle, CardImage, et CardContent peuvent être réutilisés et réarrangés librement. Cette approche réduit la duplication du code et accroît la maintenabilité.
   ‍
3. Lisibilité
   ‍Le code est plus facile à comprendre. Alors qu'un composant non composé pourrait avoir un grand nombre de props, ce qui pourrait rendre le code plus difficile à suivre, chaque sous-composant sait clairement quel est son rôle dans le composant de carte.
   ‍
4. Isolation
   ‍Les sous-composants (comme CardButton ou CardImage) peuvent être mis à jour indépendamment des autres sous-composants, évitant ainsi les effets de bord inattendus.
   ‍
5. Scalabilité
   ‍Les nouveaux sous-composants peuvent être ajoutés facilement en suivant cette approche, permettant au composant de s'adapter et de se développer avec le temps. Par exemple, un sous-composant CardFooter pourrait être ajouté si besoin.

‍

Le composant complexe en Compound Components

Enfin, passons au plus intéressant, le groupe de composant qui représente la fonctionnalité de Todo-list, voilà la version Compound Components :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
			</Card>
			<Card>
				<Card.Thumbnail source="https://picsum.photos/200/300" />
				<Card.Title title="Lorem ipsum" />
				<Card.Description 
					description="Quis enim aliqua ad et consectetur laboris reprehenderit ea anim occaecat adipisicing duis exercitation magna cupidatat."
				/>
				<Card.Button label="Lorem" onPress={() => { /* ... */}} />
			</Card>
		</View>
	)
}

‍

Ainsi que son usage, drastiquement simplifiée :

‍

// home.tsx

function HomeScreen() {
	return (
		<View>
			<Todos todos={[]}>
				<Todos.List />
				<Todos.Stats />
				<Todos.Form />
			</Todos>
		</View>
	)
}

‍


Observations

Que peux t-on observer sur cette dernière partie ?

‍

1. Flexibilité d’affichage
   ‍Avec l'approche de Compound Components, la disposition des composants est beaucoup plus flexible. Vous pouvez choisir de rendre Todos.List, Todos.Form, et Todos.Stats dans n'importe quel ordre ou même de ne pas les afficher en fonction des spécificités des spécifications ou des besoins de votre application.
   ‍
2. Utilisation du Contexte
   ‍Grâce à l'utilisation de React Context (TodosContext), vous pouvez facilement partager des données (todos) et des fonctions (add, remove) entre tous les composants enfants. Cela permet d'éviter le problème de prop-drilling propre à l'approche non compound components.
   ‍
3. Hook personnalisé
   ‍Ils utilisent un hook personnalisé useTodosContext pour obtenir les valeurs du contexte. Ce hook rend le code plus lisible et plus facile à utiliser.
   ‍
4. Réutilisabilité accrue
   ‍Les composants sont désormais plus indépendants et peuvent être facilement réutilisés ailleurs dans l'application. Par exemple, Todos.List pourra être utilisé dans un autre écran ou dans une sidebar sans avoir besoin de passer d'informations supplémentaires via les props.
   ‍
5. Extensibilité
   ‍Avec cette approche, vous pouvez également étendre facilement le composant Todos en ajoutant des sous-composants supplémentaires sans bouleverser l'architecture existante. Par exemple, si vous voulez ajouter une fonctionnalité pour marquer les tâches comme faites, vous pourriez créer un nouveau sous-composant Todos.Checkbox.

‍

Le mot de la fin 👋

‍

De manière générale, le composant “traditionnel” est plus simple, mais il offre moins de flexibilité et de potentiel de réutilisation que le Compound Components. Le choix entre les deux approches dépend des besoins spécifiques du projet. Mais de mon experience, partir direct sur du Compound Components est rarement une mauvaise idée !

‍

Les inconvénients potentiels de cette approche sont qu'elle est plus complexe et qu'elle nécessite une compréhension plus approfondie des concepts de React (pour le cas de React), tels que le Contexte et les Compound Components eux-mêmes. De plus, il est important de noter que bien que le Context puisse sembler être une solution à tous les problèmes, il doit être utilisé avec parcimonie pour éviter un couplage excessif entre les composants de votre application.

‍

L'adoption du pattern Compound Components dans la conception d'interfaces utilisateur peut sembler déroutante au début, mais les avantages qu'elle offre en termes de modularité, de flexibilité et de réutilisabilité sont indéniables. Ainsi, en décomposant intelligemment les composants en des sous-éléments logiques, nous pouvons produire des systèmes d'UI flexibles, réutilisables et gérables.

‍

Vous pouvez retrouvez cet article au format vidéo sur YouTube en suivant ce lien.

‍