Tutoriel pour apprendre les nouveautés de Laravel 5.5

Maurice Chavelli

À chaque semestre, sa nouvelle version importante de Laravel. Certains disent que c'est trop rapide, mais personne n'est obligé de suivre ce rythme ! Alors voici que se profile la version 5.5 qui est annoncée pour le mois de juillet et sera LTS. La copie est assez avancée pour pouvoir faire un peu le point. Si vous aimez la langue anglaise, vous avez une description de toutes les nouveautés sur le site officiel. Sinon je vous en fais ici un petit résumé dans notre langue préférée !

Commentez

- Titre : Tutoriel pour apprendre les nouveautés de Laravel 5.5

- Auteur : Maurice Chavelli

- Parution : 5 janvier 2018

- Licence : Copyright ® 2018 Laravel. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. PHP 7

- II. Les erreurs

- II-A. Les pages d'erreurs

- II-B. Les helpers throw_if et throw_unless

- III. Retour des données de la validation

- IV. La commande migrate:fresh

- V. La commande vendor:publish

- VI. Les mails

- VI-A. Les thèmes

- VI-B. Le rendu dans le navigateur

- VII. Le frontend

- VIII. Whoops

- IX. Chargement des packages

- X. Conclusion

- XI. Remerciements

I - PHP 7

La première grande nouveauté est la version minimale de PHP qui est désormais la 7 :

