Remix JS : c’est quoi ?

A quoi servent Next JS et Remix

Comme vous le savez surement, React sert - pour simplifier les choses - à transformer un état en interface utilisateur.

On a des données en entrée, une fonction de rendu en JS, et une sortie HTML.

Le fait de déporter de la logique côté client permet une expérience utilisateur plus fluide - puisqu’on n’a pas besoin de faire d’aller-retour avec le serveur pour absolument toutes les mises à jour d’état.

Mais, par contre… le rendu côté client rend plus difficile le référencement par les robots des moteurs de recherche.

Pour pallier ce problème, il existe des solutions qui proposent de déporter cette logique côté serveur pour le rendu initial.

C’est le principe de Next JS, dont je vous ai déjà parlé dans une vidéo précédente. Et Remix répond au même problème de manière similaire, avec une première phase de rendu côté serveur.

On obtient comme ça le meilleur des deux mondes, avec un rendu initial qui est fait côté serveur et optimisé en SEO. Puis des rendus ultérieurs qui sont faits côté client sur les navigateurs, et qui fournissent donc une expérience utilisateur optimale.

Mais du coup, qu’apporte Remix ? Quel est le besoin que NextJS n’adresse pas et que Remix adresse ?

Quelles sont les particularités de Remix ?

D’une certaine façon, Remix profite du fait d’être né récemment.

Remix construit sur les nouveautés des dernières versions de React.

Plus exactement, de la direction que prend React, parce que Remix semble avoir pris cette direction avant même que React ne la prenne publiquement.

(Pour info je suis allé un peu plus en détail sur les nouveautés de React 18 dans une autre vidéo.)

Par exemple, la façon dont Remix structure des composants est très proche des composants serveur React. Avec une séparation dans la nomenclature entre ce qui est du domaine du serveur et ce qui est du domaine du client.

L’équipe de Remix décrit leur solution comme étant 4 choses :

• un compilateur
• un gestionnaire de requête HTTP
• un framework serveur
• un framework client

Ils décrivent même leur solution comme étant « un compilateur pour React Router ». Et je vais m’arrêter un peu sur cette phrase.

Qu’est-ce qu’elle veut dire en pratique?

Il faut préciser, avant d’aller plus loin, que Remix est crée par l’équipe de React Router.

Et quand on lit leur documentation technique ils ne sont visiblement pas des néophytes, on sent qu’ils connaissent intimement React.

Ils utilisent React Routeur pour lier une route, une URL en gros, avec un composant React.

Chaque élément de la route, du chemin, est associé à un composant.

Imaginons par exemple qu’on ait une route /shop/classes/42

Cette route sera liée à un composant <Shop>, dans lequel il se trouve un composant <Classes> dans le quel se trouve un composant <Class> qui va rendre l’info pour l’élément 42.

(Alors petite parenthèse, pour être précis : Ici j’ai calqué l’URL sur la nomenclature des composants pour rendre l’exemple plus lisible. Mais en réalité dans Remix comme dans Next JS d’ailleurs, c’est la nomenclature des fichiers et des dossiers qui fait le lien, pas à proprement parler celui des composants).

Revenons à nos moutons.

L’idée c’est que chaque composant sait récupérer les informations dont il a besoin pour s’afficher. Mais c’est ici que joue l’intelligence de Remix, et le fait que Remix soit décrit comme un compilateur pour React Routeur :

Dans notre exemple de boutique avec des classes, on a un composant dans un composant dans un composant, où chacun a besoin de récupérer une information pour s’afficher.

Si chaque composant est responsable de récupérer ses propres informations, on aura une belle séparation des responsabilités mais aussi une grosse chaine d’aller retours réseau successif.

Le premier composant se charge, récupère ses infos, fait le rendu du deuxième composant, qui se charge, et qui récupère donc ses infos, et ainsi de suite. Au final ça ferait une chaine qui prend du temps.

Alors évidemment, dans un React “classique”, on va surtout avoir tendance (du coup) à récupérer toute l’information nécessaire en haut de la chaine et de la faire redescendre.

C’est moche, ça ne respecte pas vraiment la “separation of concerns”, la répartition des responsabilités. Mais bon, au moins… ça fonctionne dans un temps raisonnable.

Dans Remix, chaque fichier de composant comporte trois parties (dans un même fichier).

Il y a bien sur la fonction de rendu du composant, de manière classique.

Et puis deux fonction optionnelle de transfert de données.

• une fonction nommée “action” qui sert à traiter côté serveur les informations envoyées par le client, par exemple les données d’un formulaire.
• et surtout fonction du nom de loader, qui sert à récupérer les données dont a besoin le composant pour rendre ; par exemple en base de données ou sur le système de fichiers

Et donc ici, au moment de faire le rendu, Remix va récupérer chacun des loader qui correspondent à l’arbre des composants de la route appelée, et va lancer simultanément tous les chargements utiles.

C’est pour ça que Remix est un compilateur pour React Routeur : le routeur est imbriqué avec la chaine de rendu.

Et c’est ici qu’on voit la plus grosse différence entre Next JS et Remix.

Dans Next JS il faut appréhender tout un mécanisme avec sa logique propre, entre les getStaticProps et les getStaticPaths et les getServerSideProps.

Et ces méthodes provoquent quelques interrogations et confusions dans les différents forums et groupes que j’ai pu consulter. Des questions qui montrent que le rôle et le contexte de ces fonctions n’est pas clair pour tous.

Remix, par contre, simplifie. Non pas au niveau technique, mais au niveau des concepts.

Le routage est construit à partir de l’arborescence des fichiers. La récupération des données et la soumission sont regroupés avec les composants qui les soumettent, pas dans un dossier API à part. Et d’ailleurs la soumission de formulaire ne passe pas par du code ou des méthodes spécifiques mais par des normes du HTML.

Ce qui permet à Remix de dire qu’il n’y a pas là un n-ième framework à apprendre, mais simplement des fonctionnement normaux et normés de formulaires HTML ou de fonction JS de base.

Que c’est donc un bon investissement en temps d’apprendre ce framework, puisque ce n’est pas du spécifique.

Et que c’est ce qui permet même à Remix de fonctionner dans des environnements clients où le JavaScript est désactivé.

Mais tous ces avantages viennent tout de même avec certains inconvénients.

Pour ma part, dans ma façon de l’utiliser, un des grands avantages de Next JS est sa capacité de générer du HTML statique.

Et ce HTML statique va ensuite prendre un comportement dynamique grâce à React.

Et malheureusement Remix ne permet pas cela.

Pour mon cas d’usage personnel, aujourd’hui, Next JS fait bien l’affaire, et Remix ne répondrait pas à mes besoins. Peut-être un jour, mais our le moment il est trop jeune pour ça.

Mais par contre Remix est plus propre, plus moderne, mieux conçu, avec moins de fonctionnement spécifique. ET il anticipe les nouveautés de React.

Ce qui fait qu’aujourd’hui, si on me demande lequel apprendre, j’aurais tendance à plutôt conseiller, en moyenne, Remix.

Même si ça ressemble - c’est vrai - un peu à du “faites ce que je dis, pas ce que je fais”.

ET puis bon, soyons honnêtes, Next JS reste un très bon choix. Et la présence d’un peu de concurrence ne peut que l’inciter à s’améliorer encore.

Bref, on a là un environnement passionnant qui n’a de cesse d’évoluer.

Alors si vous avez envie de continuer à apprendre, et bien justement, on se retrouve dans cette prochaine vidéo.