Découper le travail en front-end : front of front-end et back of front-end

Dimitri Dumont

Développeur front-end

Depuis quelques années, j’ai l’habitude de découper le développement d’un projet front-end en deux parties : la partie UI et la partie des données. J’ai découvert et j’utilise cette pratique avec Baptiste, un développeur front-end freelance avec qui je travaille depuis 4 ans.

L’objectif de cet article est de vous présenter la manière dont on utilise cette pratique et les bénéfices qu’elle peut apporter à vos projets front-end lorsqu'on sépare la partie visuelle de la partie logique. Pour éviter tout malentendu, comprenez bien que cette pratique n’est en aucun cas une obligation ou une pratique à mettre en place dans tous les projets front-end.

Au-delà des préférences de chaque développeur, cette pratique a plusieurs avantages :

• Permettre à des développeurs plus juniors d’intervenir sur des projets : ce développeur pourra travailler uniquement sur la partie UI (ex : créer des composants React et les styliser) tandis qu’un développeur plus expérimenté pourra implémenter la logique via Redux, implémenter l’API, etc.
• Permettre à chaque partie (UI & logique) de travailler indépendamment : dans un premier temps, le développeur qui travaille sur les composants React n’a pas besoin de l’API, ni même de la partie logique. De même pour le développeur qui intègre la partie logique, il n’a pas besoin d’ouvrir son navigateur pour développer les fonctionnalités.
• Permettre à de nouveaux développeurs d’être très vite productifs sans même avoir tout de suite les connaissances sur les règles métiers.
• Elle permet de découper correctement un projet front-end en séparant la logique métier de la partie visuelle.

Elle découle de l’utilisation des bonnes pratiques de développement. Voici les pré-requis pour comprendre l'intérêt de cette méthode de travail :

• principes SOLID
• découpage de la partie visuelle et de la partie logique
• architecture hexagonale en front-end (pas obligatoire)
• un projet avec de la complexité (site e-commerce, SaaS, etc.)

Avant d’expliquer comment mettre en place cette approche, il faut comprendre pourquoi nous en sommes venus à l’utiliser. Si vous êtes développeur, vous devez savoir que les technologies évoluent rapidement, c’est l’une des raisons pour laquelle les langages de programmation, les frameworks et les librairies évoluent également rapidement.

Il y a une dizaine d'années, les sites internet étaient assez simples et étaient principalement développés en HTML et CSS. Puis Javascript a commencé à être utilisé pour dynamiser l’affichage de ces sites internet. Ensuite, Javascript a vu son utilisation évoluer pour mettre à jour dynamiquement des données dans une page web sans avoir besoin de la recharger.

De fil en aiguille, c’est ainsi que nous avons commencé à utiliser des librairies comme React et des frameworks comme Next.js pour développer des sites internet, des applications web et mobiles.

Désormais, la plupart des projets front-end a un minimum de logique. Que ce soit pour gérer des formulaires, gérer des étapes avant l’envoi des données à une API, etc. Les personnes qui pensent que le développement front-end consiste simplement à intégrer des maquettes n’ont pas réellement la connaissance des projets web de nos jours.

Hexa web

Des conseils pour un projet web ?

Nous contacter

Il existe toujours des sites vitrine ou « one page » avec assez peu de logique qui peuvent toujours être développés uniquement en HTML & CSS. Mais la réalité est qu’une grande partie des applications contiennent des fonctionnalités qui impliquent un certain degré de complexité. Par exemple, un site vitrine avec des données statiques n’a pas la même complexité qu’un réseau social avec un système d’abonnement, de modération, de messagerie, etc.

Avec toutes les applications web de nos jours et leurs fonctionnalités, la partie front-end d’une application web est de plus en plus complexe. Il n’est pas rare de voir des centaines de composants React, plusieurs dizaines de hooks, des actions et des reducers Redux, etc. On parle même d’architecture hexagonale, de “DDD”, et de tests en front-end.

Étant donné que les projets front-end sont de plus en plus complexes, il est intéressant de s’assurer de la qualité de code et que chaque modification de ce code ne génère pas de régression. C’est pour cela que de plus en plus de développeurs front-end s’intéressent à l’inversion de dépendances, l’architecture hexagonale et les tests pour développer des projets plus robustes et plus rapidement.

Si vous ne connaissez pas ces sujets, je vous invite à lire nos articles sur l'inversion de dépendances en front-end et l’architecture hexagonale en front-end. Nous proposons notre vision de ces pratiques avec des exemples concrets sur des projets React & Next.js.

En appliquant ces bonnes pratiques dans vos applications web, le découpage de la partie visuelle et des données devient naturel. La partie UI est un des clients de la partie logique, c’est-à-dire que ça peut être des composants React, des composants Vue.js, du simple Javascript, une CLI, etc. Ainsi, même si un seul développeur peut s’occuper de développer les deux parties, il peut être intéressant de partager ce travail entre plusieurs développeurs. C’est également un gain de productivité lorsqu’un développeur intervient sur une partie où il a plus de compétences et de connaissances.

Pour vous donner un exemple, Baptiste a plus d’appétences que moi sur les notions d’UI/UX, d’accessibilité, etc. Tandis que de mon côté, j’ai plus d'appétences sur l’architecture de code, les bonnes pratiques de développement et les tests. Ainsi, lorsqu’on intervient ensemble sur un même projet, on se répartit naturellement les tâches en fonction de nos compétences et de nos appétences.

