https://d226lax1qjow5r.cloudfront.net/blog/blogposts/new-year-new-rails/new-year_new-rails.png

Nouvelle année, nouveaux rails

Publié le January 31, 2022

Temps de lecture : 7 minutes

Le début d'une nouvelle année est souvent considéré comme le moment de réinventer l'entreprise. self. Prendre un abonnement à la salle de sport, manger plus sainement, apprendre une nouvelle langue, etc. Je n'ai jamais vraiment été un fan des résolutions du type "nouvelle année, nouveau toi", mais d'après mes premières impressions, je suis certainement un fan de "nouvelle année, nouveau Rails".

D'accord, la partie "nouvelle année" n'est pas entièrement exact ; Rails 7.0 est sorti à la fin de l'année dernière, le 15 décembre. Nous avons déjà eu une version 7.0.1 pour prendre en charge Ruby 3.1. La partie "nouveau Rails" semble toutefois exacte. Une mise à jour majeure apporte toujours un sentiment de nouveauté, mais Rails 7.0 va plus loin. Il s'agit d'un changement audacieux et passionnant par rapport aux versions précédentes.

Au cours des premières années d'existence de Rails, son recours à la convention plutôt qu'à la configuration, et à des valeurs par défaut basées sur l'opinion en termes d'outils et de composants, a été considéré comme quelque peu controversé. Ces principes clés de l'approche Rails, qui ont finalement fait partie de Doctrine Railssont aussi ce qui a attiré de nombreux développeurs vers le framework. Bien sûr, il fallait se familiariser avec les valeurs par défaut et apprendre les conventions, mais une fois que c'était fait, c'était tout simplement un plaisir de travailler avec Rails. Cette approche globale soutient le premier pilier de la Doctrine Rails : Optimiser pour le bonheur des programmeurs.

L'une des forces de Rails en tant que framework a été sa capacité à évoluer avec le paysage technologique en constante mutation. Au cours des dernières années, une grande partie de ce changement a eu lieu sur le front-end, où un désir d'interfaces réactives a conduit à l'augmentation des Applications à Page Unique (SPA) et le déplacement associé de la logique d'application du serveur vers le client. L'un des effets de cette évolution a été d'ajouter de la complexité au processus de développement frontal en termes de gestion des dépendances, de transpilation, de regroupement des actifs, etc. Depuis Rails 5.2, la réponse à la gestion de cette complexité frontale a été Webpacker.

Webpacker suscite-t-il la joie ?

Bien que Webpacker fasse abstraction d'une partie de la complexité de la gestion des dépendances et de la configuration du front-end, il a toujours semblé être une solution de contournement, bien que nécessaire. C'était un moyen d'accrocher une application Rails à l'écosystème frontal existant plutôt qu'une solution frontale intégrée. C'est bien quand tout fonctionne, mais on peut toujours se retrouver à devoir gérer des problèmes complexes de dépendances de paquets Node ou à déboguer diverses erreurs de compilation - ce n'est probablement pas le genre de choses sur lesquelles la plupart des développeurs Rails veulent passer trop de temps.

Il semble que l'équipe de Rails ait adopté l'approche de Marie Kondo de Webpacker car, dans Rails 7, il a disparu. La l'idée qui sous-tend cette décision est basée sur des avancées récentes dans l'environnement web et internet au sens large, à savoir la prise en charge désormais universelle de ES6 par les navigateurs, combinée à l'adoption généralisée de HTTP/2. Le premier supprime le besoin de transposer le code ES6 en ES5, et les capacités de multiplexage du second atténuent l'effet de latence lié à la demande de plusieurs petits fichiers au lieu d'un seul gros "paquet".

Vous vous dites peut-être "mais j'ai encore besoin de tous mes paquets Node, comment puis-je les obtenir ? La réponse à cette question est importer des cartescombinées à des CDN qui peuvent servir les modules ES, comme Skypack ou JSPM. Cette combinaison supprime le besoin d'outils de construction ou même d'avoir Node installé localement. La importmap-rails geminclus par défaut dans Rails 7, permet essentiellement de faire correspondre des "spécificateurs de modules nus" à une source de chargement de ce module. Vous définissez la configuration de votre importmap dans un fichier config/importmap.rb fichier. Les modules spécifiques sont demandés au moment de l'exécution, au fur et à mesure des besoins de certaines mises en page, par l'intermédiaire d'une balise <script> de type "importmap" dans l'élément <head> de cette présentation. Plutôt génial !

Cette approche ne conviendra pas à tout le monde. Certains développeurs voudront utiliser React avec JSX ou utiliser Typescript, et auront donc toujours besoin d'une étape de compilation/transpilation et de la capacité de s'accrocher à l'écosystème Node. Eh bien, vous pouvez toujours le faire dans Rails 7. La jsbundling-rails gem vous permet d'utiliser esbuild, rollup.js, ou Webpack pour compiler votre JavaScript et ensuite le livrer via le pipeline d'actifs dans Rails.

Bien que certains développeurs continueront à vouloir utiliser ce type d'approche séparée front-end / back-end, le message de Rails 7 est que pour la plupart des cas d'utilisation, vous n'avez pas nécessairement besoin d'une sorte de framework front-end lourd ou de beaucoup de JavaScript personnalisé sur le front-end pour fournir une expérience utilisateur réactive dans le navigateur. Vous pouvez fournir cette expérience en utilisant une architecture d'application beaucoup plus unifiée en utilisant Hotwire.

