‍

Origine

Git a été inventé et développé par Linus Torvalds en 2005. Il s’agit un logiciel libre et gratuit permettant aux développeurs de gérer les changements apportés au code au fil du temps. Linus Torvalds c’est aussi le petit génie qui est à l’origine du noyau Linux qu’il a commencé en 1991, donc bien avant Git.

Linux c’est un projet plutôt conséquent et il a donc dû nécessiter l’usage d’un outil de gestion de version. Cet outil, à l’époque, c’est BitKeeper. Le problème de BitKeeper, c’est qu’il s’agit d’un logiciel propriétaire et que toute la communauté qui gravite autour de Linux, elle n’aime pas vraiment les logiciels propriétaires. Alors que BitKeeper n’est déjà pas totalement apprécié par la communauté Linux, ils vont faire une annonce qui va déclencher la colère de toute cette communauté et surtout de Linus Torvalds. Ils vont cesser, du jour au lendemain, d’être gratuit. C’est à ce moment précis que Linus Torvalds décide de développer lui même son propre système de gestion de version du code source et tout comme Linux, ce système sera libre et gratuit.

Système de contrôle de version (VCS)

Git est donc un système de contrôle de version, il permet tout simplement de suivre l’évolution du code au fil du temps, à l’aide de branche, de fichiers et d’opérations sur ces fichiers.

Git est structuré comme suit :

• on y retrouve des fichiers (le code source)
• des branches (correspondant à une arborescence de fichiers)
• et des opérations pour faire évoluer les fichiers dans les branches

Grâce à ces opérations, git permet de savoir qui a touché à quel fichier, à quel moment et comment.

GitHub, GitLab, Bitbucket, etc.

Git est un logiciel qui permet de sauvegarder et de gérer localement l’évolution du code source au fil du temps. GitHub, GitLab, Bitbucket, etc. sont des plateformes (web) qui se servent du logiciel git pour gérer le code source. Les dépôts ne sont alors plus gérer localement mais sur des serveurs distants et permettent donc notamment la collaboration avec plusieurs personnes. Ces plateformes proposent également de nombreuses fonctionnalités de gestion de projets et d’équipes (wiki, affectations de tâches, suivi des problèmes, roadmap, statistiques, etc.).

‍

‍

Les bases

‍

Git Flow

Git Flow est une organisation de travail basé sur la capacité de Git à gérer des branches. Par défaut il existe une branche principale qui s’appelle main (anecdote : anciennement master, ce nom par défaut a changé pour des raisons culturelles, ne plus assimiler la notion de master/slave à l’industrie du développement face aux nombreux cas de racisme dans le monde). Il existe une deuxième branche que nous allons créer et qui sera également considérée comme principale, il s’agit de la branche develop.

Nous avons donc 2 branches principales :

• main (anciennement master), qui représente le code source utilisé sur la production
• develop, qui contient les dernières fonctionnalités dont la phase de développement est terminée

‍

Tout au long du développement du projet, de nombreuses branches seront créées lors du développement des fonctionnalités et des corrections diverses. Ces branches respecteront des conventions de nommages comme suit :