Afin de vous donner un exemple concret, nous allons voir comment développer une fonctionnalité avec notre méthode de travail sur un projet en Typescript avec React et Next.js. Pour cela, nous allons développer une page qui regroupe une liste d’articles de blog. Ces articles de blog sont récupérés via à une API externe. Cette fonctionnalité est volontairement simple afin de se focaliser sur la méthodologie.

Avec Baptiste, voici comment nous organisons nos projets React et Next.js :

• Un dossier src/app qui contient les pages, layouts et autres éléments liés à Next.js
• Un dossier src/ui qui contient les composants React et le style
• Un dossier src/modules qui contient la logique de notre projet front-end

Le développeur en charge de la partie visuelle va travailler sur la création de la page Next.js ainsi que ses composants. Il va également intégrer le style, ici avec TailwindCSS. Dans des cas plus complexes, il pourrait intégrer des animations et d’autres éléments visuels.

1import { BlogList } from "@/ui/components/blog/blog-list"
2import { Container } from "@/design-system/blog-article/layout/container"
3import { Title } from "@/design-system/blog-article/title"
4import { NextPage } from "next"
5
6const BlogPage: NextPage = () => {
7	return (
8		<Container as="div">
9			<Title>Découvrez nos articles</Title>
10
11			<p className="text-shark-500 text-md mt-4">
12				Nous partageons nos expériences et nos connaissances en tant que
13				développeurs front-end sur les bonnes pratiques de
14				développement, Typescript, React & Next.js
15			</p>
16
17			<hr className="my-10 border-shark-200" />
18
19			<BlogList />
20		</Container>
21	)
22}
23
24export default BlogPage
25

1import { ArticlePreviewItem } from "@/ui/components/blog/article-preview-item"
2import { getBlogPosts } from "@/modules/blog/get-blog-posts.action"
3
4export const BlogList = async () => {
5	const blogPosts = await getBlogPosts()
6
7	return (
8		<div className="space-y-10 pb-8">
9			<div className="grid md:grid-cols-2 gap-10 mb-10">
10				{blogPosts?.map((post, i) => (
11					<div
12						key={i}
13						className="max-md:border-b last-of-type:border-none border-shark-100 pb-8"
14					>
15						<ArticlePreviewItem {...post} />
16					</div>
17				))}
18			</div>
19		</div>
20	)
21}
22

1import { twMerge } from "tailwind-merge"
2import { Avatar } from "@/design-system/blog-article/avatar"
3import Link from "next/link"
4import { BlogPost } from "@/modules/blog/blog.type"
5import Image from "next/image"
6
7type Props = BlogPost
8
9export const ArticlePreviewItem = ({
10	author,
11	description,
12	publicationDate,
13	title,
14	slug,
15	cover,
16}: Props) => {
17	return (
18		<Link href={"/blog/" + slug} className="flex flex-col group">
19			<div className="relative rounded overflow-hidden aspect-video bg-shark-100 mb-3">
20				<Image
21					src={cover ?? "/img/blog/default-article-banner.png"}
22					alt={cover + " cover"}
23					fill
24					className="object-contain"
25					quality={50}
26					sizes="100%"
27				/>
28			</div>
29			<article>
30				<h2
31					className={twMerge(
32						ClashDisplay.className,
33						"word-spacing text-xl font-medium group-hover:text-shark-600 transition-all duration-150 line-clamp-2",
34					)}
35				>
36					{title}
37				</h2>
38				<div className="text-shark-400 text-xs mt-2">
39					{publicationDate}
40				</div>
41				<p className="my-6 text-sm leading-6 text-shark-600 line-clamp-3">
42					{description}
43				</p>
44
45				<div className="flex items-center space-x-4">
46					<Avatar
47						avatar={author.avatar}
48						name={author.name}
49						size={"sm"}
50					/>
51					<div className="space-y-1">
52						<div className="text-sm">{author.name}</div>
53						<div className="text-xs text-shark-500">
54							{author.job}
55						</div>
56					</div>
57				</div>
58			</article>
59		</Link>
60	)
61}
62

Imaginons que le développeur en charge de la partie visuelle intervienne en premier, il peut très bien utiliser de fausses données le temps que l’autre développeur ou lui-même s’occupe de la récupération des articles.

Ainsi, il n’est pas bloqué pour développer cette partie et n’a pas besoin de connaissances et de compétences autres que sur React, TailwindCSS et Next.js.

Pour le développement de la partie logique, nous allons créer une fonction getBlogPosts qui sera utilisée par notre UI, dans des composants React.

1export const getBlogPosts = async () => {
2	const response = await fetch("https://api.example.com/blog-posts")
3
4	if (!response.ok) {
5		throw new Error("Failed to fetch blog posts")
6	}
7
8	const blogPosts = await response.json()
9
10	return blogPosts
11		.filter((blogPost) => blogPost.isPublished)
12		.sort(
13			(a, b) =>
14				new Date(b.publicationDate).getTime() -
15				new Date(a.publicationDate).getTime(),
16		)
17}

L’avantage de découper ainsi, c’est que nous n’avons pas besoin d’ouvrir le navigateur pour vérifier si nous récupérons correctement les articles de blog. Grâce aux tests automatiques avec Jest, nous pouvons le vérifier facilement et rapidement sans React.

Hexa web

Des conseils pour un projet web ?

Nous contacter

En adoptant la pratique du "front of front-end" et du "back of front-end", nous facilitons la collaboration entre les développeurs front-end en offrant une plus grande autonomie dans le développement et en accélérant la productivité des nouveaux arrivants.

Cette approche structurée permet de mieux gérer la complexité croissante des applications web, garantissant ainsi des solutions robustes et évolutives.

Comme chaque outil et méthode de travail, elle est à utiliser lorsque c’est nécessaire et selon votre contexte.