{ "version": "https://jsonfeed.org/version/1.1", "title": "Thomas Citharel", "language": "fr", "home_page_url": "https://tcit.fr", "feed_url": "https://tcit.fr/feed.json", "description": "Je m’appelle Thomas, et je crée des outils web.", "author": { "name": "Thomas Citharel", "url": "" }, "items": [{ "id": "https://tcit.fr/post/dynamically-add-enum-values-in-elixir's-graphql-library-absinthe/", "url": "https://tcit.fr/post/dynamically-add-enum-values-in-elixir's-graphql-library-absinthe/", "title": "Dynamically add enum values in Elixir's GraphQL Library Absinthe", "content_html": "

Do you have a huge list of value acceptable for a GraphQL enum? Absinthe can dynamically extend the schema at runtime.

\n

While adding a "category" feature to the events in Mobilizon, I wanted to restict the values this field could take. Usually I use an enum in the GraphQL schema definition for this kind of situation, for instance:

\n
@desc \"The list of join options for an event\"
  enum :event_join_options do
    value(:free, description: \"Anyone can join and is automatically accepted\")
    value(:restricted, description: \"Manual acceptation\")
    value(:invite, description: \"Participants must be invited\")
  end
\n

This uses the enum macro and three value macros. But in this case there would be a lot of options for value, so it wouldn't make sense to have them all in the schema declaration.

\n

Moreover, I want this list of categories to be extendable in the future by the instance administrator, who doesn't want to recompile to extend the list.

\n

So the Absinthe docs are far from being perfect, but you can find mention of custom schema manipulation. This page, with the help of a few Github issues and a test file, helped me see clear through this.

\n

For starters, let's create a new module to dynamically build our new enum. There's a few comments inline.

\n
defmodule Mobilizon.GraphQL.Schema.Custom.EnumTypes do
  alias Absinthe.Blueprint.Schema
  alias Absinthe.Schema.Notation
  alias Absinthe.{Blueprint, Pipeline, Phase}

  # The list of categories
  # having an atom identifier and a string label
  # This is currently being defined as a module attribute,
  # but in the future it will be expanded by some admin
  # configuration as well
  @categories [
    %{
      id: :arts,
      label: \"ARTS\"
    },
    # … a long list of categories
  ]

  def pipeline(pipeline) do
    # When to insert this override
    Pipeline.insert_after(pipeline, Phase.Schema.TypeImports, __MODULE__)
  end

  # Adding this enum to the list of schema definitions
  def run(blueprint = %Blueprint{}, _) do
    %{schema_definitions: [schema]} = blueprint

    new_enum = build_dynamic_enum()

    schema =
      Map.update!(schema, :type_definitions, fn type_definitions ->
        [new_enum | type_definitions]
      end)

    {:ok, %{blueprint | schema_definitions: [schema]}}
  end

  # Building the enum itself
  def build_dynamic_enum do
    %Schema.EnumTypeDefinition{
      name: \"EventCategory\",
      identifier: :event_category,
      module: __MODULE__,
      __reference__: Notation.build_reference(__ENV__),
      values:
        # Create a `Schema.EnumValueDefinition`
        # for each value in `@categories`
        Enum.map(@categories, fn %{id: id, label: label} ->
          %Schema.EnumValueDefinition{
            identifier: id,
            # The `value` can either be `id` or `label`
            # depending whether what you want to be given
            value: label,
            name: label,
            module: __MODULE__,
            __reference__: Notation.build_reference(__ENV__)
          }
        end)
    }
  end
end
\n

Finally, we just have to add in our schema definition file the following @pipeline_modifier attribute:

\n
defmodule Mobilizon.GraphQL.Schema do
  use Absinthe.Schema

  @pipeline_modifier Custom.EnumTypes

  # [… our whole schema]
end
\n

And boom, we can use our new enum just like this:

\n
field :create_event, type: :event do
  # …
  arg(:category,
    :event_category,
    # string or atom depending on what you use for value above
    default_value: \"ARTS\",
    description: \"The event's category\"
  )
  # …
end
\n", "date_published": "2022-03-27T18:22:36Z" },{ "id": "https://tcit.fr/post/imprimer-en-pdf/", "url": "https://tcit.fr/post/imprimer-en-pdf/", "title": "Imprimer en PDF", "content_html": "

Quand je veux imprimer un fichier PDF sur une imprimante jamais configurée, ça prend souvent des heures sans raison.

\n

Je constate alors ce message dans les logs :

\n
Use "pdftops-renderer" option (see README file) to use Ghostscript or MuPDF for the PDF -> PostScript conversion\n
\n

Globalement il me semble que c'est la conversion de PDF en un truc compréhensible par l'imprimante (Ghostscript, PostScript) qui rate.

\n

Sur le web, il est proposé d'utiliser pdftops comme outil de rendu (qui semble utiliser Poppler), mais ce qui marche le mieux pour moi c'est directement d'utiliser Ghostscript.

\n
lpadmin -p mon_imprimante -o pdftops-renderer-default=gs
\n

Où mon_imprimante est le nom de l'imprimante, que vous pouvez trouver avec lpstat -p.

\n

L'impression se fait alors quasi-instantanément.

\n", "date_published": "2022-01-17T09:20:00Z" },{ "id": "https://tcit.fr/post/faire-fonctionner-le-wifi-intel-sous-fedora-35/", "url": "https://tcit.fr/post/faire-fonctionner-le-wifi-intel-sous-fedora-35/", "title": "Faire fonctionner le wifi Intel sous Fedora 35", "content_html": "

Si vous avez migré vers la version 35 de Fedora et que vous utilisez une carte Wi-Fi Intel, cela peut vous aider.

\n

Tout d'abord, voyons si vous êtes concerné :

\n
lspci | grep "Network controller"\n02:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)\n
\n

Si la référence de votre carte correspond à AX2xx, vous êtes probablement concerné.

\n

En Octobre 2021 le microcode pour cette carte a été migré dans un paquet séparé du fameux linux-firmware.

\n

Il faut alors installer iwlax2xx-firmware pour faire refonctionner le Wi-Fi. Un redémarrage et c'est reparti.

\n", "date_published": "2021-10-04T09:20:00Z" },{ "id": "https://tcit.fr/post/publier-un-blog-statique-avec-gridsome/", "url": "https://tcit.fr/post/publier-un-blog-statique-avec-gridsome/", "title": "Publier un blog statique avec Gridsome", "content_html": "

Gridsome est un framework pour générer des sites statiques à l'aide de VueJS et GraphQL.

\n

On parle aussi de framework JAMStack, pour Javascript, APIs et Markup. En gros, ce terme décrit simplement d'avoir la possibilité d'ajouter des fonctionnalités dynamiques par dessus votre site statique généré à partir de fichiers sources comme du Markdown, le HTML étant hydraté avec l'application Javascript.

\n

Il n'y a pas de fonctionnalités statiques ici, j'ai juste besoin d'un blog, il n'y aura pas grande différence à l'utilisation si jamais vous avez le Javascript activé ou non dans votre navigateur[^1].

\n

J'ai choisi Gridsome car il utilise le framework VueJS avec lequel je suis plus familiarisé, mais c'est quasiment le même fonctionnement que GatsbyJS qui utilise ReactJS.

\n

J'avais eu l'occasion d'utiliser Gatsby pour entraide.chatons.org et j'avais trouvé le concept intéressant. Aujourd'hui, cet article que vous lisez est justement affiché dans une page d'un site statique généré par Gridsome.

\n

Comme indiqué sur la page de présentation de Gridsome : vous prenez des sources de données en entrée, vous effectuez des traitements sur les données (sélection, transformation, affichage) et vous déployez les fichiers HTML et assets produits.

\n

Créer un projet Gridsome #

\n

On commence par installer le module qui fournit la ligne de commande :

\n
yarn global add @gridsome/cli
\n

J'utilise yarn dans les commandes, mais vous pouvez bien sûr utiliser les équivalents npm si c'est ce que vous préférez.

\n

Puis on crée un nouveau projet :

\n
gridsome create mon-site
\n

Cela récupère le modèle du projet, le met à jour avec le nom du projet, et installe les dépendances.

\n

On peut alors se mettre dans le dossier du projet nouvellement créé puis lance le serveur de développement, par défaut sur le port 8080.

\n
cd mon-site
gridsome develop
\n

Structure du projet #

\n

Vous devriez avoir une structure de projet équivalente voire égale à celle ci-dessous :

\n
├── gridsome.config.js\n├── gridsome.server.js\n├── package.json\n├── README.md\n├── src\n│   ├── components\n│   │   └── README.md\n│   ├── favicon.png\n│   ├── layouts\n│   │   ├── Default.vue\n│   │   └── README.md\n│   ├── main.js\n│   ├── pages\n│   │   ├── About.vue\n│   │   ├── Index.vue\n│   │   └── README.md\n│   └── templates\n│       └── README.md\n├── static\n│   └── README.md\n└── yarn.lock\n
\n

On voit dans src/pages/ les fichiers About.vue et Index.vue, qui correspondent aux deux routes accessibles via la barre de navigation. Notez donc que le routage de base se fait via les fichiers disponibles dans /pages/. Index.vue correspond à la page d'accueil /, et un fichier MonProjet.vue donnerait une route /mon-projet.

\n

On a également le fichier Default.vue dans /src/layouts/. Les layouts sont utilisés pour envelopper vos pages avec des éléments communs aux pages, typiquement l'en-tête de la page, la barre de navigation, le pied-de-page… Dans nos pages, par exemple About.vue, le contenu est enveloppé par l'élément <Layout> :

\n
<template>
  <Layout>
    <h1>About us</h1>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Error doloremque omnis animi, eligendi magni a voluptatum, vitae, consequuntur rerum illum odit fugit assumenda rem dolores inventore iste reprehenderit maxime! Iusto.</p>
  </Layout>
</template>
\n

Ajout et représentation des données #

\n

Le squelette de notre site étant exploré, voyons comment y insérer nos données. Gridsome utilise GraphQL, un langage de requêtes. Nous avons par exemple un premier exemple de requête GraphQL dans le fichier layouts/Default.vue, où le nom du site (défini dans le fichier de configuration gridsome.config.js) est récupéré avec la requête suivante :

\n
query {
  metadata {
    siteName
  }
}
\n

La variable siteName est alors disponible via l'expression $static.metadata.siteName dans notre template VueJS.

\n

Pour importer nos propres données, prenons l'exemple basique de billets de blog sous forme de fichiers locaux au format Markdown.

\n

Installons les modules @gridsome/source-filesystem afin de récupérer le contenu des fichiers et @gridsome/transformer-remark afin de transformer notre contenu markdown en HTML et surtout convertir l'éventuel front matter YAML en métadonnées utilisables.

\n

Nous allons ajouter la configuration donnée en exemple dans gridsome.config.js :

\n
module.exports = {
  plugins: [
    {
      use: '@gridsome/source-filesystem',
      options: {
        typeName: 'BlogPost',
        path: './content/blog/**/*.md',
      }
    }
  ],
  templates: {
    BlogPost: '/blog/:year/:month/:day/:title'
  }
}
\n

Puis créons l'arborescence content/blog/2020 et un fichier hello world.md au bout avec le contenu de base suivant :

\n
---
date: 2020-01-05
title: \"Hello World\"
---
Il s'agit de mon **premier** contenu !
\n

On redémarre le serveur de développement Gridsome car on a changé la configuration puis on ouvre le bac à sable GraphQL pour effectuer nos premières requêtes et voir le résultat facilement.

\n

Par exemple, pour récupérer la liste de tous nos posts, on écrira :

\n
query {
   allBlogPost {
    edges {
      node {
        title,
        date(format: \"DD/MM/YYYY\"),
        path
      }
    }
  }
}
\n

Si on édite notre page Index.vue, on peut rajouter cette requête dans un bloc <page-query> et ensuite accéder aux données via $page.allBlogPost, comme par comme dans l'exemple suivant où nous rajoutons une liste des billets au template :

\n
<ul v-for=\"edge in $page.allBlogPost.edges\" :key=\"edge.node.id\">
  <li></li>
</ul>
\n

Ajoutons ensuite un fichier BlogPost.vue dans nos templates/ pour représenter ces entités:

\n
<template>
  <Layout>
    <article>
      <h1>{{ $page.blogPost.title }}</h1>
      <span>{{ $page.blogPost.date }}</span>
      <div v-html=\"$page.blogPost.content\"></div>
    </article>
  </Layout>
</template>

<page-query>
query BlogPost($path: String!) {
   blogPost(path: $path) {
        title,
        date(format: \"DD/MM/YYYY\"),
        content
        path
  }
}
</page-query>
\n

Comme on l'a vu, les données de la requête GraphQL blogPost sont injectées dans la variable $page accessible dans mon template. Maintenant que l'on a une page dédiée pour afficher chaque billet, ajoutons un lien depuis notre liste sur la page Index.vue, en changeant notre <li> en :

\n
<li>
  <g-link :to=\"edge.node.path\"></g-link>
</li>
\n

La balise <g-link> crée lors du rendu des balises <a> tout ce qu'il y a de plus basique, mais permet aussi le préchargement des liens (voir les notes de bas de page). En cliquant dessus, on arrive finalement sur notre page montrant un article en particulier.

\n

Génération et publication #

\n

Générons maintenant notre site avec gridsome build, puis servons le contenu du dossier dist, par exemple avec serve : serve dist.

\n

Je vous laisse vérifier que la navigation fonctionne bien et que le HTML produit contient bien notre contenu.

\n

On peut publier le contenu de dist là où on le souhaite, voici un exemple de fichier de configuration pour le publier sur Gitlab Pages :

\n
image: node:14
deploy:
  stage: deploy
  script:
    - yarn install
    - yarn build
    - gzip -kv -6 -r public
  artifacts:
    paths:
      - public
\n

Je m'arrête là pour parler de Gridsome, mais j'ai quand même prévu de parler de comment gérer mes contenus sur ce site avec NetlifyCMS, et comment mettre en place un chroot sur un serveur pour y faire un rsync depuis notre CI afin de déployer notre site.

\n

[^1]: Une différence est que si le Javascript est activé, Gridsome est censé observer les liens internes actuellement affichés à l'écran (avec IntersectionObserver) pour les précharger afin que les chargements de page soient effectués avant même le clic éventuel sur le lien. Les gains devraient rester minimaux étant donné qu'il n'y a qu'un contenu HTML à récupérer depuis le serveur.

\n", "date_published": "2020-05-22T20:35:53Z" },{ "id": "https://tcit.fr/post/terre-brulee/", "url": "https://tcit.fr/post/terre-brulee/", "title": "Terre Brûlée", "content_html": "

Au vent, des landes de pierre…
\nMaintenant que cette chanson est en tête, je voulais juste partager quelques photos d'Irlande.

\n

J'y étais en Juin, en road trip sur la plus grande partie du littoral de la moitié Nord.
\nVoici des photos de mes coins préférés, surtout dans le comté de Mayo, de Downpatrick Head à la vallée de Doolough, en passant par l'île d'Achill et en poussant jusqu'au parc national du Connemara.

\n

Elles sont classées par ordre chronologique.

\n", "date_published": "2019-11-09T22:57:27Z" },{ "id": "https://tcit.fr/post/internationalisation-simple-des-dates-dans-le-navigateur/", "url": "https://tcit.fr/post/internationalisation-simple-des-dates-dans-le-navigateur/", "title": "Internationalisation simple des dates dans le navigateur", "content_html": "

Nous allons voir dans cet article comment formatter des dates facilement dans le navigateur en évitant de faire appel à des bibliothèques tierces.

\n

Formater avec MomentJS #

\n

Lorsque l'on veut manipuler des données temporelles avec Javascript dans le navigateur, on se repose souvent sur la bibliothèque Moment.js.
\nElle permet en effet de formater des dates à sa convenance :

\n
moment().format('MMMM Do YYYY, HH:mm:ss');  
// October 19th 2019, 19:04:56
\n
moment().format('dddd, MMMM do YYYY');  
// Saturday, October 6th 2019
\n

Si vous chargez aussi le support des différentes locales, ça peut vous donner ceci :

\n
moment.locale('fr');  
moment().format('LLL');  
// 19 octobre 2019 19:09
\n

Plutôt pratique, n'est-ce pas ? Du coup Moment.js est très populaire (42k stars sur Github) et très utilisé (presque 2 millions d'installations journalières via npm, où plus de 36 000 paquets en sont dépendants ).

\n

Confort vs poids #

\n

Le souci de Moment.js, c'est son poids énorme de 329Ko (non compressé, et avec toutes les locales).
\nDu coup ça fait un sacré module à charger (et il faut mieux qu'il soit chargé dès le début, c'est pas très joli quand les dates s'affichent une fois seulement que la page est chargée).

\n

Y a quelques solutions pour améliorer cela, par exemple charger uniquement la locale de l'utilisateur qui peut être fournie par le backend en fonction de l'en-tête Accept-Language.
\nOn peut ensuite éventuellement charger dynamiquement d'autres locales si jamais l'utilisateur⋅ice décide de changer de langue.

\n

Cela dit, même en chargeant uniquement le cœur de Moment.js, on reste à plusieurs dizaines de kilo-octets pour une utilisé potentiellement très limitée.

\n

En réaction à cette problématique, les bibliothèques dayjs et date-fns - de poids beaucoup plus réduit - existent. Date-fns permet de faire du tree-shaking avec Webpack pour importer uniquement les modules dont on a besoin et dayjs n'incorpore que le minimum, en externalisant les fonctionnalités supplémentaires via des plugins.

\n

Pour la plupart des fonctionnalités, ça remplace très bien Moment.js. Vous pouvez voir un comparatif sur ce dépôt : You don't (may not) need Moment.js.

\n

Encore plus léger #

\n

Et si on voulait s'épargner encore quelques kilo-octets, on regarderait du côté…de Javascript. En effet, il existe depuis relativement assez longtemps (2012) une API Intl avec notamment un objet DateTimeFormat fait pour formater des dates en fonction de la locale.

\n

Ça s'utilise comme cela :

\n
let date = new Date();
new Intl.DateTimeFormat('fr-FR').format(date);
// 10/19/2019
\n

Ça prend en charge correctement les caractères non-latins et le sens d'écriture de droite à gauche :

\n
let date = new Date();
new Intl.DateTimeFormat('ar-EG').format(date);
// ١٩‏/١٠‏/٢٠١٩
\n

Si on ne veut pas spécifier de locale, on peut passer l'argument 'default' ou bien undefined au constructeur de Intl.DateTimeFormat, ça utilisera la locale configurée du navigateur :

\n
let date = new Date();
new Intl.DateTimeFormat('default').format(date);
// 10/19/2019
\n

Bon, et maintenant si on veut une vraie date formattée, comment on fait ?

\n

Avec le second argument du constructeur, pardi !

\n
let date = new Date();
let options = { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' };
new Intl.DateTimeFormat('default', options).format(date);
// samedi 19 octobre 2019
new Intl.DateTimeFormat('ar-EG', options).format(date);
// السبت، ١٩ أكتوبر ٢٠١٩
\n

La référence de ces options se trouve sur cette page du MDN.

\n

Comme l'API Intl est assez ancienne, le support est plutôt bon (Internet Explorer 11, Safari 10).

\n

Formatage de dates relatives #

\n

Je note qu'il existe aussi un objet Intl.RelativeTimeFormat pour afficher des temps relatifs :

\n
const rtf = new Intl.RelativeTimeFormat('default', { numeric: \"auto\" });
rtf.format(-1, \"day\");
// 'hier'

rtf.format(3, \"day\");
// 'dans 3 jours'

rtf.format(-6, \"month\");
// 'il y a 6 mois'
\n

Cette fois par contre, pas de support pour Internet Explorer, Edge ou Safari, ce qui rend son emploi plus hasardeux. On peut bien entendu détecter cela avec

\n
if (Intl.DateTimeFormat) {
    // do something
    // it should probably work
}

if (Intl.RelativeTimeFormat) {
    // do something
    // you're using Firefox or Chrome
}
\n

Conclusion #

\n

Voilà, même avec l'addition récente de RelativeTimeFormat, l'API Intl est vraiment loin d'avoir toutes les fonctionnalités de Moment.js ou même de date-fns, mais s'il vous faut juste afficher quelques dates au bon format, pas besoin de charger des centaines de kilooctets pour rien.🙂

\n

Bonus #

\n

En utilisant l'API Intl, on peut facilement récupérer la liste des mois et des noms des jours traduits dans la langue de l'utilisateur :

\n
function localeMonthNames() {
  const monthNames = [];
  for (let i = 0; i < 12; i += 1) {
    const d = new Date(2019, i, 1);
    const month = d.toLocaleString('default', { month: 'long' });
    monthNames.push(month);
  }
  return monthNames;
}
localeMonthNames();
// [ \"janvier\", \"février\", \"mars\", \"avril\", \"mai\", \"juin\", \"juillet\", … ]
\n

Là, c'est plutôt simple, on n'a qu'à itérer chaque mois dans le constructeur de Date pour avoir son nom textuel. On note quand même que les mois commencent à 0.

\n
function localeShortWeekDayNames() {
  const weekDayNames = [];
  for (let i = 13; i < 20; i += 1) {
    const d = new Date(2019, 9, i);
    const weekDay = d.toLocaleString('default', { weekday: 'short' });
    weekDayNames.push(weekDay);
  }
  return weekDayNames;
}
localeShortWeekDayNames();
// [ \"dim.\", \"lun.\", \"mar.\", \"mer.\", \"jeu.\", \"ven.\", \"sam.\" ]
\n

Ici, c'est plus compliqué, il faut partir d'une date où l'on sait qu'il s'agit d'un dimanche, puis itérer sur les 7 jours de la semaine. Et oui, le jour 0 est bien un Dimanche. Ici j'ai mis les versions courtes des noms des jours, mais ça marche aussi évidemment avec la fonction complète.

\n

Ça peut éviter de traduire des informations inutiles.

\n

Un truc qui manque par contre, c'est déterminer en fonction de la locale quel jour de la semaine celle-ci commence. En effet, si la fameuse norme ISO 8601 définit lundi comme le premier jour de la semaine, certains pays comme les États-Unis d'Amérique, le Canada, le Japon et l'Australie entament leur semaine le Dimanche. Au Moyen-Orient, elle commence le Samedi. Du coup si vous n'avez pas de bibliothèque tierce, il faut fournir l'option aux traducteurs pour qu'ils mettent leur propre valeur.

\n

Image « Calendrier Mural Jours » par Andreas Lischka sur Pixabay

\n", "date_published": "2019-10-20T10:36:42Z" } ] }