Version de développement
Cette documentation décrit la version « next » (develop), non encore publiée. Pour la version stable, basculez sur « v5 » dans l'en-tête.
Développement

Composer

API et personnalisation du compositeur de messages de Dodock

Le Composer est le composant d'interface qui permet à l'utilisateur de rédiger et d'envoyer des messages — emails, commentaires ou réponses — depuis le système. Il est utilisé dans la messagerie, les fils de discussion, les fiches avec fil de commentaires, ainsi que par les applications qui s'appuient sur le framework (par exemple Helpdesk pour ses réponses aux tickets).

Il existe deux variantes du Composer :

  • EmailComposer — pour la rédaction d'emails (avec destinataires, objet, pièces jointes).
  • CommentComposer — pour les commentaires dans les fils de discussion.

Les deux partagent la même base technique, les mêmes slots d'extension et la même gestion des états.

Depuis la version v5, le Composer est un composant Vue moderne exposé depuis @dokos/ui/components/Composer. Les applications qui l'utilisent contrôlent l'envoi du message : le Composer ne se charge pas de poster lui-même, il délègue à l'application hôte via la propriété submitting.

API du Composer

Propriétés principales

PropriétéTypeDescription
submittingbooleanActive l'état « envoi en cours » du bouton d'envoi.
loading (bouton Joindre)booleanAffiche un spinner sur le bouton d'ajout de pièce jointe pendant l'upload.
#footerslotZone d'insertion entre le corps (pièces jointes incluses) et la barre d'outils.
recipients (modèle)arrayPré-remplit le cache d'options du champ destinataires avec les noms et avatars connus.

submitting — indiquer l'envoi en cours

Le Composer ne sachant pas quand l'envoi est terminé — c'est l'application hôte qui en a la responsabilité —, la propriété submitting permet de refléter visuellement l'état d'envoi.

Comportement quand submitting = true :

  • le bouton Send affiche un spinner après son libellé ;
  • le bouton devient non interactif (les clics sont ignorés) ;
  • l'attribut aria-busy est positionné sur le bouton pour l'accessibilité ;
  • le raccourci clavier de soumission est suspendu jusqu'au retour à l'état normal.

Associez submitting = true à un libellé plus court sur le bouton, par exemple « Envoi… » ou, comme Helpdesk, « Sending ». L'espace gagné laisse le spinner respirer.

Exemple — cycle d'envoi dans une application hôte

// Pseudo-code côté application (par exemple un client Helpdesk)
async function sendMessage() {
  if (composer.submitting) return  // évite tout double-envoi
  composer.submitting = true
  composer.sendLabel = 'Envoi…'
  try {
    await api.post('/helpdesk/reply', {
      ticket: currentTicket,
      message: composer.body,
      recipients: composer.recipients
    })
    composer.reset()  // efface le corps, les destinataires, les pièces jointes
  } catch (err) {
    // gestion d'erreur — le Composer reste ouvert pour correction
  } finally {
    composer.submitting = false
    composer.sendLabel = 'Send'
  }
}

Le slot #footer est rendu entre le corps du message (y compris les éventuelles pièces jointes) et la barre d'utilitaires (pièce jointe, formatage, envoi). Il permet d'épingler des actions ou des informations que l'application hôte souhaite garder visibles juste au-dessus de la barre d'outils.

Cas d'usage typiques :

  • un panneau de réponses enregistrées (Helpdesk déplace ici son panneau de réponses pré-rédigées) ;
  • une zone d'avertissement (par exemple « Ce message sera envoyé à 5 destinataires ») ;
  • un récapitulatif de configuration (modèle d'email sélectionné, signature active, etc.).

Utilisez #footer plutôt que d'ajouter des éléments autour du bouton Send. Le Composer se charge du positionnement et de la cohérence visuelle (alignement, espacement, masque de défilement).

recipients — pré-afficher les destinataires avec leur libellé

Lorsqu'une application fournit des destinataires au Composer, l'utilisateur ne voit parfois que l'adresse email brute jusqu'à ce qu'une recherche se déclenche et retourne un résultat correspondant. Depuis cette version, les destinataires fournis via le modèle alimentent directement le cache d'options du champ, de sorte que leur nom et leur avatar s'affichent dès le premier rendu.

Ce qui change concrètement :

  • un destinataire pré-chargé avec un libellé (par exemple « Marie Dubois marie@maison-verte.fr») ne montre plus uniquement son adresse brute ;
  • le nom et l'avatar (si disponibles) apparaissent immédiatement, sans attendre un événement de recherche ;
  • les résultats de recherche continuent d'alimenter ce même cache d'options.

Interface

Barre d'outils — alignement sur la bordure du texte

Avant. Le premier bouton de la barre d'outils (généralement le trombone d'ajout de pièce jointe) démarrait légèrement en retrait du bord du texte, ce qui laissait son glyphe à 6 pixels à l'intérieur de la zone du corps.

Maintenant. La barre d'outils s'aligne sur la même ligne de bordure que le corps du message. Le trombone se trouve exactement sur le bord du texte, comme le corps lui-même.

Bouton Joindre pendant l'upload

Avant. Pendant l'upload d'une pièce jointe, le bouton Joindre était simplement désactivé et s'assombrissait, sans indiquer de progression.

Maintenant. Le trombone est remplacé par un spinner qui tourne sur place. Le bouton reste non interactif pendant toute la durée de l'upload. La limite maximale de pièces jointes, si elle est atteinte, continue de désactiver le bouton.

Dégradé en bas du corps

Avant. Le texte du corps défilait directement jusqu'à la barre d'outils, ce qui pouvait couper une ligne en plein milieu au bord inférieur.

Maintenant. Un dégradé de 18 pixels en bas du corps masque proprement le texte qui défile. Il s'agit du même masque que celui utilisé par EmailContent pour les emails tronqués. Le remplissage inférieur propre au corps maintient la dernière ligne lisible lorsque le défilement atteint le bas.

Voir aussi