DEV Community: LcsGa

Introduction au CSS "utile"

LcsGa — Sun, 21 Sep 2025 10:54:29 +0000

Le CSS : un éternel mal-aimé ? 🤔

Depuis des années, j'ai vu d'innombrables développeurs se battre avec le CSS.
On entend souvent qu'il est imprévisible, difficile à maintenir et qu'il mène inévitablement à des solutions de contournement lourdes et peu élégantes.
Mais et si le problème n'était pas le CSS lui-même, mais la façon dont on l'aborde ?

Je suis convaincu que cette frustration repose sur deux erreurs fondamentales.

1. La méconnaissance de ses fonctionnalités

Nombreux sont ceux qui n'exploitent qu'une fraction du potentiel du CSS. On se limite aux propriétés de base et on contourne les difficultés en créant des classes à tout-va, comme en témoigne l'existence d'outils comme BEM.
Cette approche, conduit trop souvent au « class hell » où l'on perd un temps fou à essayer de nommer des éléments, au lieu de s'appuyer sur la richesse native du langage.

La solution ? Plonger dans les fondamentaux :

Sélecteurs et Spécificité : Comprendre comment les sélecteurs fonctionnent (la base même du CSS) permet de cibler des éléments sans surcharger le HTML de classes.
On devrait d'abord penser balises sémantiques, pseudo-éléments, pseudos-classes, et attributs "fonctionnels".
Les classes devraient être un dernier recours, utilisées de manière utilitaire et ciblée (non générique).
Propriétés adaptées au besoin : Certaines sont encore sous-utilisées alors qu’elles simplifient grandement la vie.
L’exemple le plus parlant : centrer une <div>. Il fut un temps où c’était un casse-tête, devenu même un mème sur Internet.
Aujourd’hui on utilise Flexbox partout... quitte à ignorer Grid, pourtant bien plus adapté dans la très grande majorité des cas.

Il en résulte qu'on multiplie les wrappers inutiles, et donc les classes à nommer inutilement.

2. L'absence d'architecture CSS

On pense l'architecture de notre application, mais le CSS est souvent laissé pour compte. Or, le style peut et doit aussi être structuré.

Appliquer les principes SOLID : Oui, les principes de conception logicielle — comme le SRP (Single Responsibility Principle) par exemple — s'appliquent aussi au CSS.
Chaque composant et chaque style devrait avoir une unique raison de changer, facilitant ainsi la maintenance et la réutilisation.
Découper son code : Le CSS d'une application devrait refléter son architecture.
Pour un code plus propre et plus facile à gérer, il est préférable de décomposer son application en petits composants granulaires et de lier le style à chaque composant.
Mieux vaut 10 composants de 100 lignes (bien isolés) qu'un seul de 1000 lignes (où tout dépend de tout) !

Le CSS "utile" : redorer le blason d'un langage laissé de côté

Tandis que le JavaScript, le TypeScript, les frameworks comme Angular, les tests, l'architecture applicative, etc. bénéficient d'une multitude de contenus, le CSS est souvent relégué au second plan.
Il existe bien des articles et tutoriels présentant des fonctionnalités isolées, mais il y a un manque criant d'informations sur la façon de structurer, d'optimiser et de maintenir son code CSS sur le long terme.

Cet article est le premier d'une série qui a pour but de changer cela.
Je veux explorer le CSS "utile" : celui qui vous fait gagner du temps, qui simplifie la maintenance et qui vous donne un contrôle total sur votre design.
Nous verrons comment écrire des sélecteurs sans douleur, adopter les bonnes pratiques d'architecture et découvrir des astuces concrètes.

À l'heure où des solutions comme Tailwind dominent la discussion, je veux montrer que le CSS natif est non seulement une alternative viable, mais souvent une approche bien plus confortable, maintenable et scalable.
C'est en comprenant le cœur du CSS que l'on réalise que les solutions basées sur des utilitaires, le BEM, et d'autres approches similaires, répondent souvent à de fausses problématiques.

Alors, prêt(e) à se réconcilier avec le CSS ?

Angular Signals Don't Replace Observables: Pull vs. Push

