Aller plus loin

Le framework Next.js

Lorsque l’on entend parler de React, il est de plus en plus commun que soit également mentionné Next.js. React est réputé peu efficace dans la gestion du SEO (bien que cela vienne aussi de la sous-utilisation de méthodes d’optimisation du chargement telles que le lazy loading). C’est pour pallier ces manques qu’intervient Next.js. Il permet de construire des applications web modernes, rapides, et optimisées pour le SEO en prenant en charge le rendu côté serveur (SSR - Server Side Rendering) et la génération de sites statiques (SSG - Static Site Generator). Next.js est un framework web open source développé par Vercel, qui combine la réactivité des applications React et la performance des applications traditionnelles.

Next.js n’est pas utilisé dans tous les projets React mais il tend à se répandre de plus en plus. En avoir connaissance peut donc être un avantage non négligeable. Pour autant, Next.js n’est pas un gros framework, disposant de nombreuses fonctionnalités. Bien au contraire, ses fonctionnalités peuvent être regroupées autour de quatre parties. La plus importante est le rendu hybride (SSR et SSG) qui offre des performances remarquables en matière de SEO et de chargement des pages. La seconde est le App Router. La troisième est l’optimisation automatique des données (images et polices). Enfin, la dernière fonctionnalité est la possibilité de créer des routes d’API directement dans Next.js. Cette dernière est moins utilisée car, le plus souvent, un développeur back-end ou fullstack maîtrise déjà une autre technologie plus adaptée pour créer des serveurs d’API. Ces routes servent davantage de point de contact entre une application front-end et un serveur d’API externe.

Pour créer un nouveau projet Next.js, exécutons la commande :

npx create-next-app@latest

L’invite de commande proposera d’utiliser TypeScript et le App Router. Il est très fortement conseillé de les intégrer au projet.

Comme pour les autres bibliothèques étudiées, et dans la mesure où cet ouvrage est consacré à React et non à Next.js...

La sécurité des applications

La sécurité est une préoccupation majeure dans le domaine du développement web. Si React offre des protections par défaut, il est crucial de comprendre les vulnérabilités courantes qui peuvent toucher une application et faire le nécessaire pour s’en prémunir. La sécurité ne sera toutefois pas densément étudiée ici, car l’essentiel des pratiques de sécurisation d’une application ne sont pas propres à React et doivent être mises en place sur toute application web indépendamment de la technologie choisie. Il revient au développeur de se former sur le sujet. Les failles de sécurité sont nombreuses : faille XSRF (Cross-Site Request Forgery), injection de dépendances dans les packages npm, données d’authentification gérée via l’API localStorage, etc. Toutefois, en React, la faille la plus courante est sans nul doute la faille d’injection de code XSS.

Une injection de code (souvent appelée XSS, Cross-Site Scripting) se produit lorsqu’un attaquant injecte du code malveillant (le plus souvent, un morceau de code JavaScript) dans une application web, via un champ de texte ou une entrée utilisateur. Ce code est stocké sur le serveur et s’exécute lorsque, via son navigateur, un utilisateur...

L’internationalisation (i18n)

L’internationalisation consiste à adapter une application pour qu’elle soit disponible dans plusieurs langues sans avoir à modifier de manière extensive le code source. Le principe de base de l’internationalisation est d’externaliser les chaînes de caractères hors du code. Elles sont stockées dans des fichiers de traduction qui se chargeront selon la langue choisie par l’utilisateur ou définie par son système.

1. La configuration de l’internationalisation

La bibliothèque d’internationalisation la plus connue en JavaScript est i18next. Elle est portée en React via le package react-i18next.

Attention à ne pas faire la confusion : i18next n’a rien à voir avec Next.js.

Il est possible d’installer ces packages via la commande :

npm install i18next react-i18next

Le package i18next-browser-languagedetector peut aussi être installé pour une détection automatique de la langue de l’utilisateur en fonction de la configuration de son navigateur.

Jusqu’ici, tous les textes lisibles par l’utilisateur étaient écrits « en dur » directement dans le code JSX. Si cette approche est cohérente avec les besoins pédagogiques de l’ouvrage, il est crucial, dans une application, de séparer clairement les textes du reste du code, a minima dans un ou des fichiers JSON (Javascript Object Notation) externalisés. Cela facilitera nettement la maintenance de l’application, y compris s’il n’y a pas d’intention d’internationaliser l’application (les textes sont centralisés et ne nécessitent pas de manipulation directe du code source). Par ailleurs, les chaînes stockées dans des fichiers JSON peuvent être utilisées dans les tests unitaires. Cela s’avère utile si un test unitaire teste un composant en fonction de son texte. Changer le texte dans le composant casserait alors le test unitaire, ce qui n’arrivera pas si les valeurs textuelles sont partagées entre tests et composants.

Dans une application internationalisée, il est commun d’avoir un répertoire locales/ à la racine du projet, dans lequel on place des sous-répertoires pour chaque langue et dont...

L’accessibilité (A11y)

Il est crucial qu’une application soit accessible à tous et qu’elle puisse être utilisée indépendamment des capacités de l’utilisateur. L’accessibilité commence par un bon usage de la sémantique des balises HTML, et s’étend à des pratiques propres à React. Il faut donc penser à utiliser les balises de structure (main, nav, header, etc.) plutôt que d’utiliser systématiquement des balises <div>. Si cela n’est pas possible, il est important d’appliquer un rôle via l’attribut role pour que le logiciel utilisé pour naviguer sache qu’il s’agisse d’un élément interactif.

{/* For some reason, a button tag can't be used here. So the role needs to be explicit. */} 
 
<div role="button">Click me !</div>

1. Les rôles et attributs ARIA

Les attributs ARIA (Accessible Rich Internet Application) sont un ensemble d’attributs HTML qui servent à améliorer l’accessibilité des applications pour les personnes utilisant des technologies d’assistance, comme les lecteurs d’écran. Cela permet de rendre des interfaces compréhensibles à un utilisateur qui ne peut pas naviguer via la souris. Les attributs role sont un exemple. Ils permettent d’expliciter la fonction d’un élément HTML (le plus souvent une balise <div> ou <span>) dont le rôle n’est pas clairement explicité par la sémantique de la balise elle-même. Par exemple, appliquer le rôle "menu" à une balise <nav> ou le rôle "link" à une balise <a> est sans intérêt.

Il y a aussi des attributs spécifiquement conçus pour décrire à l’utilisateur ce qu’il se passe à l’écran. Pour les éléments qui n’ont pas de texte (par exemple un bouton avec une icône), l’attribut aria-label permet de fournir un texte alternatif, analogiquement à l’attribut alt pour les balises <img>.

<button aria-label="Send the message"> 
  <PaperPlaneIcon /> 
</button

L’attribut...