Pour bien comprendre les concepts de Next.js et React, ainsi que leurs méthodes et hooks spécifiques, voici un tableau détaillé qui explique chaque fonction et méthode, leur utilité, et où elles peuvent être utilisées (client, serveur ou les deux). En plus, nous aborderons des concepts comme Server Action, Route Handlers et Helpers.

1. Hooks et Méthodes de React/Next.js

2. Concepts et Méthodes de Next.js

3. Explication des Concepts

Server Action

Les Server Actions sont des fonctionnalités introduites dans Next.js qui permettent d’exécuter du code côté serveur directement dans le composant React, sans passer par une API route séparée. Cela permet de rendre l’architecture plus simple, de réduire le besoin d’API supplémentaires et d’améliorer la performance. Ce mécanisme est basé sur le fait que certaines actions doivent être exécutées côté serveur (par exemple, la gestion de l’état, l’appel à une base de données).

Exemple :

'use server'

async function addItemToCart(itemId) {
  const res = await fetch('/api/cart', { method: 'POST', body: JSON.stringify({ itemId }) });
  return res.json();
}

Route Handlers

Les Route Handlers sont des fonctions ou des méthodes utilisées pour traiter des requêtes HTTP dans Next.js. Cela peut inclure la gestion des requêtes GET, POST, PUT, DELETE, etc. Ces gestionnaires permettent de créer des API à partir de la structure des routes dans Next.js.

Exemple :

// Dans un fichier de route handler de Next.js 13
export async function GET(request) {
  const data = await fetchDataFromDatabase();
  return new Response(JSON.stringify(data));
}

Helpers

Les Helpers sont de petites fonctions utilitaires qui ne sont pas directement liées au rendu ou à la gestion de l’état, mais qui aident à organiser et simplifier le code. Par exemple, cela pourrait inclure des fonctions pour formater les dates, manipuler des objets ou des tableaux, ou encore simplifier les appels API.

Exemple :

function formatDate(date) {
  return new Date(date).toLocaleDateString('fr-FR');
}

Conclusion

• Client-side : Beaucoup des hooks comme useState, useEffect, et useSearchParams sont utilisés côté client dans React et Next.js.
• Server-side : Les Server Actions et les Route Handlers sont principalement utilisés côté serveur dans Next.js.
• Les deux (SSR/ISR) : Des techniques comme le Suspense et le useRouter (lorsqu’il est utilisé avec Server-Side Rendering) peuvent être utilisées à la fois côté client et serveur pour une expérience plus fluide.

Chaque fonction ou méthode a son propre contexte d’utilisation, donc il est essentiel de bien comprendre son rôle pour décider quand et où l’utiliser dans une application Next.js ou React.

Dans Next.js, le hook useRouter peut être utilisé à la fois côté client et côté serveur, mais il y a des différences importantes dans leur fonctionnement, notamment lorsque l’on parle de Server-Side Rendering (SSR). Voici des explications détaillées avec des exemples pour comprendre comment useRouter fonctionne dans ces deux contextes.

1. useRouter côté Client

Lorsqu’on utilise useRouter côté client, on accède à l’instance du routeur Next.js qui permet de gérer la navigation, récupérer des informations sur l’URL actuelle (par exemple, les paramètres de la requête ou le chemin actuel), et même effectuer une navigation programmée.

Exemple côté client :

import { useRouter } from 'next/router';

const ClientSidePage = () => {
  const router = useRouter();

  // On récupère le pathname (le chemin actuel)
  const currentPath = router.pathname;
  
  // Récupérer les paramètres de requête
  const { id } = router.query;

  // Naviguer vers une autre page
  const goToHome = () => {
    router.push('/');  // Redirige vers la page d'accueil
  };

  return (
    <div>
      <h1>Page actuelle : {currentPath}</h1>
      <p>Paramètre 'id' : {id}</p>
      <button onClick={goToHome}>Aller à la page d'accueil</button>
    </div>
  );
};

export default ClientSidePage;

Explication :

• router.pathname : Donne le chemin actuel de la page (par exemple, /about).
• router.query : Accède aux paramètres de la requête de l’URL (par exemple, si l’URL est /post?id=1, router.query.id serait 1).
• router.push : Permet de naviguer vers une autre page de manière programmatique.

Le useRouter côté client est principalement utilisé pour la gestion de la navigation dynamique (naviguer d’une page à l’autre sans rafraîchir la page complète).

2. useRouter côté Serveur avec SSR (Server-Side Rendering)

Dans Next.js, Server-Side Rendering (SSR) signifie que certaines pages sont rendues côté serveur avant d’être envoyées au client. Le hook useRouter peut également être utilisé dans le contexte du SSR, mais il a un comportement légèrement différent.

Lors du rendu côté serveur, Next.js ne peut pas accéder aux hooks React directement avant que la page ne soit envoyée au client. Cependant, le routage côté serveur (comme les paramètres d’URL) peut toujours être récupéré via des fonctions de rendu côté serveur comme getServerSideProps.

Exemple côté serveur avec SSR :

import { useRouter } from 'next/router';

const ServerSidePage = ({ serverSideData }) => {
  const router = useRouter();
  
  // Récupérer le pathname côté client après le rendu SSR
  const currentPath = router.pathname;

  return (
    <div>
      <h1>Page SSR - Chemin : {currentPath}</h1>
      <p>Données côté serveur : {serverSideData}</p>
    </div>
  );
};

// Cette fonction est exécutée côté serveur pour chaque requête
export async function getServerSideProps(context) {
  const { id } = context.query; // Accéder aux paramètres de requête côté serveur
  const serverSideData = `Données pour l'ID: ${id || 'non défini'}`;

  return {
    props: { serverSideData }, // Les données sont passées au composant
  };
}

