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 :

• [x] Styliser la croix de fermeture
• [x] Supprimer le style du bouton "Y aller" (soulignement)
• [x] Réussir à styliser les icônes existantes en CSS (avec filter() ou autre)
• [x] Uniformiser la liste des détails du lieu :
• [x] 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 :

[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
  ?)
• 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 👍

[kevinvennitti]

Mise à jour en vidéo cette fois :

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

[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.

[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 ;) )

[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 :)