• feature/*, pour les branches de fonctionnalités
• hotfix/* ou bugfix/*, pour les branches de corrections
• refactor/*, pour améliorer la qualité du code

Conventional Commits

Conventional Commits est une spécification dont le but est d’améliorer la lisibilité des commits et l’historique des modifications du code source. À l’aide de ces conventions on peut identifier immédiatement le type, le contexte et l’objectif des modifications apportées au code sur un commit (nota bene : Cela permet aussi d’être compris par des outils automatisé pour générer de la documentation en autres).

‍

Les types de commits les plus utilisés sont :

• feat, développement d’une feature
• fix, correction d’un bug
• refactor, amélioration du code
• test, ajout ou mise à jour de tests
• chore, tâche technique non assimilée à une feature
• remove, revert, style, ci, docs, etc.

‍

Workflow : merge vs rebase

Avec Git Flow on travaille donc sur des branches partant de develop (ou autre) et une fois le travail terminé on met à jour develop pour qu’il ai connaissance des modifications apportées.

Il existe plusieurs façons de ramener les modifications d’une branche vers une autre. On peut utiliser la politique de merge ou bien la politique de rebase. Ces deux méthodes ont des avantages et des inconvénients.

Politique de merge

Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche contient un certain nombre d’opération qui n’existent pas sur la branche d’origine. Le principe de la politique de merge est simple : récupérer les modifications faites sur une branche et les ramener sur une autre branche qui n’a pas connaissance de ces modifications. Ces modifications sont ramenées telles quelles.

Avantages :

• traçabilité totale, l’historique du code source correspond totalement à ce qui a été fait
• résolution des conflits en une seule fois (peut être un inconvénient dans certains cas)

Inconvénients :

• historique du code source vite pollué par des opérations inutiles “wip” ou des opérations qui s’annulent
• historique peu fiable et difficile à debugger
• résolution des conflits en une seule fois (peut être un avantage dans certains cas)

Politique de rebase

Lorsque le travail de développement est terminé sur une branche (de feature, de refactor, etc.), la branche a donc un certain nombre d’opération qui diverge de la branche principale. Lorsqu’on suit une politique de rebase, notre objectif va être de nettoyer ces opérations en les réécrivant jusqu’à avoir le nombre minimum d’opérations pertinentes.  

Avantages :

• historique du code source linéaire et lisible qui peut servir de documentation
• messages de commit clairs et respectant les conventions, plus de “wip”
• plus de commits qui s’annulent et donc une fiabilité de l’historique
• facilité pour revenir en arrière et trouver l’origin d’un bug car l’historique n’est pas pollué
• facilité pour revoir une feature complète, pour la modifier ou l’annuler
• résolution des conflits opération par opération (peut être un inconvénient dans certains cas)

Inconvénients :

• demande une grande rigueur car on réécrit en permanence l’historique
• demande une bonne communication ou des règles précises si on travaille en équipe sur la même branche
• la réduction d’une nombre d’opération au minimum est parfois trop extrême et atténue la clarté du contexte dans certains cas
• résolution des conflits opération par opération (peut être un avantage dans certains cas)

‍

Nettoyage avec rebase Interactif

Avec la politique de rebase on réécrit l’historique des opérations faites sur le code source. Pour cela on peut utiliser des outils comme GitKraken ou autre, mais on peut également utiliser la commande git rebase interactive.

Les rebases réécrivent l’historique et donc écrasent totalement ce qui existait avant. En équipe il est donc indispensable de bien communiquer, de bien se mettre à jour et de prendre le soin de ne pas travailler sur la même branche. Si ces règles ne sont pas respecter, les pertes de code sont plus que probables !

Le processus classique de développement pour ne pas rencontrer de problèmes et profiter de la puissance du rebase est le suivant (en plus  :

• travailler en local en faisant autant d’opérations que nécessaires
• lorsque le travail est terminé et que tout fonctionne comme il faut, créer une pull request et demander une revue de code en gardant l’historique de code tel qu’il est pour garder du contexte et donner à l’auteur de la revue de code un moyen de comprendre le cheminement de pensé qui a amené à ces modifications
• une fois la revue de code terminée et acceptée, il faut utiliser le rebase interactive pour nettoyer le code et ne garder que les opérations nécessaires
• intégrer les modifications sur la branche d’origine et supprimer la branche créée précédemment

‍

‍

🧑💻 Démonstration

Supposons nous avons un dépôt git avec une seule branche main et un seul fichier hello.ts qui contient une fonction “Hello World !” comme suit :

Maintenant, nous devons développer la fonctionnalité “Good Bye World!”.

Pour cela, nous allons donc commencer par créer une branche qui respecte les conventions de nommage : git checkout -b feature/good-bye
Puis, nous allons créer un fichier good-bye.ts et écrire la fonction suivante :

Et nous allons créer un commit contenant cette fonctionnalité : git commit -m “feat: good bye world”.

Vous l’avez peut-être remarqué, une erreur s’est glissée dans la fonction, nous allons donc faire un commit pour la corriger :

Avec le commit suivant : git commit -m “fix(good-bye): typo”.

Nous avons donc 2 commits alors qu’il serait plus pertinent d’en avoir qu’un seul. Nous allons donc utiliser le git rebase interactive pour réécrire l’historique des modifications.

‍

Pour initialiser le rebase interactive on utilise la commande suivante : git rebase interactive HEAD~2‍

Cette commande va ouvrir l’interface suivante :

Sur cette interface on voit les 2 derniers commits de mon dépôt git (parce qu’on a utilisé HEAD~2). On y retrouve également une documentation des commandes qu’on peut utiliser devant l’identifiant de chaque commit.

Dans notre cas, on veut fusionner les modifications du deuxième commit avec le premier commit. C’est donc la commande fixup qui nous intéresse, nous allons donc remplacer pick devant le commit fix(good-bye): typo par fixup.

On enregistre et on obtient l’historique suivant (un seul commit) :

7f077f4 (HEAD -> feature/good-bye-world) feat: good bye world

‍

Liens utiles

• https://wikipedia.org/wiki/Linus_Torvalds
• https://wikipedia.org/wiki/BitKeeper
• https://wikipedia.org/wiki/Git
• https://git-scm.com/book/
• https://nvie.com/posts/a-successful-git-branching-model/
• https://www.conventionalcommits.org/en/v1.0.0/
• https://ray.so
• https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase

‍

‍

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.

‍

Dans le domaine de la gestion des données, le choix entre Hard Delete et Soft Delete peut avoir un impact significatif sur la sécurité et la récupération des informations. Ces deux méthodes de suppression de données sont essentielles pour les développeurs et les administrateurs de bases de données.

‍

Dans cet article, nous explorerons en détail ce qu'est le Hard Delete et le Soft Delete, leurs avantages respectifs, et comment choisir la meilleure approche en fonction des besoins spécifiques de votre projet. Nous fournirons également des exemples de code source pour illustrer leur mise en œuvre, afin que même les novices puissent comprendre ces concepts fondamentaux.

‍

Comprendre la différence entre Hard Delete et Soft Delete

‍

La gestion des données supprimées est une composante cruciale de toute application ou système de gestion de bases de données. Comprendre les distinctions entre le Hard Delete et le Soft Delete est le point de départ pour prendre des décisions éclairées.

‍

Hard Delete : La Suppression Définitive (h3)

‍

• Le Hard Delete, également connu sous le nom de suppression définitive, signifie que les données supprimées sont éliminées de manière permanente de la base de données.
• Cela signifie qu'une fois que vous avez effectué un Hard Delete, les données sont irrécupérables.
• Exemples de scénarios où le Hard Delete est approprié : suppression de données sensibles ou obsolètes, respect de la conformité légale.

‍

Soft Delete : La suppression réversible

‍

• Le Soft Delete, contrairement au Hard Delete, implique une suppression réversible.
• Les données supprimées sont marquées comme "supprimées" mais restent dans la base de données.
• Cela permet la récupération des données supprimées si nécessaire, offrant une couche de sécurité supplémentaire.
• Utilisation courante du Soft Delete : préservation de l'historique des données, récupération en cas d'erreur de suppression.

‍

En comprenant la différence fondamentale entre le Hard Delete et le Soft Delete, vous pouvez commencer à évaluer quelle méthode convient le mieux à votre projet. La prochaine section examinera les avantages de chacune de ces méthodes pour vous aider à prendre une décision éclairée.

‍

Les avantages du Hard Delete

‍

Le Hard Delete est une méthode de suppression de données qui peut s'avérer essentielle dans certaines situations. Examinons de plus près les avantages qu'il offre :

‍

L'un des principaux avantages du Hard Delete réside dans la sécurité qu'il offre. Lorsque vous effectuez un Hard Delete, les données sont supprimées de manière permanente de la base de données.

Cela garantit qu'aucune trace des données supprimées ne subsiste, réduisant ainsi le risque de divulgation d'informations sensibles.

‍

Dans certains secteurs, comme la santé ou les finances, la conformité légale est cruciale. Le Hard Delete permet de répondre à ces exigences en supprimant irrévocablement les données.

‍

En supprimant définitivement les données, le Hard Delete peut contribuer à améliorer les performances de la base de données en libérant de l'espace et en réduisant la charge de travail du système.

‍

Le Hard Delete simplifie la gestion des données, car il n'est pas nécessaire de gérer un ensemble de données supprimées de manière réversible. Cela peut simplifier les processus de sauvegarde et de restauration.

‍

Pour mieux comprendre la mise en œuvre du Hard Delete, voici un exemple de code SQL montrant comment effectuer une suppression permanente dans une base de données :

‍

Les avantages du Soft Delete

‍

Le Soft Delete, bien que différent du Hard Delete, présente des avantages significatifs dans certaines situations. Examinons en détail les avantages qu'il offre !

L'un des principaux avantages du Soft Delete est la capacité à récupérer des données supprimées par erreur. Les données marquées comme "supprimées" restent dans la base de données et peuvent être restaurées si nécessaire.

‍

Le Soft Delete permet de conserver un historique complet des données, y compris celles qui ont été supprimées. Cela peut être utile pour l'audit, la conformité ou l'analyse des tendances historiques.

‍

En évitant la suppression permanente des données, le Soft Delete offre une couche de protection contre les erreurs humaines, telles que la suppression accidentelle de données critiques.

‍

Lors de la mise en œuvre de nouvelles fonctionnalités ou de modifications de la structure de la base de données, le Soft Delete permet une transition en douceur en conservant les données existantes.

‍

Pour mieux comprendre la mise en œuvre du Soft Delete, voici un exemple de code SQL montrant comment marquer une ligne de données comme "supprimée" sans la supprimer définitivement :

‍

‍

Quand utiliser chacune des méthodes

‍

La décision entre Hard Delete et Soft Delete dépend largement des exigences particulières de votre projet. Voici des conseils pour vous aider à faire le choix approprié :

‍

Choisissez le Hard Delete lorsque la sécurité des données est une priorité absolue. Par exemple, dans les applications de santé ou financières, il est préférable d'opter pour une suppression définitive.

‍

Si la récupération des données supprimées est essentielle, le Soft Delete est la meilleure option. Cela s'applique notamment aux systèmes où les erreurs de suppression peuvent se produire.

‍

Pour respecter les réglementations strictes qui exigent la suppression permanente de données, le choix du Hard Delete est nécessaire.

‍

Si vous avez besoin de conserver un historique complet des données, optez pour le Soft Delete. Cela est particulièrement utile pour l'audit et la conformité.

Si vous souhaitez optimiser la performance de la base de données en réduisant la charge, le Hard Delete peut être plus approprié, car il libère de l'espace.

‍

Envisagez le Soft Delete lorsque vous prévoyez d'introduire de nouvelles fonctionnalités ou des changements structurels dans la base de données, car il permet une transition en douceur.

En évaluant soigneusement les besoins de votre projet en fonction de ces critères, vous pourrez prendre une décision éclairée quant à l'utilisation du Hard Delete ou du Soft Delete. Gardez à l'esprit que dans certains cas, une combinaison des deux méthodes peut également être envisagée pour répondre aux besoins spécifiques de votre application.

‍

Le choix entre Hard Delete et Soft Delete est une décision cruciale dans la gestion des données. Chacune de ces méthodes présente des avantages distincts, et le choix dépend des besoins spécifiques de votre projet.

‍

Le Hard Delete offre une sécurité maximale en supprimant définitivement les données, ce qui le rend idéal pour les applications où la confidentialité et la conformité légale sont essentielles. Cependant, il faut être prudent, car les données sont irrécupérables.

‍

Le Soft Delete, quant à lui, permet la récupération des données supprimées, préservant ainsi un historique complet et offrant une protection contre les erreurs humaines. Il est particulièrement adapté aux systèmes où la récupération des données est une priorité.

‍

Le choix entre ces deux méthodes peut également dépendre des contraintes de performance de votre base de données et de la flexibilité nécessaire pour les futures modifications.

‍

En fin de compte, il n'y a pas de réponse universelle. Il est essentiel d'évaluer les besoins de votre projet et de choisir la méthode qui répond le mieux à ces exigences spécifiques. Dans certains cas, une combinaison des deux méthodes peut également être envisagée pour une gestion des données supprimées plus complète.

‍

Quelle que soit la méthode choisie, la gestion des données supprimées est une composante essentielle de tout système de base de données bien conçu. En comprenant les avantages du Hard Delete et du Soft Delete, vous êtes mieux préparé à prendre des décisions éclairées pour garantir la sécurité et la flexibilité de votre application.

‍

N'hésitez pas à partager vos propres expériences et réflexions sur ce sujet dans les commentaires ci-dessous. La gestion des données supprimées est une discipline en constante évolution, et l'échange d'idées peut bénéficier à l'ensemble de la communauté de développement.

‍