Довгоочікуваний Laravel 5.5 – нова LTS (реліз з довгостроковою підтримкою) версія фреймворку. Попередній LTS реліз було випущено у середині 2015 року.
Whoops
Whoops – це PHP фреймворк для обробки помилок, він вже з'являвся у старших версіях Laravel. Тепер його буде включено до фреймворку «з коробки», і тому він не матиме залежностей. Whoops групує винятки і помилки, представляючи їх у відсортованому вигляді та зручному інтерфейсі.
Він спрощує пошук помилок і винятків, відображаючи сегмент коду, в якому вони виникли. Він підтримує JSON, XML, AJAX, а також підсвічує синтаксис.
Прапорці 'vendor:publish'
У попередніх версіях Laravel, команда vendor:publish повертала у термінал представлення, конфіги, міграції та інші ресурси від усіх вендорів. Але у Laravel 5.5 ця команда запропонує вам обрати вендорів або теги. Ви також можете обійти його вказавши після publish прапорець --all, або --provider.
Стилізація поштової розсилки
У Laravel 5.5 було додано можливість створити власний стиль макету електронної пошти. Ви можете задати CSS стиль властивість вашого класу, відповідального за макет електронної пошти.
Уявіть, що ви створюєте застосунок, в якому вам необхідно надсилати повідомлення електронною поштою користувачам та адміністраторам вашої організації. Щоб такі листи отримали кастомний зовнішній вигляд, просто створіть CSS стиль і вкажіть його як властивість класу:
resources/views/vendor/mail/html/themes
Тепер просто визначте $theme у тілі класу розсилки вашим користувачам.
class SendInvoice extends Mailable
{
protected $theme = 'my-style';
/*...*/
}
Відображення поштових макетів у браузері
Тестування макетів електронної пошти може займати багато часу, тож найліпший спосіб – переглянути їх у браузері, щоб можна було внести загальні правки. Laravel 5.5 має об'єкт для відображення поштових макетів безпосередньо засобами маршрутизації.
Ви можете створити макет:
php artisan make:mail UserWelcome --markdown=emails.user.subscription.canceled
Відобразити макет через маршрут:
Route::get('/no/way', function () {
return new App\\Mail\\UserSubscriptionCanceled();
});
Перезавантаження міграцій
Laravel 5.5 отримав нову Artisan команду для migrate:..., вона подібна до migrate:refresh, але замість відкату існуючих міграцій вона знищить всі таблиці та почне міграцію з нуля. Різниця між відкатом міграції та знищенням полягає у тому, що migrate:refresh застосовує drop до кожної таблиці, а migrate:fresh до всіх міграцій одночасно і відбудовує їх з початку.
Автоматичний пошук пакетів
У попередніх версіях фреймворку отримання пакету вимагало реєстрації його постачальників та додання псевдонімів. Laravel 5.5 додає можливість автоматичної реєстрації пакетів через composer.json:
"extra": {
"laravel": {
"providers": [
"The\\\\Dark\\\\Knight\\\\BatmanServiceProvider"
],
"aliases": {
"Bar": "The\\\\Dark\\\\Knight\\\\Batman"
}
}
}
Пресети для фронтенду
Laravel містить деякі CSS та JavaScript заготовки, щоб пришвидшити роботу з тривіальними завданнями. Не дивлячись на це ви можете почати з нуля за вашим власним бажанням, така можливість обмежувалася лише Vue.js. Laravel 5.5 включає 3 фронтенд пресети: Bootstrap, Vue, React, і надає можливість обрати той, що вам до вподоби.
Ви можете змінити пресет командою:
php artisan preset react
Щоб змінити пресет за вашим бажанням, замініть react на vue, bootstrap, тощо.
Редизайн стандартних помилок
Laravel 5.5 отримав новий дизайн для помилок типу 404, 50*: тепер ці сторінки матимуть відцентровані помилки та успадкують шрифт від базової сторінки Laravel.
Гнучкі звіти
Laravel 5.5 додає підтримку визначення методів, які відповідають за винятки та помилки. У Laravel 5.4 вам доводилося перевіряти метод обробника якщо викидалося окреме повідомлення. Тож якщо вам доводилося надсилати лист про помилку на електронну пошту, то ви робили щось схоже:
class Handler extends ExceptionHandler
{
...
public function report(Exception $exception)
{
if ($exception instanceof CustomException) {
// Send email
}
parent::report($exception);
}
}
Але, використовуючи Laravel 5.5, ви можете позбутися цього і зареєструвати метод звіту на своєму спеціальному класі винятків. Фреймворк перевіряє, чи існує метод звітування у класі винятків, і якщо це так, то викликає метод.
Спрощена валідація запиту
Додано можливість прямого виклику методу підтвердження на екземплярі Request, замість використання контролеру. Тож тепер нема потреби у передачі запиту як аргументу методу.
public function store()
{
request()->validate([
'title' => 'required',
'body' => 'required'
]);
return Post::create(request(['title', 'body']));
}
Друга зміна полягає в тому, що валідатор повертає дані запиту. Ви можете зберігати їх у змінній, і передавати методу створення моделі.
public function store()
{
$post = request()->validate([
'title' => 'required',
'body' => 'required'
]);
// $data = request()->only('title', 'body');
return Post::create($post);
}
Слід бути обережним з таким підходом, бо дані повернені валідатором будуть містити лише поля, визначені правилами валідації. Це підвищує захищеність, проте ви можете втратити дані, у разі відсутності правила. Щоб запобігти цьому, вам слід додати поле з порожнім правилом:
public function store()
{
$post = request()->validate([
'title' => 'required',
'body' => 'required',
'fieldWithNoRules' => '',
'andAnotherOne' => ''
]);
// $data = request()->only('title', 'body');
return Post::create($post);
}
Допоміжні функції винятків
Дві нові функції throw_if і throw_unless покликані полегшити роботу з винятками. Якщо ви хочете викинути винятки базуючись на умові, вони допоможуть вам позбутися нагромадження коду. Вони обидва приймають три аргументи, перший – булева функція, другий – клас винятків, і третій – повідомлення, яке буде показано у разі, якщо не було задоволено умову другого аргументу.
throw_if викидає виняток якщо boolean позитивний.
$foo = true;
throw_if($foo, new BarException('Foo is true'));
// or
throw_if($foo, BarException::class, 'Foo is true');
throw_unless викидає виняток якщо boolean негативний.
$phoo = false;
throw_unless($phoo, new BazException('Phoo is false'));
// or
throw_unless($phoo, BazException::class, 'Phoo is false');
Власні правила валідації
Laravel 5.5 дає змогу створити окремий клас для обробки валідації. Щоб визначити власне правило валідації, вам необхідно створити клас, який містить два методи: passes та message. Ви можете розмістити його у будь-якому місці додатку, наприклад App/Rules. Обраний метод приймає два аргументи: атрибут і значення, які ви можете використати, щоб перевірити поле.
namespace App\\Rules;
use Illuminate\\Contracts\\Validation\\Rule;
class CustomRule implements Rule
{
/**
* Перевірка проходження правил валідації
*
* @param string $attribute
* @param mixed $value
* @return bool
*/
public function passes($attribute, $value)
{
// потрібно повернути статус валідації
}
/**
* Отримання повідомлення про помилку.
*
* @return string
*/
public function message()
{
// повернення рядка про стан помилки
}
}
Ваше правило має використовувати Illuminate\\Contracts\\Validation\\Rule. Ви можете користуватися правилом будь-де, як запит до форми, або в контролері, а також ви можете включати будь-які залежності в конструктор. Якщо ви використовуєте його так, то ви не зможете передати строку з правилами розділеними комою. Вам необхідно передавати кожне правило як окремий елемент масиву.
$request->validate([
'someField' => [
'required', 'min:4', new CustomRule()
]
]);
Генератори моделей
В Laravel 5.5 ви можете легко створювати генератори моделей новою Artisan командою make:factory:
php artisan make:factory PostFactory
Команда створить новий файл PostFactory.php в директорії database/factories.
Також дозволяється створення фабрики разом з моделлю.
php artisan make:model Post -f
Якщо додати прапор -c то ви отримаєте контролер, -m - міграцію.
Робота з колекціями
У попередніх версіях Laravel при відлагодженні колекцій доводилося прив'язувати змінна до колекції та оновлювати її при внесенні змін у колекцію. Оскільки тепер можливо викликати dd() та dump() безпосередньо на колекції, то про такий підхід можна забути.
Припустимо, дано колекцію постів, які проходять ряд трансформацій під час редагування, тож нам необхідно перевірити колекцію на кожному окремому кроці.
Приклад:
$posts = Post::all();
$posts
->dump()
->sorBy('title')
->dump()
->pluck('title')
->dump();
Отримаємо:
Collection {#284 ▼
#items: array:3 [▼
0 => Post {#285 }
1 => Post {#286 }
2 => Post {#287 }
]
}
Collection {#272 ▼
#items: array:3 [▼
0 => Post {#285 }
2 => Post {#287 }
1 => Post {#286 }
]
}
Collection {#268 ▼
#items: array:3 [▼
0 => "Aida Bosco"
1 => "Madge Leuschke"
2 => "Miss Bulah Armstrong Jr."
]
}
Такий метод спрощує відстеження контенту колекції на кожному кроці. Зауважте, що у будь-якому випадку існує різниця між викликом dump() та dd() на колекції.
dump() показує результат в момент виклику і продовжує обробку, у той час, як dd() зупиняє обробку негайно, і відображає тільки результат. Ми викликали dd() на колекції в кожному кроці, тож ми отримали результат кожного окремого виклику.
Підсумовуючи описане вище:
$posts = Post::all();
$posts
->dump()
->sorBy('title')
->dd()
->pluck('title')
->dump();
Вивід буде іншим:
Collection {#284 ▼
#items: array:3 [▼
0 => Post {#285 }
1 => Post {#286 }
2 => Post {#287 }
]
}
array:3 [▼
0 => Post {#285 }
2 => Post {#287 }
1 => Post {#286 }
]
Відношення багато до багатьох
Зазвичай, існує можливість декларування поля casts в моделі, яка визначає як атрибут буде зчитано, або збережено. Наприклад, існує модель Post, і ми хочемо провести серіалізацію одного поля у JSON під час читання або запису таким чином:
class Post extends Model
{
[...]
protected $casts = [
'somefield' => 'array',
];
[...]
}
Існує можливість використання власних опорних точок у відношеннях багато-до-багатьох, але вона обмежена читанням даних. Якщо б ми хотіли виконати операції запису даних, то нам спочатку довелося перенести значення атрибута перед збереженням. Але тепер attach, sync та save будуть доступні моделі.
Власні директиви Blade
Blade – це вбудований шаблонізатор Laravel, у новій версії він отримав можливість абстракції шаблонних перевірок, це дозволить зробити код чистішим та читабельнішим.
Приклад:
@if (auth()->check() && auth()->user()->isSubscribed())
<p>Subscribed</p>
@else
<p>Not Subscribed</p>
@endif
Можна замінити на:
@subscribed
<p>Subscribed</p>
@else
<p>Not Subscribed</p>
@endsubscribed
Деякі перевірки вимагають передачі аргументу для якогось методу. У такому випадку ми передаємо аргумент директиві blade.
@if (auth()->check() && auth()->user()->isFollowing($user->id))
У приведеному вище прикладі ми передаємо $user->id як аргумент isFollowing(), щоб створити власну директиву blade.
Blade::if('following', function (User $user) {
return auth()->check() && auth()->user()->isFollowing($user->id)
});
І тепер ми зможемо використати нову директиву в шаблоні:
@following($user)
<p>Following</p>
@else
<p>Not Following</p>
@endfollowing
Додатково
Laravel отримав багато впроваджень і арсенал його можливостей безумовно розширився, проте деякі нововведення залишилися поза цим перекладом, то ви можете самі з ними ознайомитися тут.
Ще немає коментарів