Phoenix est un framework de développement web écrit en Elixir qui implémente le modèle MVC (Model View Controller) côté serveur. Nombre de ses composants et concepts sembleront familiers à ceux d'entre nous qui ont l'expérience d'autres frameworks web tels que Ruby on Rails ou Django de Python. Phoenix offre le meilleur des deux mondes : une productivité élevée pour les développeurs et des performances élevées pour les applications. Il présente également quelques nouveautés intéressantes, comme des canaux pour l'implémentation de fonctionnalités en temps réel et des modèles précompilés pour une vitesse fulgurante.La version finale de Phoenix 1.7 est disponible ! Phoenix 1.7 contient un certain nombre de nouvelles fonctionnalités très attendues comme les routes vérifiées, le support de Tailwind, les générateurs d'authentification LiveView, les modèles HEEx unifiés, les flux LiveView pour des collections optimisées, et bien plus encore. Il s'agit d'une version rétrocompatible avec quelques dépréciations. La plupart des gens devraient être en mesure de mettre à jour juste en changeant quelques dépendances.
Note : Pour générer un nouveau projet 1.7, vous devrez installer le générateur phx.new de hex :
| Code : | Sélectionner tout |
mix archive.install hex phx_new
Les routes vérifiées remplacent les router helpers par une approche basée sur les sigils (~p) et vérifiée à la compilation.
note : Les routes vérifiées utilisent les nouvelles fonctionnalités du compilateur Elixir 1.14. Phoenix supporte toujours les anciennes versions d'Elixir, mais vous devrez les mettre à jour pour profiter des nouvelles fonctionnalités de vérification à la compilation.
En pratique, cela signifie que là où vous utilisiez auparavant des fonctions autogénérées comme :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | # router get "/oauth/callbacks/:id", OAuthCallbackController, :new # usage MyRouter.Helpers.o_auth_callback_path(conn, :new, "github") # => "/oauth/callbacks/github" MyRouter.Helpers.o_auth_callback_url(conn, :new, "github") # => "http://localhost:4000/oauth/callbacks/github" |
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | # router get "/oauth/callbacks/:id", OAuthCallbackController, :new # usage ~p"/oauth/callbacks/github" # => "/oauth/callbacks/github" url(~p"/oauth/callbacks/github") # => "http://localhost:4000/oauth/callbacks/github" |
Il y a aussi maintenant une correspondance 1:1 entre les routes que vous écrivez dans le routeur, et la façon dont vous les appelez avec ~p. Vous l'écrivez simplement comme si vous codiez des chaînes en dur partout dans votre application - sauf que vous n'avez pas les problèmes de maintenance qui viennent avec le codage en dur des chaînes. Nous pouvons obtenir le meilleur des deux mondes avec la facilité d'utilisation et de maintenance parce que ~p est une vérification à la compilation des routes dans votre routeur.
Par exemple, imaginons que nous fassions une faute de frappe sur une route :
| Code : | Sélectionner tout |
<.link href={~p"/userz/profile"}>Profile</.link>
| Code : | Sélectionner tout |
1 2 3 | warning: no route path for AppWeb.Router matches "/postz/#{post}"
lib/app_web/live/post_live.ex:100: AppWeb.PostLive.render/1 |
| Code : | Sélectionner tout |
~p"/posts/#{post.id}"
Les chaînes de requête sont également prises en charge dans les itinéraires vérifiés, soit sous la forme traditionnelle d'une chaîne de requête :
| Code : | Sélectionner tout |
~p"/posts?page=#{page}"
| Code : | Sélectionner tout |
1 2 3 | params = %{page: 1, direction: "asc"}
~p"/posts?#{params}" |
Une fois que vous aurez essayé cette nouvelle fonctionnalité, vous ne pourrez plus revenir aux router helpers. Les nouveaux générateurs phx.gen.html|live|json|auth utilisent des routes vérifiées.
Générateurs Tailwind basés sur des composants
Phoenix 1.7 est livré avec TailwindCSS par défaut, sans dépendance avec nodejs sur le système. TailwindCSS est le meilleur moyen que j'ai trouvé pour styliser les interfaces en 20 ans de développement web. Son approche axée sur l'utilité est bien plus facile à maintenir et plus productive que n'importe quel système ou framework CSS que j'ai utilisé. Son approche colocalisée s'aligne parfaitement avec le composant de fonction et le paysage LiveView.
L'équipe de Tailwind a également généreusement conçu la nouvelle page d'accueil du projet, les pages CRUD et les pages du système d'authentification pour les nouveaux projets, vous donnant un point de départ de première classe et poli pour la construction de vos applications.
Un nouveau projet phx.new contiendra un module CoreComponents, abritant un ensemble de composants d'interface utilisateur tels que des tables, des fenêtres modales, des formulaires et des listes de données. La suite de générateurs Phoenix (phx.gen.html|live|json|auth) utilise les composants de base. Cela présente un certain nombre d'avantages intéressants.
Tout d'abord, vous pouvez personnaliser les composants de base de l'interface utilisateur en fonction de vos besoins, de vos conceptions et de vos goûts. Si vous souhaitez utiliser Bulma ou Bootstrap au lieu de Tailwind, pas de problème ! Remplacez simplement les définitions de fonctions dans core_components.ex par vos implémentations spécifiques au framework/UI et les générateurs continuent à fournir un excellent point de départ pour de nouvelles fonctionnalités, que vous soyez un débutant ou un expert chevronné construisant des fonctionnalités de produit sur mesure.
En pratique, les générateurs vous donnent des modèles qui utilisent vos composants de base, qui ressemblent à ceci :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <.header>
New Post
<:subtitle>Use this form to manage post records in your database.</:subtitle>
</.header>
<.simple_form for={@form} action={~p"/posts"}>
<input field={@form[:title]} type="text" label="Title" />
<input field={@form[:views]} type="number" label="Views" />
<:actions>
<.button>Save Post</.button>
</:actions>
</.simple_form>
<.back navigate={~p"/posts"}>Back to posts></.back> |
Composants de fonction unifiés pour les contrôleurs et les LiveViews
Les composants de fonction fournis par HEEx, avec des affectations et des emplacements déclaratifs, constituent un changement radical dans la manière dont nous écrivons du HTML dans les projets Phoenix. Les composants de fonction fournissent des blocs de construction de l'interface utilisateur, permettant aux fonctionnalités d'être encapsulées et mieux étendues par rapport à l'approche précédente des modèles dans Phoenix.View. Vous bénéficiez d'une manière plus naturelle d'écrire des balises dynamiques, d'une interface utilisateur réutilisable qui peut être étendue par l'appelant, et de fonctions de compilation qui font de l'écriture d'applications HTML une expérience de premier ordre.
Les composants de fonction apportent une nouvelle façon d'écrire des applications HTML dans Phoenix, avec de nouveaux ensembles de conventions. En outre, les utilisateurs ont eu du mal à combiner les fonctionnalités Phoenix.View basées sur les contrôleurs avec les fonctionnalités Phoenix.LiveView dans leurs applications. Les utilisateurs se sont retrouvés à écrire render("table", user : user) dans des modèles basés sur des contrôleurs,...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.