export default ServerSidePage;

Explication :

• getServerSideProps : Cette fonction permet d’exécuter du code côté serveur avant de rendre la page. Ici, nous utilisons context.query pour obtenir les paramètres de la requête (similaire à router.query côté client).
• useRouter côté serveur : Le hook useRouter peut être utilisé côté client une fois que la page est rendue. Cependant, pour récupérer des données côté serveur (avant le rendu), vous devez utiliser getServerSideProps.

Le useRouter côté serveur, par défaut, ne fonctionne pas avant que la page ne soit envoyée au client. C’est pourquoi l’accès aux informations de l’URL comme les paramètres de requête doit être effectué dans getServerSideProps pendant le rendu côté serveur.

Comparaison Côté Client vs Serveur avec SSR

Conclusion

• Côté Client : Le hook useRouter est utilisé pour gérer la navigation, les paramètres de l’URL, et pour effectuer des redirections sans recharger la page. Il fonctionne de manière réactive après le premier rendu de la page.
• Côté Serveur (SSR) : Lorsque vous utilisez SSR avec getServerSideProps, vous ne pouvez pas utiliser useRouter pour accéder aux informations de l’URL avant que la page ne soit envoyée au client. Vous devez récupérer les paramètres de l’URL via l’objet context dans getServerSideProps. Cependant, une fois que le rendu côté serveur est terminé et que la page est envoyée au client, vous pouvez utiliser useRouter pour gérer la navigation côté client.

Cela montre comment useRouter fonctionne dans un contexte de rendu hybride (SSR et client) et comment l’utiliser efficacement dans un projet Next.js.

J’utilise depuis peu MaxGraph.js sous Next.js, pour créer des diagrammes techniques. MaxGraph.js est un Fork de la librairie MxGraph.js. Elle introduit des évolutions intéressantes.

Le développement de mxGraph à été stoppé le 09.11.2020.

J’ai utilisé la documentation, des exemples MxGraph.js pour comprendre la librairie, les fonctions et les objets.

Depuis peu, je suis en train de convertir des projets Draw2D , et mxGraph vers MaxGraph.

mxGraph 4.2.2

mxGraph is a JavaScript diagramming library that enables interactive graph and charting applications to be quickly created that run natively in any major browser that is supported by its vendor.

mxGraph est sous licence. Apache License 2.0.

La librairie à été crée en 2005.

La librairie a été utilisé pour créer Draw.IO . Une plateforme pour créer des diagrammes et des organigrammes

Le développement des sources mxGraph public à été stoppé le 09.11.2020.

mxGraph est une bibliothèque bien établie, mais son développement actif a été arrêté après son acquisition par JGraph Ltd. (créateurs de Diagrams.net).

( NOTE 09.11.2020 : Development on mxGraph has now stopped, this repo is effectively end of life.)

maxGraph V0.15.0

MaxGraph est un fork des sources MxGraph.

maxGraph est une bibliothèque TypeScript qui permet d’afficher et d’interagir avec des diagrammes vectoriels. À un niveau élevé, elle propose :

• Des nœuds, également appelés sommets, qui sont généralement représentés par des formes comme des rectangles.
• Des arêtes, qui peuvent être des lignes ou des flèches, reliant généralement un nœud à un autre.

Elle offre de nombreuses fonctionnalités de diagrammes que l’on pourrait attendre d’un logiciel de présentation comme Microsoft® PowerPoint™ ou LibreOffice® Impress, telles que la possibilité de redimensionner, déplacer ou faire pivoter des nœuds. Cependant, elle se concentre davantage sur les algorithmes de disposition automatique et les applications de la théorie des graphes. Elle est particulièrement adaptée aux logiciels nécessitant une personnalisation plus fine des fonctionnalités que les solutions prêtes à l’emploi.

La bibliothèque maxGraph n’utilise aucun logiciel tiers, ne nécessite aucun plugin et peut être intégrée à pratiquement n’importe quel framework (elle est en JavaScript natif).

maxGraph est le successeur de mxGraph, qui n’est plus maintenu. Initialement, elle propose les mêmes fonctionnalités que mxGraph, tout en ajoutant :

• Le support de TypeScript.
• Un package npm maintenu.
• Une version moderne, modulaire et tree-shakable de mxGraph, afin de réduire la taille totale du package.

Points clés :

1. maxGraph est une bibliothèque TypeScript moderne et légère.
2. Elle est conçue pour des applications nécessitant une personnalisation avancée et des algorithmes de graphes.
3. Elle est compatible avec tous les frameworks grâce à son utilisation de JavaScript natif.
4. Elle succède à mxGraph en apportant des améliorations comme le support de TypeScript et une architecture modulaire.

Voici un tableau de comparaison entre maxGraph et mxGraph .

Je vais comparer mxGraph (la bibliothèque originale) avec maxGraph.

Les évolutions d’un point de vue technique

J’ai vu des évolutions sur le nommage des composants, dans les fonctions.

Tableau 1 : Évolutions des noms de composants

Tableau 2 : Évolutions des noms de fonctions

Tableau 3 : Évolutions des noms d’événements

Tableau 4 : Évolutions des noms de styles et de propriétés

Remarques :

1. Ces évolutions sont basées sur des tendances courantes en matière de refactoring et de modernisation d’API.
2. Les évolutions visent souvent à simplifier les noms, à les rendre plus intuitifs et à les aligner sur les conventions modernes de développement.

Vous trouverez aussi d’autres informations sur la migration de MxGraph vers MaxGraph .

maxGraph APIs are not fully compatible with mxGraph APIs. The concepts are the same, so experienced mxGraph users should be able to switch from mxGraph to maxGraph without issues.

For a complete guide, see the dedicated migration page.