LcsGa — Wed, 10 Sep 2025 22:46:16 +0000

Recently, we've seen many developers trying to replace RxJS by creating their own "operators" for Angular's signals. This approach is understandable, but it can lead to subtle errors. To avoid them, it's essential to understand the distinction between two reactivity models: Push and Pull.

Push (Observables): Every Pushed Value Matters

In the Push model, the emitter (the source) is in control. It emits values into an "observable" stream, and each emitted value exists independently. These values are then processed, one by one, by those who are observing them.

Imagine a production line: each part that passes exists independently. If you stand along the line to observe, you'll see every part pass, without exception. If you arrive late, you've simply missed the first few parts. They've been sent, and they aren't waiting for you.

👉 This model is ideal for managing data streams, where every value is important.

Pull (Signals): Only the Last Pulled Value Matters

In the Pull model, the consumer is in control. A value is only of interest when it's explicitly read. The consumer will "pull" the value when they need it. This implies that transient values that are not read are irrelevant.

Imagine a digital display board at a train station. It's constantly updated, showing real-time information about trains. There might be dozens of updates per second, but the traveler only sees the last version displayed when they look up. The intermediate updates don't matter to them. Only the latest version of the board's state is relevant.

👉 Signals are therefore perfect for managing a state where only the latest version matters.

Why Some Operators Make Sense and Others Don't

This distinction between Push and Pull is crucial for understanding why certain operators work with signals and others don't.

✅ What Works: Operating on the Final State

Operators that don't care about the history and only react to the change in the final state will work well with signals. For example, a double operator is perfect for a signal. It simply reads the current value, multiplies it by two, and returns the result. It needs nothing else.

const count = signal(2);
const doubledCount = computed(() => count() * 2);
console.log(doubledCount()); // 4

❌ What Doesn't Work: Needing the History

Operators like filter or take are designed to work with data streams. Adapting them to signals is risky. Why?

The filter trap:

Imagine a signal initialized to 1 (const counter = signal(1)) and a resulting signal (a computed for example) that only keeps even numbers. If you do counter.set(2), then counter.set(3), the resulting signal will never see the value 2. In fact, if you only pull the final value, the signal will only consider the last value, which is 3 (odd), and filter it out. Thus, the result will never be what you expected.

const counter = signal(1);
const evenCounter = computed(() => {
    const value = counter();
    return isEven(value) ? value : undefined;
});

counter.set(2);
counter.set(3);
console.log(evenCounter()); // undefined => instead of 2

Conversely, if the last value is 4, you'll get the false impression that your operator is working correctly.

const counter = signal(1);
const evenCounter = computed(() => {
    const value = counter();
    return isEven(value) ? value : undefined;
});

counter.set(2);
counter.set(3);
counter.set(4);
console.log(evenCounter()); // 4 => tricky result

The take trap:

Similarly, with the same counter signal initialized to 1, if you perform counter.set(2), then counter.set(3), then counter.set(4), a take(3) operator will only consider the last value (4). It will have no idea that the values 1, 2, and 3 ever existed. For it, this is its first (and only) iteration.

In Summary

Signals are optimized for managing the application's state (Pull model), while RxJS is perfect for managing data streams (Push model).

Before using one or the other, ask yourself the following question:

"Do I need to know the history of the data, or does only the latest value matter to me?"

If only the latest value matters, signals are for you. Otherwise, an observable is probably the better solution.

Les Signals Angular ne remplacent pas les Observables : Pull vs Push

LcsGa — Mon, 01 Sep 2025 00:04:22 +0000

Récemment, on voit de nombreux développeurs tenter de remplacer RxJS en créant leurs propres "opérateurs" pour les signals d'Angular. Cette démarche est compréhensible, mais elle peut entraîner des erreurs subtiles. Pour les éviter, il est essentiel de bien comprendre la distinction entre deux modèles de réactivité : Push et Pull.

Push (Observables) : Chaque donnée poussée compte

Dans le modèle Push, l’émetteur (la source) est aux commandes. Il émet des valeurs dans un flux "observable", et chaque valeur émise existe indépendamment. Ces valeurs sont ensuite traitées, une par une, par ceux qui les observent.