Hotwire, c'est du rail

Hotwire n'est pas complètement nouveau - il pouvait être utilisé dans Rails 6 avec une certaine configuration - mais c'est maintenant l'approche par défaut dans Rails 7. Hotwire, développé par les équipes de Basecamp et Hey, est composé de trois bibliothèques : Turbo, Stimulus et Strada, qui n'est pas encore disponible.

Turbo

Turbo se charge de la plupart des tâches lourdes. Il utilise le rendu côté serveur (SSR) pour envoyer du HTML par câble au lieu de JSON, ce qui supprime la nécessité d'un rendu, d'une gestion d'état, etc. sur le front-end. Turbo combine plusieurs concepts et techniques complémentaires.

  • Conduite : Intercepte les clics sur les liens et les soumissions de formulaires, émet une demande de nouveau contenu et rend la réponse HTML. fetch demande le nouveau contenu et rend la réponse HTML.

  • Cadres : Permet de diviser une vue en parties ou composants individuels de sorte que les clics sur les liens ou les soumissions de formulaires ne rafraîchissent que des parties spécifiques de la page web au lieu de recharger toute la page.

  • Flux : Permet de rafraîchir partiellement les pages en réponse à des actions asynchrones envoyées par WebSocket ou par un événement envoyé par le serveur.

Tout cela peut sembler être une fonctionnalité SPA assez standard. La principale différence avec Turbo est que la logique de toute cette réactivité frontale n'est pas séparée dans un framework distinct boulonné sur le devant de votre application Rails. Au contraire, elle se trouve directement dans vos modèles, vues et contrôleurs Rails, en utilisant des conventions claires, logiques et élégantes.

Cet article n'est pas un tutoriel, je n'entrerai donc pas dans les détails de ces conventions ici, mais n'oubliez pas de consulter le Turbo Turbo et les référence du développeurainsi que le README pour l'implémentation Rails de Turbo, turbo-rails.

Stimulus

Stimulus se présente comme un "cadre JavaScript aux ambitions modestes" et est destiné à compléter Turbo. Il s'appuie fortement sur les attributs de données HTML, en utilisant des objets JavaScript appelés contrôleurs pour répondre aux événements du navigateur déclenchés par des éléments ayant un attribut data-controller ou en associant des actions spécifiques à des événements DOM à l'aide d'attributs data-action à l'aide d'attributs Là encore, je n'entrerai pas dans les détails ici, mais vous pouvez en savoir plus dans le Stimulus Manuel, référence du développeuret le README pour l'implémentation Rails de Stimulus stimulus-rails.


Hotwire est conçu pour être agnostique. Mais il a beaucoup de sens dans un contexte Rails, en particulier compte tenu de la façon dont les implémentations Rails des bibliothèques s'intègrent à ActiveRecord. Par exemple, vous pouvez utiliser un broadcasts_to dans vos modèles pour mettre en place divers rappels qui publient sur un canal nommé particulier, disons :todo_listlorsque des modifications sont apportées aux données dans le contexte de ce modèle (c'est-à-dire par des actions de création, de mise à jour ou de destruction).

class Todo < ApplicationRecord
  broadcasts_to :todo_list
end

Vous pouvez ensuite configurer les éléments Turbo Stream pour qu'ils s'abonnent à la :todo_list diffusion. Ces éléments sont mis à jour de manière appropriée lorsque les données sont modifiées. Toute personne consultant une page contenant un élément de flux abonné à cette diffusion particulière verra son navigateur mettre à jour cet élément de la page en temps réel.

Cette fonctionnalité utilise en arrière-plan ActionCablequi est depuis longtemps un composant de Rails, en arrière-plan. Ce que fait turbo-rails permet de tout relier de manière logique et accessible.

Pour moi, le point fort de Hotwire est qu'il ressemble à Rails. Il fait abstraction d'une grande partie de la complexité du front-end grâce à une approche innovante et à quelques conventions solides. Cela a toujours été la façon de faire de Rails, et son intégration dans Rails 7 semble adhérer beaucoup plus étroitement à la doctrine de Rails que le compromis Webpacker n'a jamais pu le faire.

Autres faits marquants

Bien que le changement qui fait la une de Rails 7 soit la nouvelle approche par défaut pour travailler avec le front-end, il y a aussi quelques changements notables en termes de back-end. Les plus intéressants d'entre eux concernent divers aspects du travail avec les données.

  • Active Record Encryption fournit une couche supplémentaire de sécurité en ajoutant des attributs cryptés. attributs cryptés à ActiveRecord.

  • Le chargement parallèle des requêtes permet d'améliorer les performances dans les situations où les actions de votre contrôleur doivent charger simultanément plusieurs requêtes non liées.


Personnellement, je suis très enthousiaste à propos de Rails 7 et j'ai hâte de construire des choses intéressantes cette année en utilisant Rails 7 et les API de Vonage. J'aimerais savoir ce que vous pensez de Rails 7 ! Faites-le moi savoir sur sur Twitter.

Partager:

https://a.storyblok.com/f/270183/373x376/e8d3211236/karl-lingiah.png
Karl LingiahDéveloppeur Ruby Advocate

Karl est un défenseur des développeurs pour Vonage, qui se concentre sur la maintenance de nos SDK de serveur Ruby et sur l'amélioration de l'expérience des développeurs pour notre communauté. Il aime apprendre, fabriquer des objets, partager ses connaissances et tout ce qui a trait à la technologie du web.