Améliorations UI des fiches lieu

kevinvennitti

👋

Suite aux échanges sur une nouvelle maquette pour les fiches lieu (accessibles ici sur Figma), voici un tout premier jet d'intégration en CSS directement dans le code de Cartes :

Ce n'est qu'un début, de nombreux points sont encore à traiter :

• Styliser la croix de fermeture
• Supprimer le style du bouton "Y aller" (soulignement)
• Réussir à styliser les icônes existantes en CSS (avec filter() ou autre)
• Uniformiser la liste des détails du lieu :
• Intégrer la première icône de chaque lieu comme icône sur fond bleu dans la liste des lieux :
• Réorganiser les boutons pour tester deux groupes différents : un groupe "Y aller / Appeler / Site web / Envoyer un mail" (actions directes) et un groupe "Favori / Partager" (méta-actions), l'objectif étant d'avoir le meilleur affichage en fonction des données de chaque lieu :

1. kevinvennitti

   Mise à jour disponible ici :

   

   

   

   

   Des questions pour toi @laem :

   • Est-ce souhaitable / possible / préférable que les nouveaux styles que j'expérimente (qui s'intègrent pour la plupart dans un design system partagé entre les éléments) soient regroupés dans une feuille CSS ? Ou je continue en inline ?
   • Est-ce souhaitable / utile de créer de nouveaux composants (pour Mérimée, pour les numéros de téléphone, etc. à la manière de <Address /> ?)
   • J'ai créé un fork (branche "design") : n'hésite pas à me demander si ça t'intéresse de la tester de ton côté un jour 👍
2. kevinvennitti

   Mise à jour en vidéo cette fois :

   https://github.com/user-attachments/assets/4ba02ab5-c89a-41e9-831c-cbe4ca65aa14

3. laem

   Mince je n'avais pas vu ton fork !

   Alors pour le CSS j'ai adopté des principes qui me semble optimaux par rapport à tout ce que j'ai testé. Je sais que les opinions diffèrent largement entre les équipes mais personnellement j'apprécie ce mode :

   • 1. pour les composants uniques, la balise css={``} de styled-components est parfaite. Si on créée un composant pour l'instant unique mais qui devrait être réutilisé ailleurs dans le futur, le mettre direction dans 2)
   • 2. des fichiers de style par convention nommés UI.tsx ou MonComposantUI.tsx qui regroupent des définitions export const MonComposantStylé= styled.xx``
   • 3. un style global.css où sont définis les styles très très larges (body, a, h1 etc)

   Cette méthode s'affranchit totalement des class="xx yy" et mise un maximum sur le web sémantique en utilisant la balise adéquate. L'utilisation de paramètres de composants évite la multiplication des classes et donne toute la puissance d'un vrai langage.

4. kevinvennitti

   Ok parfait, ça me va de suivre cette logique ! Je vais modifier en conséquence 👍

   Pareil, quelle est ta logique conditionnelle ?

   a) Conditionner l'affichage d'un composant avant son appel dans le code

   {uneVariable && <Composant var={uneVariable}></Composant>}
   

   b) Appeler un composant dans le code sans condition, et conditionner le return s'il y a des données ou pas au sein du composant ?

   Composant.tsx
   
   export function Composant({ var }) {
     if(!var) return
   
     return ( ... )
   }
   

   (Désolé s'il y a des coquilles, message composé sur téléphone ;) )

5. laem

   Bonne question ! Je crois que j'utilise les deux. Je trouve que la deuxième version est plus sympa quand on calcul une variable d'affichage (var = var1 || var2 && var3 > 29) locale à ce composant, et la première version est meilleure quand ton "unevariable" est locale au composant appelant :)