Design & Développement web - Le topic des canards qui mangent des cookies

[Charmide]

Ca dépend de ta configuration, principalement les options allowJs et noImplicitAny

Yes j'allais le dire. Ca fait plus de sens quand tu te dis qu'il a fallu migrer (les mentalités et les bases de code), un certain laxisme a bien aidé l'adoption.

Par exemple c'était vraiment la purge à un moment quand 80-90% des libs n'avaient pas de déclarations de type, donc soit tu t'amusais à décrire le type de tes librairies toi-même soit tu acceptais qu'une partie du code ne soit pas type safe. Mais ça a pas mal changé ça, maintenant si une lib n'a pas de types c'est probablement une lib suffisamment obscure pour que je ne l'utilise pas, j'en vois quasi plus.

Y'a vraiment 0 raisons de pas faire de typescript ces temps-ci, au pire tu configures pour que ce soit ultra-laxiste et tu codes comme avant, mais même en le faisant exprès y'aura bien des bouts de ton code typesafe et des erreurs que tu verras arriver en avance, et t'auras de l'auto-complétion bien plus sympa.

Perso j'en suis à 90% de code typés et quelques Record<string, any> qui trainent en général, parce que faut pas oublier les racines

[Orhin]

Ca dépend de ta configuration, principalement les options allowJs et noImplicitAny

Ceci.
On active toutes les options strict dans un vrai projet TS.

Pour la discussion sur le linting/formatage, je vois souvent ESLint et Prettier utilisés de concert, mais j'ai du mal à distinguer les ajouts de Prettier par rapport à un eslint --fix. C'est juste pour ajouter une configuration "opinionated", ou y'a plus?

Prettier et ESLint c'est pas le même type d'outil.

ESLint c'est des règles de code, ça regarde donc le fond (dans le sens "pas le droit de déclarer 2 variables avec le même nom dans le même contexte", "les imports doivent être dans tel ordre", etc).
Prettier c'est du pur formattage de code, ça regarde donc la forme (on indente de telle façon, on met les parenthèse dans tel cas, etc).

D'ailleurs, dans les trucs cons, j'avais fait une interface avec un booléen. Avec une API, je récupère 0 ou 1 (en string). Je pensais qu'en faisant monObjet.monBooleen = Number(resultat), j'aurais true ou false, mais non, j'ai monObjet.monBooleen qui est égal à 0 ou 1

Ben "Number()" c'est un constructeur de... number comme son nom l'indique.
Ce que tu veux faire c'est "monObjet.monBooleen = Boolean(resultat)"

[raaaahman]

ESLint c'est des règles de code, ça regarde donc le fond (dans le sens "pas le droit de déclarer 2 variables avec le même nom dans le même contexte", "les imports doivent être dans tel ordre", etc).
Prettier c'est du pur formattage de code, ça regarde donc la forme (on indente de telle façon, on met les parenthèse dans tel cas, etc).

La frontière devient un peu floue quand on utilise les configurations ESLint je trouve, genre celle-ci. Il y a clairement un job que fait ESLint que Prettier ne peux pas faire, mais l'inverse est-il aussi catégorique?

[Orhin]

La frontière devient un peu floue quand on utilise les configurations ESLint je trouve, genre celle-ci. Il y a clairement un job que fait ESLint que Prettier ne peux pas faire, mais l'inverse est-il aussi catégorique?

Prettier est en général plus efficace que ESLint pour le reformatage, surtout sans avoir besoin d'importer une config de 3km de long avec plein de règles custom.
Après oui, théoriquement tu pourrais recoder Prettier dans ESLint, mais à quoi bon ?

Surtout que t'as pas envies d'appliquer leurs "corrections" aux même moments.
Perso j'ai du reformatage auto de Prettier à chaque fois que je sauvegarde mais le autoFix d'ESLint je préfère l'appliquer manuellement.

[GrandFather]

Personnellement je n'utilise pas TypeScript, j'ai toujours trouvé que ça rendait JS plus verbeux que nécessaire sans apporter de grande plus-value. C'est peut-être un tort, mais pour le type de clients JS que j'écris et le contexte dans lequel je le fais, ça ne m'a pas porté préjudice jusqu'ici, à condition de rester rigoureux.

