V1 - FaireDesJeux.fr

[goulvenclech]

Après 17 mois en béta, il est temps de commencer sérieusement à s'attaquer à la V1 de FaireDesJeux. Cela va principalement consister en un refactor complet du site, tout en gardant l'aspect visuel et l'organisation actuelle.

Cette pull request sera actualisée au fur et à mesure de l'avancement du projet. Un kanban a également été ouvert, ainsi qu'un tag spécifique pour les issues.

Stack Technique

(work in progress)

• Vue 2 => Vue 3
• Tailwind => Tailwind 2 + JIT
• Gridsome abandonné
• TypeScript adopté
• Vite adopté

[Princesseuh]

Une des fonctions de Gridsome qu'il faudra reproduire c'est le support des transformations pour les images, Gridsome fait ça à travers GraphQL où tu peux mettre diverses options (qualité, taille etc) sur les images que tu query qui sont dans le data store.

Dans l'écosystème Vite, une librairie qui est pas mal aimée pour transformer les images c'est imagetools qui permet de mettre des paramètres sharp directement dans les imports. Je sais pas à quel point c'est utilisable pour nous considérant que nos images viennent de markdown (y'aurait sans doutes moyen de passer par un plugin remark/whatever truc de markdown on utilise) mais je pense que ça serait intéressant à regarder

Cependant, le délire de Gridsome de load les images progressivement avec plein de Javascript à la Medium c'est plus vraiment intéressant en 2021 avec loading="lazy" et decoding="async". On pourrait mettre un placeholder généré automatiquement et load avec les outils natifs quand même cependant. Comme eleventy-high-performance-blog de Google (code ici)

[Princesseuh]

Par-rapport à mon dernier commit (8c59c34), le linting est actuellement très agressif, dans le sens que, le build fail en cas d'erreur de formatting par-exemple 😄

D'un côté, ça ajoute de la friction au développement, puisque ça force à toujours respecter les règles mais, la réalité c'est que la plupart des problèmes rencontrés sont très mineurs et peuvent être corrigé automatiquement par ESLint / Prettier lors de la sauvegarde dans votre éditeur préféré

Pour VS Code par-exemple, il suffit d'installer les extensions (qui sont recommandés par défaut par VS Code grâce au fichier extensions.json) et d'ajouter les options suivantes à son fichier de configuration ou à celui du workspace (.vscode/settings.json):

{
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    }
}

Et voilà, à chaque sauvegarde, la très grande majorité des problèmes rencontrés seront corrigés automatiquement. Magie. Je pense également que c'est bien d'encourager le plus possible ce qu'on considère comme étant les bonnes pratiques

[goulvenclech]

Concernant les styles Tailwind, personellement je suis plutôt contre les remettres dans un plugin, ce n'était pas une erreur si j'ai essayé de mettre au maximum dans les templates + des balises styles. Utiliser un plugin comme l'on faisait avant, c'est beaucoup de side-effects et ça oblige à revenir en permanence dans le fichier config pour vérifier si un style s'y trouve.
Je préfère vraiment adopter complétement le css atomique, en soit effectivement ça va donner de la redondance de code. Mais c'est en fait généralement plus maintenable étant donné que l'on aura plus souvent à modifier un composant que le style global. Et dans tout les cas, en Tailwind la redondance ne créé pas plus de CSS en prod.

[goulvenclech]

Pour l'instant mes points de frictions par rapport à Snowpack/Astro plutôt que Vite :
-> Le fait de ne pas pouvoir importer des packages (pour les fonts ou tailwind) ce qui nous fait dépendre de fonts téléchargées en dur (on peut moins facilement mettre à jour) et de global.css qui est un fichier vide
-> On ne peut pas gérer les images comme on le faisait directement dans les dossiers cours, et ça va rendre la contribution plus compiquée / moins agréable
-> Le serveur dev n'est pas even close aussi agréable que Vite (notamment il crash à la moindre erreur)
-> Ca a l'air méga opinionated, y a l'air de n'y avaoir qu'une manière de faire les choses, Astro semble faire beaucoup de magie "under the hood" et la documentation est minimaliste... Peur que l'on se retrouve très vite limités

Je sais que Astro évolue rapidement, donc peut-être que ça s'arrangera. Mais so far je me demande a quel point ça nous arrange par rapport à NuxtJS par exemple.

[goulvenclech]

Rendu obsolète par #56 , bye bye !