Comment et pourquoi ce blog est custom?

Il y a quelques temps, je surfais sur le blog d'une amie - ça s'appelle Furax, c'est vraiment trop bien - et je me souviens qu'elle m'avait demandé ce que je lui conseillais techniquement pour faire un blog. J'avais dit "Franchement, t'emmerdes pas, fais un Wordpress". Pourquoi je ne suis pas les conseils que je donne à mes propres amies (car mon blog n'est pas un Wordpress) ? Je vous raconte.

Un site custom, franchement, pourquoi tu te compliques la vie, Audrey ?

Ben oui c'est vrai ça, bonne question. J'aime bien Wordpress, j'ai rien contre et en plus ça me permettrait d'avoir une partie portfolio un peu plus léchée que la mienne actuellement (je sais, ça commence à se voir que je ne l'entretiens pas...). Pour comprendre, il faut remonter à mes débuts de code : en octobre 2022, quand j'entame ma formation à Ada, il nous faut "un projet".

Je sens bien que c'est pas avec mes trois compétences en JS que je vais réussir à coder l'app de mes rêves et très vite, comme je sais que j'aime bien écrire, je me dis qu'ouvrir un blog pour documenter mon parcours, ça pourrait être intéressant. Mais pas seulement: comme je débute en HTML/CSS, je me dis que je ferais bien ce blog custom, juste pour enfin mettre en place mes maigres et fraiches compétences. Sur les conseils d'un dev éclairé, je décide de faire un petit site statique hébergé sur une page github. Simple, basique.

Avec le recul, je suis très contente d'avoir pris cette décision:

• du côté blog, ca m'a forcé à avoir une régularité dans mes bilans et à suivre correctement mes revues de littérature et ma veille;
• du côté code, j'ai pu appliquer des connaissances en html, css et js et découvrir les pages github.

Pourquoi changer ? Choix techniques et artistiques (lol)

Rapidement, la page Github montre ses limites : j'ai besoin de quelque chose de plus dynamique qui me permette de gérer davantage de fonctionnalités et d'étendre l'app au serveur.

Nextjs s'impose assez facilement : idéal pour les sites composites que sont les blogs (une partie peut tout à fait être faite en statique mais il est parfois utile d'avoir du SSR), en React - une librairie que j'essaye d'apprendre depuis quelques semaines -, un tuto simple, une bonne interopérabilité avec d'autres librairies et stacks qui m'intéressent.

Par ailleurs, j'écris mes articles sur Obsidian en markdown. L'idée est donc d'implémenter un process rapide et efficace d'écriture et de publication des articles, sans devoir passer de mes articles stockés en local sur mon ordinateur en md à mes articles dans des balises HTML.

Bref, j'ai migré d'une page statique à un vrai site créé sur Next, déployé par Vercel et hébergé sur OVH. C'était il y a plusieurs mois et il s'enrichit de jour en jour. Il est temps de faire un point d'étape.

MDX - écrire des articles, récupérer leurs metadatas, les publier

L'intérêt principal de ce blog, c'est le mdx qui me permet d'optimiser mon workflow. Pourquoi du mdx ?

1. L'intérêt premier de MDX, c'est que c'est du markdown. Ca répond donc à mon besoin de faciliter mon workflow. J'écris en effet mes articles sur Obsidian, en markdown. Je n'ai plus qu'à les récupérer tels quels sur mon app et voilà.
2. Pourquoi du mdx et pas du markdown alors ? Le mdx me permet d'intégrer du JSX dans mon markdown. Le JSX étant, je le rappelle, l'extension de Javascript qui permet d'écrire du HTML dans du JS (donc oui, maintenant je peux écrire du HTML dans du JS dans du markdown).

3. Pourquoi du mdx (suite) ? Nextjs gère très bien le mdx : la configuration est simple et bien documentée. pour l'utiliser avec Typescript.

4. Je peux faire des composants jsx comme dans une app react et les importer dans mon article en mdx. Par exemple: citer des tweet grâce au composant natif de Next, personnaliser les encadrés des tips de Dre Drey, ou même de faire de la datavisualisation avec D3. Bref, la créativité n'a plus de limite.

5. Finalement, le dernier intérêt du mdx n'est pas le moindre : il donne la possibilité d'intégrer des métadatas aux fichiers mdx grâce à la librairie gray matter. Cette librairie me permet d'agréger les métadatas de mes articles en fichier json au moment du prebuild grace au prebuil-metadata.json qui va chercher les metadata de tous les fichiers qui ont la route pages/blog / \* _ / _ .mdx. Ces metadata c'est la vie : c'est ce qui me permet de générer des pages qui prennent en compte les titres, langues, tags, date, description, etc. de mes articles, de faciliter leur rendu sur la page en français et en anglais et finalement de générer le flux RSS.

En conclusion, l'alliance de Nextjs, du mdx et de quelques librairies me permet de faciliter la publication de mes articles mais aussi de les customiser de plein de manières différentes.

Le CSS : Tailwind

Le CSS global (font, hover, titres, etc.) est géré dans le fichier de configuration, avec un pluging Typography qui me permet d'appliquer des classes prose, adaptées aux longs textes, très pratique en MD. Par exemple, prose dark:prose-invert va automatiquement optimiser le mode dark selon le thème.

Une configuration importante de mon blog, c'est son CSS géré par Tailwind. Au moment où j'ai commencé, ça me paraissait être le plus simple et j'ai beaucoup aimé la proposition de Tailwind. Mon bilan sur ce projet est vraiment mitigé : c'est ok pour le commencer, mais plus je l'utilise moins j'ai envie de l'utiliser et ça, c'est quand même pas ouf comme expérience de dev. Je ne vais pas développer ici avec précisions les raisons de cette mauvaise expérience et ça sera peut-être l'occasion d'un autre article, mais en gros: trop de répétitions, trop long, trop lourd, trop illisible, etc. Si c'était à refaire, je ne le referais pas et l'objectif est de migrer sur un css module ou une librairie de composants (mais j'ai du mal à me décider).

Les bonus

Evidemment, l'App.tsx wrappe le tout, avec notamment le queryprovider, les analytics, et l'highlight (pour highlight le code). Je ne reviens pas sur le queryprovider que j'utilise à savoir react query, car j'en parlais dans la dernière revue de presse avec l'article du blog de TkDodo. Par contre, voici quelques outils que j'utilise pour des services ou features complémentaires :

Vercel

Le site est déployé grâce à Vercel. Simple et efficace, le service fournit tout une série d'outils vraiment pratiques, puisque c'est aussi Vercel qui me permet de gérer mes analytics (avec le composant <Analytics/> directement dans l'app et une interface vraiment clean), mais aussi mes opengraph customisés. Oui, pour l'instant ma créativité se limite à un dégradé de couleurs, j'ai pas fait option design à la fac, mais j'ai prévu de revenir dessus dès que j'aurais davantage d'idées.

export default function handler(request: NextRequest) {
  try {
    const { searchParams } = new URL(request.url);

    // j'ai choisi d'afficher le titre comme je n'ai pas d'articles d'auteurs externes,
    //mais je pourrais display davantage d'infos...
    const hasTitle = searchParams.has("title");
    const title = hasTitle
      ? decodeURIComponent(searchParams.get("title")?.slice(0, 100) || "")
      : "My default title";

    return new ImageResponse(
      (
    // la tu mets le style qui te plait et les balises qui te plaisent: texte, image, etc.
      ),
      {
        width: 1200,
        height: 630,
      }
    );
  } catch (e) {
    console.log(`${e.message}`);
    return new Response(`Failed to generate the image`, {
      status: 500,
    });
  }
}

Les libraries externes: D3, le flux RSS, le highlight

En parlant de bout de code dans le texte, je vais finir cet article sur quelques librairies utilisées dans ce projet et que je ne vais pas détailler ici mais qui peuvent donner des pistes si tu cherches des outils pour certaines features.

• Pour display le code comme ci-dessus, j'utilise le markdown ensuite customisé par highlight.js une super librairie qui te permet de customiser les couleurs de ton code dans le texte, etc.
• Pour gérer le flux rss, sur la base de l'excellent article de Paola Ducolin, j'ai finalement opté pour feed.
• Pour les graphiques, j'avais beaucoup testé Chart.js mais je suis passée à D3 aidée par les ressources d'Amelia Wattenberger (ma frontend préférée, son blog est si pédagogique et léché que j'ai les yeux qui saignent dès que je reviens sur le mien.)

Et voilà, si tu as des suggestions ou des sujets sur lesquels tu voudrais davantage de détails, n'hésite pas à me contacter :).