J'apprécie par contre que le typage se renforce dans PHP au fil des versions. Déjà parce que c'est nécessaire pour automatiser l'injection de dépendances, et aussi parce que ça permet d'éviter quelques vilains pièges liés à la conversion de type si particulière de ce langage...

[deathdigger]

Personnellement je n'utilise pas TypeScript, j'ai toujours trouvé que ça rendait JS plus verbeux que nécessaire sans apporter de grande plus-value. C'est peut-être un tort, mais pour le type de clients JS que j'écris et le contexte dans lequel je le fais, ça ne m'a pas porté préjudice jusqu'ici, à condition de rester rigoureux.

J'apprécie par contre que le typage se renforce dans PHP au fil des versions. Déjà parce que c'est nécessaire pour automatiser l'injection de dépendances, et aussi parce que ça permet d'éviter quelques vilains pièges liés à la conversion de type si particulière de ce langage...

Mais du coup, tu fais comment tes fronts ? en pur HTML/CSS/js ?

[Awake]

Mais du coup, tu fais comment tes fronts ? en pur HTML/CSS/js ?

En ImageMap

[GrandFather]

Mais du coup, tu fais comment tes fronts ? en pur HTML/CSS/js ?

Avec des composants Vue3 et SCSS. Quand je fais un client SPA, ce qui n'est pas systématique, j'y adjoins de la gestion d'état avec Vuex (plutôt Pinia maintenant) et du routage (avec VueRouter). Pour le build, webpack. Il n'est pas obligatoire d'adopter TypeScript pour utiliser des librairies récentes - et heureusement.

[Foksadure]

je ne veux pas devenir le dinosaure qui est le dernier à coder avec Vim sur des technologies de 2000 et un style de code complètement dépassé

https://rosettacode.org/wiki/Rosetta_Code

Rosetta Code is a programming chrestomathy site. The idea is to present solutions to the same task in as many different languages as possible, to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another. Rosetta Code currently has 1,213 tasks, 390 draft tasks, and is aware of 893 languages, though we do not (and cannot) have solutions to every task in every language.

Où on s'aperçoit que certains langages de script haut-niveau ne sont pourtant pas les moins verbeux, ni les plus lisibles.

[Charmide]

[raaaahman]

Surtout que t'as pas envies d'appliquer leurs "corrections" aux même moments.
Perso j'ai du reformatage auto de Prettier à chaque fois que je sauvegarde mais le autoFix d'ESLint je préfère l'appliquer manuellement.

Ben c'est un peu là que je suis perdu... Il ne me semble pas qu'ESLint puisse auto-corriger plus que le formatage, si?

C'est peut-être un tort, mais pour le type de clients JS que j'écris et le contexte dans lequel je le fais, ça ne m'a pas porté préjudice jusqu'ici, à condition de rester rigoureux.

J'ai envie de te dire que c'est un peu pareil pour tout (et surtout PHP). Si tu as l'assurance d'être rigoureux en toutes circonstances, sur la durée de ta journée de travail complète, et de ne bosser qu'avec des gens aussi rigoureux que toi et partageant la même vision des choses... oui techniquement les outils les plus rudimentaires suffisent. Non pas que ta stack soit rudimentaire, mais si tu typais ta gestion d'état par exemple, ça te ferait quand même quelques erreurs qui seraient découvertes à la compilation, tu gagnerais du temps sur le long terme je pense.

[tenshu]

Dis donc c'est pas dingue en ce moment le marché de l'emploi
.
Je me retrouve à devoir changer assez rapidement de job et c'est la première fois que je m'inquiète un peu.

[Orhin]

Ben c'est un peu là que je suis perdu... Il ne me semble pas qu'ESLint puisse auto-corriger plus que le formatage, si?

Ben par exemple, réordonner les imports ou renommer des variables, ça sort du formatage pour moi.

