1 seconde : c’est l’intervalle de rafraîchissement retenu pour un compte à rebours affiché avant l’ouverture d’un salon professionnel, un choix qui donne une impression de temps réel sans jamais solliciter le moindre serveur. Un compte à rebours qui défile ainsi capte l’attention d’une façon qu’une simple date écrite en toutes lettres n’obtient jamais.
Ce billet détaille la construction d’un bloc Gutenberg personnalisé affichant un compte à rebours avant une échéance, pour une agence qui organise plusieurs salons professionnels chaque année sur des pages événement distinctes. L’inscription des participants, gérée par un système à part, ne fait pas partie de ce périmètre.
Le besoin exprimé par l’agence
Chaque salon dispose de sa propre page sur le site, avec sa propre date d’ouverture. L’agence souhaitait pouvoir insérer un compte à rebours sur n’importe laquelle de ces pages, en choisissant simplement la date et l’heure cible dans le panneau latéral de l’éditeur, sans jamais toucher au code.
La déclaration de l’attribut de date
Le bloc expose un unique attribut de type chaîne de caractères, au format ISO, réglable via un composant de sélection de date fourni par les composants natifs de l’éditeur :
attributes: {
dateCible: {
type: 'string',
default: '',
},
},import { DateTimePicker } from '@wordpress/components';
<DateTimePicker
currentDate={ attributes.dateCible }
onChange={ ( valeur ) => setAttributes( { dateCible: valeur } ) }
/>Le calcul du temps restant, entièrement côté client
Le calcul lui-même n’a aucune raison de solliciter le serveur : une simple fonction JavaScript, rafraîchie chaque seconde via setInterval, suffit largement à afficher un compteur crédible.
function calculerRestant( dateCible ) {
const diff = new Date( dateCible ).getTime() - Date.now();
if ( diff <= 0 ) {
return null;
}
const jours = Math.floor( diff / ( 1000 * 60 * 60 * 24 ) );
const heures = Math.floor( ( diff / ( 1000 * 60 * 60 ) ) % 24 );
const minutes = Math.floor( ( diff / ( 1000 * 60 ) ) % 60 );
const secondes = Math.floor( ( diff / 1000 ) % 60 );
return { jours, heures, minutes, secondes };
}Ce fragment tourne dans le script de vue du bloc (viewScript), chargé uniquement sur les pages où le bloc est réellement présent, pas sur l’ensemble du site. Aucun appel à une route REST WordPress n’est nécessaire : la seule donnée requise, la date cible, est déjà présente dans le balisage du bloc sous forme d’attribut de donnée.
Gérer l’échéance dépassée proprement
Une fois la date cible atteinte, le compteur ne doit évidemment pas afficher des valeurs négatives. Un texte de repli, réglable lui aussi depuis le panneau latéral, prend le relais automatiquement :
- Un message « Le salon a déjà eu lieu, retrouvez le résumé ici » quand l’échéance est dépassée
- Un lien optionnel vers la page récapitulative de l’événement passé
- Un test systématique de ce cas avant chaque mise en production, souvent oublié
Un détail d’accessibilité à ne pas négliger
Un compteur qui change chaque seconde peut perturber les lecteurs d’écran s’il n’est pas correctement isolé. La zone du compteur reçoit un attribut aria-live="off" plutôt que la valeur par défaut, précisément pour éviter qu’un changement toutes les secondes soit annoncé en continu par la technologie d’assistance ; la date cible complète reste accessible, elle, dans un texte statique adjacent au compteur visuel.
Un compte à rebours qui change chaque seconde reste un gadget si personne ne pense à ce que vit un visiteur utilisant un lecteur d’écran : ce détail se règle en une ligne, mais se pense en amont, pas après coup.
En résumé
Un bloc horloge entièrement côté client, sans aucune sollicitation du serveur, répond bien au besoin d’une agence événementielle qui gère plusieurs pages salon en parallèle. La vraie difficulté ne tient pas au calcul de temps restant, trivial en JavaScript, mais à la gestion soignée de l’échéance dépassée et de l’accessibilité du compteur.
