Button react component dans un button - Javascript/Node.js - Programmation
Marsh Posté le 14-09-2024 à 18:13:00
Hfr n'est plus vivant ?
Marsh Posté le 14-09-2024 à 19:58:42
https://www.youtube.com/watch?v=Meb7uaNlcS0
Spoiler : Désolé mais je n'ai touché 1 semaine à react y'a plusieurs années... |
Marsh Posté le 14-09-2024 à 20:17:34
T'inquiète pas, y'a quelques semaines j'y avais jamais touché
Marsh Posté le 14-09-2024 à 23:26:53
Bon en fait c'était simple, j'ai viré le button final puisque c'était lui qui embriquait le bouzin et générait l'avertissement.
A partir de la un div en role button (voir picocss) et finalement je passe les attributs que je veux à Expand qui se comporte comme un button.
Easy
Marsh Posté le 25-09-2024 à 17:35:25
Salut,
J'ai déjà eu ce souci avec shadcn en imbriquant des composants de type bouton, dans ce cas il faut passer en prop "asChild" sur le parent.
Sinon dans ton cas t'as peut être pas besoin d'imbriquer deux boutons et tu peux le transformer en div.
Marsh Posté le 25-09-2024 à 19:42:09
Oui c'est ce que j'ai fait, ça marche bien et je n'ai plus les problèmes de CSS que j'avais en amont.
Merci pour l'autre suggestion, je suis encore un gros noob en js/njs/react/nextjs
Marsh Posté le 26-09-2024 à 12:55:23
C'est pas moi qui vais te jeter la pierre, je viens de me mettre à Next récemment, entre les routes, les server actions, les composants serveur, client, le ssr, eslint et ts qui chialent en permanence, putain quel joyeux bordel j'ai l'impression de rien maitriser
La j'ai une erreur ts, ça fait 30min que je pige pas
Marsh Posté le 26-09-2024 à 13:11:01
Ouh là TS je touche pas encore, si c'est pour rajouter une couche de complexité, non merci
Honnêtement j'ai même pas foutu ESlint et Prettier pour éviter de me faire galérer
Marsh Posté le 26-09-2024 à 14:23:27
Prettier c'est plutôt pratique et une fois installé t'as pas grand chose à faire.
Et eslint mine de de rien ça reste indispensable (encore que ça dépend de la complexité de ton projet), je crois que serai incapable de coder quoi que ce soit sans ça, même si des fois ça me fait rager, j'essaie cependant ne pas bidouiller les règles
là je me suis forcé à utiliser typescript pour un nouveau projet, car ça fait des mois que je repousse, mais c'est vrai que ça rajoute quand même de la complexité, mais au final ça permet aussi d'éviter bien des erreurs.
Sinon si t'as besoin d'aide sur react / next / tailwind etc. Et l'ecosysteme react de façon plus generale hésite pas, je suis loin d’être un crack mais je connais quelques trucs quand même
Marsh Posté le 26-09-2024 à 15:58:58
Je note, je note
J'ai prévu de passer à Prettier & ESlint mais je voulais pas me charger entre la découverte de Next, JS plus grossièrement, PicoCSS, NextAuth, React...
Et il me tarde de tester Tailwind !
J'utilises pas mal de LLM pour générer du code, je sais pas si tu as testé de ton côté mais ça marche pas mal du tout
Marsh Posté le 26-09-2024 à 16:38:52
Talwind depuis que je me suis mis à tailwind, maintenant dès que je dois toucher/lire du css "vanilla" https://www.youtube.com/watch?v=wLg04uu2j2o avant ça j'étais passé par Sass ensuite CSS Modules et styled components, mais tailwind c'est tellement pratique
Oui j'utilise chat gpt(4o/o1-mini) mais mais je préfère quand même vérifier dans la doc ou stackoverflow quand j’ai un doute car des fois il propose des trucs un peu crado. Surtout quand c'est des techno assez récente genre next 14 etc. il est pas tout le temps à jour
d'ailleurs un très bon plugin que j'utilise avec prettier : https://github.com/tailwindlabs/pre [...] ailwindcss
ça permet d'automatiquement réorganiser les classes tw dans l'ordre recommandé sans avoir à se soucier de ça.
Marsh Posté le 27-09-2024 à 20:10:35
Ah non ils ont pas à jour (Claude 3.5 aussi), ça date d'un an en arrière donc Next13, difficultés sur les API route, etc. Mais ça te fait 80% du boulot si tu l'orientes bien et j'apprends beaucoup avec
Je note pour le plugin tailwind x prettier faut vraiment que j'y passe, prochain projet je l'utilise !
Marsh Posté le 29-10-2024 à 09:57:15
Salut
Je me permets de m'immiscer un peu sur ce topic pour une question.
C'est quoi la plus value de Next.js par rapport à react seul?
(Et merci pour Tailwindcss, je ne connaissais pas)
Marsh Posté le 29-10-2024 à 09:59:58
Je suis noob alors j'ai demandé au LLM o1 preview
Citation : Next.js est un framework basé sur React qui apporte une multitude de fonctionnalités supplémentaires pour faciliter le développement d'applications web modernes. Voici les principales plus-values de Next.js par rapport à l'utilisation de React seul :
|
Marsh Posté le 29-10-2024 à 10:05:26
XaTriX a écrit : Je suis noob alors j'ai demandé au LLM o1 preview |
J'avoue j'ai pas encore ce reflex
mmh pour l'i18n et le routage ca peut être pratique en effet.
Mais j'ai pas l'impression que ce soit très demandé comme framework.
Rarement vu sur des offres d'emploi. Je me trompe?
Marsh Posté le 29-10-2024 à 10:40:55
Je ne sais pas mais je l'ai utilisé parce que c'est souvent utilisé, enfin je crois. J'ai l'impression que les ressources sont conséquentes, en tout cas j'ai voulu utiliser un truc "simple" et plutôt connu parce que j'y connaissais rien à ce language
Pareil avec Tailwind (même si j'utilise PicoCSS), on voit des bootstrap de partout avec NextJS+Tailwind (doit même avoir un npx pour poper les deux d'un coup ?)
Marsh Posté le 29-10-2024 à 13:08:41
fredo3 a écrit : Salut |
Pour faire simple react c'est une librarie, Next.js c'est un framework.
Si tu utilises juste React "seul" tu seras vite limité et tu vas devoir toi même choisir et ajouter dans ton projet tout un tas de libraires, quel routeur, quel bundler, serveur de dev etc. (ce qui déjà n'est pas une mince affaire).
Mais le gros + de Next c'est de pouvoir faire du backend ce que React seul ne peut pas faire.
Il y a aussi des trucs très intéressants comme le SSR & SSG. L’optimisation des images grâce au composant <Image /> de next (que j'aimais pas au début mais que j'utilise constamment désormais)
Mais c'est bien de comprendre les concepts de react et faire un peu de react "vanilla" d'abord, car next utilise react.
Sinon je trouve le système de routage de Next bien foutu et bien plus intuitif et "visuel" que react routeur.
/Ce message n'a pas été généré par un LLM
Marsh Posté le 29-10-2024 à 13:13:00
XaTriX a écrit : [...](doit même avoir un npx pour poper les deux d'un coup ?) |
Oui t'as juste a exécuter "npx create-next-app@latest"
Marsh Posté le 29-10-2024 à 13:23:22
Bonne chance pour obtenir ça en React "vanilla" sans SSR et SSG
(shop next.js sur lequel je bosse)
Marsh Posté le 29-10-2024 à 19:13:29
Merci pour vos réponses
Je vais jeter un coup d'oeil aux tuto
Marsh Posté le 30-10-2024 à 21:12:58
Tu bosses dans le milieu ?
Marsh Posté le 30-10-2024 à 21:22:05
Je suis dev oui.
Mais j'ai toujours fuit le javascript comme la peste
Mais là j'ai plus trop le choix. Faut que je me mette aux front-end.
Marsh Posté le 30-10-2024 à 21:24:01
C'est marrant mais le CSS m'emmerde toujours un peu
Marsh Posté le 30-10-2024 à 22:18:54
fredo3 a écrit : Je suis dev oui. Mais là j'ai plus trop le choix. Faut que je me mette aux front-end. |
T'es pas développeur PHP j’espère
XaTriX a écrit : C'est marrant mais le CSS m'emmerde toujours un peu |
Tailwind a changé ma vie , je sais pas comment je faisais pour faire tout en css vanilla/sass avant
De toute façon CSS vanilla c'est poubelle, c'est clairement impossible à maintenir, hors react avec styled component ou css module, car le css est scopé au composant (ou a l’extrême en passant du css inline mais c'est ultra crado).
Marsh Posté le 30-10-2024 à 22:28:14
Hypp0 a écrit : |
Hypp0 a écrit : |
Ce qui veut dire
Marsh Posté le 31-10-2024 à 00:56:35
En gros chaque composant encapsule et isole son css, et grâce à ça on évite : les problèmes de nommage (l'enfer), on évite aussi les problèmes de spécificité qui se produisent souvent car on sait plus qui target quoi à quel endroit et avec quel force, et on éviter de se retrouver avec des "!important" dégueulasses et les problèmes que ça amène.
En css vanilla tous les sélecteurs sont globaux, tandis que CSS module (par exemple) génère automatiquement des nom de classe uniques à la compilation.
On évite aussi les problèmes de classes qui s'accumulent et dont on ne sait pas si on doit les supprimer ou les modifier sous peine de péter un truc
C'est 1000 fois plus facile à maintenir. En gros le css se retrouve colocalisé avec le composant qui l'utilise
On pourrait s'étendre encore longtemps sur l'enfer d'utiliser du css vanilla dès qu'un projet grossit un peu, putain quand je regarde des anciens projets j'en ai des suées
Sinon perso j'ai testé pas mal de trucs et pour moi tailwind reste le plus pratique/simple/puissant, je veux plus utiliser autre chose
Marsh Posté le 02-11-2024 à 21:22:26
J'ai commencé avec XHTML 1.1 et CSS2 mais alors ce que tu me dis me donne absolument pas envie de faire du CSS voir même du front
Marsh Posté le 02-11-2024 à 22:51:08
Avec des outils modernes le css reste "fun" enfin si on peut dire que le CSS est fun
Et puis flexbox/grid ont apporté beaucoup. Mais clairement écrire du css "vanilla" hors apprentissage, c'est sûr que c'est pas raisonnable.
Après si c'est pour styler une simple page je dis pas, mais si le projet devient un peu sérieux faut oublier.
Et puis surtout il y a aucune difficulté à utiliser tailwind quand on connait le css, la doc est incroyablement bien foutue, il y juste un peu de gymnastique à faire au début pour apprendre les classes/aller regarder la doc et c'est tout.
Marsh Posté le 06-11-2024 à 19:50:43
C'est une fausse impression où Nextjs s'apprend assez vite???
Je regarde des tuto, et oui il y a pas mal de conventions à connaître mais hormis ça, il est facile à apprendre. Cool
Marsh Posté le 07-11-2024 à 12:51:58
Je pense que ça dépend surtout de ton background et de ta connaissance de react. Il y a quand meme bcp de subtilités avec next je trouve.
Mais une fois que t'as compris le syteme de routage, les components client/server, le streaming de components, les server actions. Après pour la partie backend c'est juste du js. Il a aussi tout les api qu'il ont étendu, du genre NextResponse/NextRequest mais que t'es même pas obligé d'utiliser
Donc oui t'as sûrement raison, globalement c'est plutôt facile a apprendre si tu connais déjà js/ts/reactr
Marsh Posté le 07-12-2024 à 08:45:31
Hypp0 a écrit : |
Hypp0 a écrit : |
Tailwind c'est de la merde pour débutant et ça ajoute de la merde dans ton code HTML/JSX ton code devient une soupe de merde
Marsh Posté le 07-12-2024 à 11:41:45
gatsu35 a écrit : |
Faut vraiment être un sacré guignol pour sortir un truc comme ça
N'importe quel projet sérieux utilise une approche utilitaire comme tailwind quand c'est pas tailwind directement.
Explique nous ta méthode qui n'est pas une "methode de merde pour débutant", on t'écoute
Attends j'ai une fenêtre ouverte je regarde, c'est chatpt, ah ok ils utilisent tailwind, surement une petite appli développée par des débutants j'imagine
Marsh Posté le 07-12-2024 à 11:55:56
Hypp0 a écrit : |
Tailwind, c'est bien sur le papier, mais en utilisation, la plupart des gens font de la merde avec, ton HTML n'est plus sémantique mais une couche de caca intergalactique. Les gens oublient qu'on peut avec tailwind factoriser les classes et faire des metaclasse avec des plugins ou autre.
Car bonjour la lisibilité du code :
Code :
|
Alors que la plupart du temps normalement ce genre de truc c'est factorisé dans ton design system.
Et le code devrait plutôt ressembler à un truc comme en BEM
Code :
|
Tailwind c'est très bien pour sortir des MVP mais pour la maintenance dans le temps ça sera le bordel et paie ta sémantique avec ce genre de truc, les gens s'en battent les couilles.
Depuis 2006 je travaille sur ce genre de projet, des Kits CSS et JS avec des composants avec des systèmes de grilles via des lignes et colonnes en utilisant les meilleures techniques de l'époque à chaque période.
On avait déjà des systèmes de Cards, block, row, col, buttons, des carousel et autre composant du genre dans notre Kit D'intégration (bien avant que cela s'appelle un Design System).
Et Evidemment, il y avait une partie de classes utilitaires mais avec des instructions claires qu'il fallait en utiliser le moins possible :
txt-c, txt-r, txt-l (pour le text-align)
mt-xs, ml-lg, etc... pour les marges...
mais voilà on limitait l'usage à des cas pour le formatage de texte pour la séparation des éléments, cela permet de garder une cohérence.
Evidemment avec le temps ce genre de connerie à évolué, et je suis passé sur la création de design system comme on le fait maintenant.
Donc
Marsh Posté le 07-12-2024 à 12:11:35
gatsu35 a écrit :
|
Incompréhensible ton post, tout comme ton affirmation que t'es venu poster avec énormément d'arrogance.
Citation : Tailwind c'est très bien pour sortir des MVP mais pour la maintenance dans le temps ça sera le bordel |
C'est juste une des raisons principale d’utiliser ce genre de système, la maintenabilité, tu racontes vraiment n'importe quoi...
Et ton exemple est bidon et ne résous rien du tout.
En tout cas vas expliquer a open ai, shopify ou autre, que leur système est merdique et que c'est de la merde pour débutant, à mon avis ils ont pas du tout réfléchi au problème
Prôner du css vanilla en 2024, non franchement c'est pas sérieux.
Marsh Posté le 07-12-2024 à 13:14:56
Je penses que gatsu35 a raison mais c'est vrai qu'il a parfois un léger manque de mesure dans ses propos.
Un code html qui ressemble a ça :
Code :
|
C'est nul pacque complétement pas optimisé.
Code :
|
Sera bien mieux avec même une notion de charte graphique générique hérité par chaque page puis des cas particulier (page actu avec une classe sur le body) ou bloc par bloc si on veut splitter certain truc en 3 plutôt que 2 pacque bon, on peut.
Ce n'est pas au html définir l'apparence, c'est le boulot du css...
Un système qui te permettrait de générer des css et des classes "module par module" avec héritage et unicité, ok ce serait plutôt cool, ton truc c'est juste un truc de "fainéant" qui multiplie la taille de ton code html par 4 (et qui ne divise pas ton code css par le même ratio, sachant que la css n'est appelé qu'une fois et ton code html a chaque changement de page).
Ça existe depuis 15 ans et y'a tout un tas de gens qui préfère avoir un framework mais qui génère quand même leur css avec de l'héritage, pacque le html doit rester sémantique et que rien n’empêche le css de s'adapter.
Tu doit changer entre light and dark, un class sur le body.
Tes breaks points sont gérés dans la css, pas avec des barbarismes au niveau de chaque noeud de ton html.
Après si tu est dans un usine à pondre du code (ie des templates pour Wordpress) on est désolé pour toi, mais sache que le css/html ne se limite pas à ce genre d'infamie, va te zenifier sur https://csszengarden.com/
Nan mais je troll (un peu) mais que ce soit plus rapide et simple pour le développeur, je peux l'entendre, mais que ce soit "mieux" ou "state of the art", jamais de la vie...
Désolé pour le walloftext...
Marsh Posté le 07-12-2024 à 15:31:45
Hypp0 a écrit : En gros chaque composant encapsule et isole son css, et grâce à ça on évite : les problèmes de nommage (l'enfer), on évite aussi les problèmes de spécificité qui se produisent souvent car on sait plus qui target quoi à quel endroit et avec quel force, et on éviter de se retrouver avec des "!important" dégueulasses et les problèmes que ça amène. |
Non seulement tout ceci est faux, mais c'est faux de manière fractale : on peut prendre n'importe quelle partie du post, c'est faux On peut dézoomer, c'est faux Prendre une phrase, faux Un mot au hasard, faux
1) Les problèmes de nommage
On voit l'absolue déliquessence intellectuelle chez les « développeur » frontend dans cette incapacité à nommer un élément. Ce n'est pas un enfer, c'est une nécessité. Pour pouvoir communiquer à d'autres personnes (voire à soi-même) un sens, une intention ou encore une structure, savoir nommer est essentiel.
Si tu prend ta diarrhée tailwindienne, que tu la laisses de côté quelques semaines, y revenir va être compliqué : qui fait quoi ? Sans documenter clairement chaque élément, via une classe appropriée, il va falloir avoir systématiquement sous les yeux le site à côté du code... Alors que les tailwindeux nous vante le fait qu'il n'y aurait plus besoin d'avoir le CSS à côté du code HTML. Là c'est pire, il faut la page finale pour comprendre quel élément fait quoi, car il est 100% solidarisé de son affichage.
2) Les problèmes de spécificité
Il n'y a jamais eu de problème de spécificité, une fois que l'on a compris comment elle est calculée ( le score X - Y - Z ). On utilise une classe unique, couplée au système BEM par exemple, et il n'y a plus jamais de soucis.
Ça n'est que lorsqu'on se lance tête baissées sans prendre le temps de réfléchir que l'on se retrouve avec des listes interminables de classes imbitables.
3) L'incapacité de comprendre le contexte
Le plus pénible avec les tailwindars, c'est à chaque fois le prosélytisme qui oublie le contexte. Comme le distait Gatsu, peut-être pour un MVP d'une SPA chiottesque ça pourrait être utile (ce qui est faux, car ce qu'on croit être vite-fait et tempporaire devient vite définitif), pour d'autres cas c'est à proscrire totalement.
Ainsi, j'ai vu un autre dev gober les conneries marketing de tailchiotte, tout ça pour tenter de l'appliquer dans... un WordPress. Avec la moitié des templates et son vomi de classes utilitaires, et bien entendu du CSS presque normal avec les horribles apply à côté, parce que forcément y'avait un WooCommerce en plus, et on ne peut pas réécrire 100% du code HTML pour y mettre ses classes utilitaires insipides.
Je vois même pas l'intérêt, parce que tôt ou tard on va devoir intégrer des composants externes (on va arrêter de réinventer la roue systématiquement), et là comment adapter du code HTML externe à son design-system ?
Bon bref je m'arrête là, mais je crois que je pourrais écrire 5 pages de rant en rajoutant encore le côté ultra-sectaire des tailwindouilles au cerveau en état de pourrisement agravé.
Marsh Posté le 07-12-2024 à 15:52:28
Marsh Posté le 07-12-2024 à 15:55:46
Avouez vous êtes tous chef de projet ?
Marsh Posté le 07-12-2024 à 17:49:18
FlorentG a écrit : |
Mais t'as fait quoi comme projet réel sérieux avec ton système et que tu maintiens/update régulièrement ?
Tu pourrais nous montrer ? Car là tu bombes le torse ok, mais en vrai ça donne quoi ?
Sinon je fais pas du tout de php encore moins de worpress, je sais pas pourquoi tu m'inventes une vie. Je fais du dev fullstack au passage
Et relis ton post, je sais pas qui est le plus matrixé, mais tu suintes la haine. Ta femme est partie avec un dev front end ou quoi ? t'as l'air d'en avoir vraiment gros.
Marsh Posté le 14-09-2024 à 14:52:19
J'utilise NextJS v14 et PicoCSS ( https://picocss.com/ )
Dans mon header et ma nav j'ai un menu en ul li qui affiche des boutons stylisés grâce à picocss.
J'ai ajouté le support jour/nuit avec Toggle.dev https://toggles.dev/ et un ThemeToggle.js :
Et pour mon buton de menu:
ça marche plutôt pas trop mal, j'ai eu des mouises de style avec les bouttons qui partent en couilles et je comprend maintenant :
Expand semble utiliser button quelque part, puis je met button expand dans un button.
Dans la console nav j'ai
hydration-error-info.js:63 Warning: validateDOMNesting(...): <button> cannot appear as a descendant of <button>.
Suivi de tout le chemin pour remonter.
Donc soit je demande à un LLM de me génerer le code en reprenant la partie HTML et import CSS de toggle.dev soit je trouve comment remonter le style button "secondary" à Expand.
Une ou plusieurs solutions ?
---------------
"Xat le punk à chien facho raciste. C'est complexe comme personnage." caudacien 05/10/2020