Les règles de base d'ESLint ne vont pas très loin, mais j'ai vu des règles custom aller assez loin.
Techniquement tu peux tout faire si t'écris tes propres règles et leur fonction d'autofix associée.

J'ai envie de te dire que c'est un peu pareil pour tout (et surtout PHP). Si tu as l'assurance d'être rigoureux en toutes circonstances, sur la durée de ta journée de travail complète, et de ne bosser qu'avec des gens aussi rigoureux que toi et partageant la même vision des choses... oui techniquement les outils les plus rudimentaires suffisent. Non pas que ta stack soit rudimentaire, mais si tu typais ta gestion d'état par exemple, ça te ferait quand même quelques erreurs qui seraient découvertes à la compilation, tu gagnerais du temps sur le long terme je pense.

Ben même en étant le plus rigoureux du monde, le typage a quand même un effet d'auto-documentation qui ne peut être que bénéfique sur le long terme.

[raaaahman]

Renommer des variables avec ESLint, mais où va-t-il chercher les noms?

[Charmide]

ChatGPT probablement

[gros_bidule]

Par renommer les variables, j'imagine que l'on parle de corriger la notation ? snake case vs kebab case vs blablabla enfin vous voyez, peut être aussi restreindre le jeu de caractères pour éviter les accents, caractères cyrilliques, asiatiques, émotiones, etc. Vous n'imaginez pas imaginez ce que certaines personnes sont tentées de pousser dans leur code.

[Orhin]

Par renommer les variables, j'imagine que l'on parle de corriger la notation ? snake case vs kebab case vs blablabla enfin vous voyez, peut être aussi restreindre le jeu de caractères pour éviter les accents, caractères cyrilliques, asiatiques, émotiones, etc. Vous n'imaginez pas imaginez ce que certaines personnes sont tentées de pousser dans leur code.

Oui ce genre de chose.
Ça peut être aussi ajouter un suffixe à une variable qui partage le nom d'une autre variable dans le scope parent.
Ou ajouter un prefix/suffix "attendu" en fonction du contexte (genre les noms de classe en xxxComponent ou xxxService en Angular).

[gros_bidule]

Après ça pourrait être rigolo de changer les noms de variables, juste pour enquiquiner.

while (!starCitizen.isReleased) {
    starCitizen.takeYouMoney();
}

Ca montrerait clairement une boucle infinie, aucun doute possible.

[Charmide]

Vous n'imaginez pas imaginez ce que certaines personnes sont tentées de pousser dans leur code.

Sinon peut-être supprimer tout le code qui a été écrit par une personne donnée.. c'est une règle de lint comme une autre après tout

[Orhin]

Sinon peut-être supprimer tout le code qui a été écrit par une personne donnée.. c'est une règle de lint comme une autre après tout

Je suis allé regardé mes stats sur le repo principal où je bosse depuis Aout : +69k, -73k.
Heureusement que je suis pas payé à la ligne de code.

[Anonyme20240202]

C'est sûr qu'avec des package.lock de 30k lignes dans les repos ça va vite

#ilcherchelamerde #vafinirbétonnéaufonddelamer

[Awake]

Canard PC Analytics est en ligne

L'annonce est ici : http://forum.canardpc.com/threads/83...1#post14079984

[Orhin]

Féloches.

J'irais critiquer le code sur le repo front-end après avoir joué un peu avec.

[Awake]

Merci

Je voulais release avant le week end, donc j'ai pas pris le temps de mettre au propre les repos... y'a même pas un petit README :/

[Charmide]

Sur le coup du retour utilisateur relou perso C'est pénible de pas pouvoir middleclick/ouvrir dans une nouvelle tab ces liens là:

[Awake]

Ouais... si React avait un routeur natif on en serait pas là

[Charmide]

Des excuses, des excuses

[Dross]

J'allais te faire la même réflexion : pas de routing dans l'app c'est pas cool.

Mais si tu a utilisé React à la place d'Angular forcément...

[Etheon]

Ca existe encore React tout seul comme ça ? Next.JS ou Remix quand même !

[Orhin]

Ouais... si React avait un routeur natif on en serait pas là

On appelle ça react-router et ça prend 10s à installer.