1. "require": {

2. "php": ">=7.0.0",

3. "laravel/framework": "5.5.*",

4. ...

Donc si vous voulez passer à cette version de Laravel, il faudra peut-être mettre à jour votre serveur !

Le principal intérêt se trouve au niveau des performances parce que cette version de PHP est vraiment plus rapide. Mais ce n'est pas le seul avantage, vous trouvez la liste des nouveautés dans le manuel PHP.

II - Les erreurs

II-A - Les pages d'erreurs

L'aspect des pages d'erreur par défaut (donc pour 404, 419, 500 et 503) a été relooké. C'est un changement purement cosmétique, mais ça fait du bien aux yeux :

Mais on peut évidemment créer son propre aspect comme dans les versions précédentes en créant un dossier resources/views/errors et en nommant les fichiers blade avec le numéro de l'erreur.

II-B - Les helpers throw_if et throw_unless

Deux nouveaux helpers apparaissent :

1. $foo = false;

2. throw_if($foo, new MonException('Foo est faux'));

3. // ou

4. throw_if($foo, MonException::class, 'Foo est faux');

6. $foo = true;

7. throw_unless($foo, new MonException('Foo est faux'));

8. // ou

9. throw_unless($foo, MonException::class, 'Foo est faux);

III - Retour des données de la validation

Laravel offre la puissante méthode validate pour valider les données :

1. public function store(Request $request)

2. {

3. $this->validate($request, [

4. 'title' => 'required|unique:posts|max:255',

5. 'body' => 'required',

6. ]);

8. return Post::create($request->all());

9. }

La méthode jusque là ne retournait aucune valeur. Désormais elle va retourner les données de la requête. Du coup on pourra écrire :

1. public function store()

2. {

3. $data = $this->validate(request(), [

4. 'title' => 'required|unique:posts|max:255',

5. 'body' => 'required',

6. ]);

8. return Post::create($data);

9. }

Il faut évidemment que toutes les données passent par la validation, quitte à ne préciser aucune règle.

Personnellement j'utilise principalement des requêtes de formulaire et cette possibilité me laisse assez indifférent. D'autre part elle ne me paraît pas être d'un très grand intérêt.

IV - La commande migrate:fresh

Voici l'annonce officielle de cette commande.

Vous utilisez sans doute souvent la commande migrate:refresh. Elle permet de revenir à zéro pour repartir sur une migration toute fraîche. Mais pour que ça fonctionne, il faut prévoir des méthodes down dans les migrations pour définir le retour en arrière.

Avec la commande migrate:fresh plus besoin de méthode down, les tables sont purement et simplement supprimées et les migrations relancées. On peut lui adjoindre l'option -seed pour remplir les tables. Voilà une commande que je vais beaucoup utiliser !

V - La commande vendor:publish

Voilà une commande qui m'a souvent agacé parce que telle quelle, elle publie tout ce qu'elle trouve et ce n'est pas toujours judicieux !

Désormais lorsque vous utiliserez cette commande sans préciser de provider, vous aurez la liste de tous les providers et vous pourrez choisir celui que vous voulez publier !

Voici une animation bien faite pour cette commande :

VI - Les mails

VI-A - Les thèmes

La gestion des mails a bien progressé dans les dernières versions de Laravel, par exemple avec la possibilité d'utiliser le marquage Markdown. Cette fois on va pouvoir utiliser des thèmes. Dans la version 5.4, il y a un thème par défaut. On n'est pas obligé de l'utiliser, mais ça oblige à quelques changements : créer évidemment son propre CSS :

resources/views/vendor/mail/html/themes/mon-theme-a-moi.css

et aussi informer Laravel (config/mail.php) :

1. /*

2. |--------------------------------------------------------------------------

3. | Markdown Mail Settings

4. |--------------------------------------------------------------------------

5. |

6. | If you are using Markdown based email rendering, you may configure your

7. | theme and component paths here, allowing you to customize the design

8. | of the emails. Or, you may simply stick with the Laravel defaults!

9. |

10. */

12. 'markdown' => [

13. 'theme' => 'mon-theme-a-moi',

15. 'paths' => [

16. resource_path('views/vendor/mail'),

17. ],

18. ],

Ce n'est pas bien compliqué, mais la version 5.5 nous simplifie un peu plus la vie !

Il faut encore évidemment créer le fichier CSS, mais pour sa déclaration ça se passe directement dans la classe Mailable :

1. class MonMailAMoi extends Mailable

2. {

3. protected $theme = 'mon-theme-a-moi';

4. ...

5. }

VI-B - Le rendu dans le navigateur

Lorsqu'on développe un thème, ça dure évidemment un moment et on fait plein de réglages. On ne va pas chaque fois envoyer réellement un mail pour vérifier le rendu. Il existe des solutions, mais aucune de vraiment simple et directe.

Avec Laravel 5.5, on peut visualiser le mail directement dans le navigateur. Il suffit d'ajouter une route :

Route::get('/demo', function () {
return new App\Mail\MonMailAMoi();
});

Et c'est tout !

Ça peut d'ailleurs donner d'autres idées d'utilisation…

VII - Le frontend

Le frontend a connu une évolution un peu houleuse au cours des versions. Avec Laravel 5.5 ça devient plus modulable et rien n'est imposé. On a toujours Bootstrap et Vue.js par défaut, mais on peut facilement (avec Artisan) changer pour React. Je suppose que ça va encore évoluer avec d'autres propositions.

VIII - Whoops

Ceux qui ont utilisé Laravel 4 doivent se souvenir de la fenêtre d'affichage des erreurs Whoops :

Eh bien, on va retrouver cette sympathique bibliothèque dans la version 5.5 !

IX - Chargement des packages

Taylor a présenté récemment une nouvelle fonctionnalité pour l'installation des packages. On est tous habitués à effectuer toujours les mêmes opérations pour installer un package :

- utilisation de composer ;

- déclaration du service providers dans la configuration ;

- déclaration éventuelle de la façade dans la configuration.

Avec la version 5.5, on pourra se contenter de composer, le reste sera reconnu automatiquement si le package est configuré pour ça !

X - Conclusion

Laravel 5.5 ne nous apporte pas des changements très importants, mais se présente plutôt comme l'aboutissement de la série 5.

XI - Remerciements

Nous remercions Maurice Chavelli qui nous a autorisés à publier ce tutoriel.

Nous remercions également Winjerome pour la mise au gabarit et Claude Leloup pour la relecture orthographique.