Imaginez une chaîne de montage : chaque pièce qui passe existe indépendamment. Si vous vous placez le long de la chaîne pour observer, vous verrez chaque pièce passer, sans exception. Si vous arrivez en retard, vous avez simplement raté les premières pièces. Elles ont été envoyées, mais elles ne vous attendent pas.

👉 Ce modèle est idéal pour gérer des flux de données, où chaque valeur a son importance.

Pull (Signals) : Seule la dernière valeur tirée compte

Dans le modèle Pull, c’est le consommateur qui est aux commandes. Une valeur n’a d’intérêt que lorsqu’elle est explicitement lue. Le consommateur "tirera" la valeur au moment où il en a besoin. Cela implique que les valeurs transitoires qui ne sont pas lues n’ont aucune importance.

Imaginez un tableau d'affichage numérique dans une gare. Il est constamment mis à jour, affichant des informations en temps réel sur les trains. Il peut y avoir des dizaines de mises à jour par seconde, mais le voyageur ne verra que la dernière version affichée lorsqu’il lève les yeux. Les mises à jour intermédiaires ne comptent pas pour lui. Seule la dernière version de l’état du tableau est pertinente.

👉 Les signals sont donc parfaits pour gérer un état dont seule la dernière version compte.

Pourquoi certains opérateurs ont du sens et d'autres non

Cette distinction entre Push et Pull est cruciale pour comprendre pourquoi certains opérateurs fonctionnent avec les signals et d’autres non.

✅ Ce qui fonctionne : opérer sur l'état final.

Les opérateurs qui ne se préoccupent pas de l’historique et réagissent uniquement au changement d’état final fonctionneront bien avec les signals. Par exemple, un opérateur double est parfait pour un signal. Il lit simplement la valeur actuelle, la multiplie par deux et retourne le résultat. Il n’a besoin de rien d’autre.

const count = signal(2);
const doubledCount = computed(() => count() * 2);
console.log(doubledCount()); // 4

❌ Ce qui ne fonctionne pas : avoir besoin de l'historique.

Les opérateurs comme filter ou take sont conçus pour travailler avec des flux de données. Les adapter aux signals est risqué. Pourquoi ?

Le piège de filter :

Imaginez un signal initialisé à 1 (const counter = signal(1)) et un signal résultant (un computed par exemple) qui ne garde que les nombres pairs. Si vous faites counter.set(2), puis counter.set(3), le signal résultant ne verra jamais la valeur 2. En effet, si vous ne tirez que la valeur finale, le signal prendra uniquement en compte la dernière valeur, qui est 3 (impair), et la filtrera. Ainsi, le résultat ne sera jamais celui que vous attendiez.
```
const counter = signal(1);
const evenCounter = computed(() => {
    const value = counter();
    return isEven(value) ? value : undefined;
});

counter.set(2);
counter.set(3);
console.log(evenCounter()); // undefined => instead of 2
```
À l’inverse, si la dernière valeur est 4, vous aurez la fausse impression que votre opérateur fonctionne correctement.
```
const counter = signal(1);
const evenCounter = computed(() => {
    const value = counter();
    return isEven(value) ? value : undefined;
});

counter.set(2);
counter.set(3);
counter.set(4);
console.log(evenCounter()); // 4 => tricky result
```
Le piège de take :

De la même manière, avec le même signal counter initialisé à 1, si vous effectuez counter.set(2), puis counter.set(3), puis counter.set(4), un opérateur take(3) ne prendra en compte que la dernière valeur (4). Il n’aura aucune idée que les valeurs 1, 2 et 3 ont existé. Pour lui, c'est sa première (et unique) itération.

En résumé

Les signals sont optimisés pour gérer l’état de l’application (modèle Pull), tandis que RxJS est parfait pour gérer des flux de données (modèle Push).

Avant d’utiliser l’un ou l’autre, posez-vous la question suivante :

"Ai-je besoin de connaître l’historique des données, ou est-ce que seule la dernière valeur m’importe ?"

Si seule la dernière valeur compte, les signals sont faits pour vous. Sinon, un observable est probablement la meilleure solution.