Laravel 5.5の新しいリリースは、長期サポート(Long Term Support、LTS)のリリースになります。 つまり、彼は2年間バグ修正を受け取り、3年間セキュリティアップデートを受け取ることになります。 Laravel 5.1のリリースは同じでしたが、今年の2年間の編集は終わりに近づいています。 新しいバージョンで私たちを待っているものを大騒ぎせずに見てみましょう。
Laravel 5.5で新しいプロジェクトを作成する
新しいリリースはまだ正式にリリースされていないので、次のコマンドを使用してdevリリースをダウンロードできます。
laravel new laravel55 --dev cd laravel55 php artisan key:generate
Laravelインストーラーが気に入らない場合は、composerコマンドを使用できます。
composer create-project --prefer-dist --stability=dev laravel/laravel:dev-master cd laravel php artisan key:generate
新しいアプリケーションのホームページにアクセスすると、以前のバージョンのLaravelのようなウェルカムページが表示されます。
ブラウザでメーラブルをレンダリングする
この機能は非常に役立つと思います。 Laravelの以前のバージョンでは、ニュースレターをテストするために実際の手紙を送信するか、Mailtrapなどの電子メールクライアントを使用する必要がありましたが、タスクは最も面白くありませんでした。 Laravel 5.5では、ブラウザでメッセージテンプレートを直接レンダリングできるようになりました。
これを行う簡単な方法は次のとおりです。プロジェクト用に新しいメール可能テンプレートとレターテンプレートを作成します。
php artisan make:mail Welcome --markdown=emails.welcome
すでにいくつかのコンテンツを含むテンプレートを取得しているため、マークダウン形式を使用することを好みます。 web.php
ファイルを開き、レターテンプレートを確認するためのテストルートを作成します。
Route::get('/email', function () { return new App\Mail\Welcome(); });
ルート/ web.php
ルート/メールに行くと、レターテンプレートが表示されます。
実際、次のことが起こります。 Laravel 5.5では、「Mailable」クラスは「render()」メソッドで「Renderable」コントラクトを使用します。 「Illuminate / Mail / Mailable.php」のrenderメソッドの実装は次のとおりです。
public function render() { Container::getInstance()->call([$this, 'build']); return Container::getInstance()->make('mailer')->render( $this->buildView(), $this->buildViewData() ); }
イルミネーション/メール/ Mailable.php
このメソッドを使用すると、ビューを取得できます。 ルート内で「Renderable」コントラクトを適用しないクラスのインスタンスを返そうとすると、「UnexpectedValueException」が発生します。
カスタムメール
Markdownを使用して文字をフォーマットする場合、Laravelはデフォルトの件名を配置します。 ただし、ブランドを宣伝するには独自のスタイルが必要になる場合があります。
特定の郵便物のカスタムデザインを作成するには、まず、必要なスタイルでカスタム '.css'ファイルを作成します。
touch resources/views/vendor/mail/html/themes/custom.css
次に、このファイルの名前をMailableクラスの特性として指定します。
class Welcome extends Mailable { protected $theme = 'custom'; [...] }
アプリ/メール/ Welcome.php
したがって、レターテンプレートは、 custom.css
ファイルで指定したスタイルに基づいています。 特に喜ばしいのは、さまざまなスタイルの郵便物を設定できることです。
ヘルパー例外関数
Laravel 5.5には、より表現力豊かなコードの作成に役立つ2つのヘルパー例外関数が含まれています。 これらはthrow_if
およびthrow_unless
です。 どちらも3つの引数を含み、3番目の引数はオプションです。
これらの例外がどのように適用されるかを見てみましょう。
$number = 2; throw_if($number !== 3, new NotThreeException('Number is not three')); // or throw_if($number !== 3, NotThreeException::class, 'Number is not three');
ヘルパー関数 'throw_if'を使用する場合、最初の引数がtrueと見なされると例外がスローされます。
throw_unless
を使用する場合、基本的にすべてが同じになりますが、唯一の違いは、最初の引数がfalseの場合に例外がスローされることです。
$number = 2; throw_unless($number === 3, new NotThreeException('Number is not three')); // or throw_unless($number === 3, NotThreeException::class, 'Number is not three');
良い例ではありませんが、デモンストレーションに適しています。
移行:新しいコマンド
おそらく、データベースを復元しなければならない状況に陥っています。 Laravelの以前のバージョンでは、これはphp artisan migrate:refresh
コマンドを使用して実行できました。 migrate:refresh
コマンドは、各移行ファイルの「down」メソッドに記述されている内容に基づいてすべての移行をロールバックし、移行を再開します。
ただし、特に外部キー制約を操作する場合、または移行のいずれかの 'down()'メソッドが十分に定義されていない場合、このコマンドで問題が発生することがあります。 これが発生すると、ほとんどの場合、問題のあるテーブルを手動で削除します(おそらくCLIまたはGUIを使用します)。 それがmigrate:fresh
時migrate:fresh
チームが救助に駆けつけます。 このコマンドは、すべてのテーブルを削除してから、既存の移行を再び開始します。
スタックトレースJSONエラー
最大の変更ではありませんが、以前のバージョンのLaravelでは、APIでエラーが発生するたびにPostmanなどのAPIクライアントからHTMLマークアップが表示されていました。 Laravel 5.5では、エラーが発生した場合、HTMLマークアップではなく、JSONのトレースを取得します。これは理解しやすいものです。
自動パッケージインストール
Laravelプロジェクトでサードパーティパッケージを使用するには、次の手順を実行します。
- パッケージをインストールします。
- パッケージのサービスプロバイダーを登録します。
- ファサードがある場合は登録します。
ご覧のとおり、手順を簡略化できます。 次のようになります。
パッケージの自動インストールでは、目的のパッケージを選択してオンザフライで配置するだけです。 ただし、これはパッケージプロバイダーが適切に構成した場合にのみ可能であることに注意してください。
自動インストールがすでに構成されているLaravel Debugbarパッケージを見ると、 composer.json
ファイル内にextra
セクションがあることがわかります。
"extra": { "laravel": { "providers": [ "Foo\\Bar\\ServiceProvider" ], "aliases": { "Bar": "Foo\\Bar\\Facade" } } }
パッケージプロバイダーは、 composer.json
ファイルに追加のセクションを追加してから、サービスプロバイダーとパッケージのエイリアスを指定する必要があります。
パッケージの自動インストールのもう1つの利点は、依存関係を削除しても何も壊れないことです。 通常、パッケージが取り壊された後でも、そのサービスプロバイダーとファサードはconfig/app.php
に残っており、場合によってはエラーが発生する可能性があります。
自動インストールでは、Composerを使用してパッケージを削除すると、このパッケージに関連するすべてのものも削除されます。
ベンダーへの変更:発行コマンド
Laravelの以前のバージョンでは、 vendor:publish
コマンドはすべてのパッケージのリソースとフレームワーク自体を公開していました。 これらのリソースには、移行、ビュー、構成が含まれます。
Laravel 5.5では、このコマンドで正確に公開するものを詳細に明確にする必要があります。 フラグなしでphp artisan vendor:publish
コマンドを実行する場合、必要なものだけを公開しやすくするためにプロバイダーまたはタグを選択する必要があります。 以下のスクリーンショットをご覧ください。
publish
コマンドの実行時に--all
または--provider
この手順を回避できます。
php artisan vendor:publish --all
さまざまなフロントエンドプリセット
Laravel 5.3および5.4では、デフォルトでいくつかのVueおよびBootstrapプリセットがあり、フロントエンド開発を簡素化しました。 新しいバージョンでは、Reactがこのキットに追加されました。 しかし、彼はデフォルトではそこに立っていません。
新しい職人チームは、フロントエンドプリセットの管理を支援します。 作業したいプリセットに必要なワークピースのみがあります。 しかし、デフォルトのプリセットであるVue、Bootstrap、Reactに誰もが満足しているわけではなく、誰か他のものが必要になる場合があります。 おそらく別のフロントエンドフレームワーク。 そして、Laravelはすでにこれを処理していました。
php artisan preset none
このコマンドは、既存のすべてのフロントエンドブランクを削除します。 Reactを使用したい場合は、次のコマンドが準備に役立ちます。
php artisan preset react
以下は、この新しいチームの活動です。
おっと戻ってきた!
おっと、Laravel 5.5に戻ってきました! エラーを表示する新しい方法。 現在、開発中にエラーが発生した場合、このコード行をエラーメッセージとともにスクリーンショットとして見ることができます。 私の意見では、エラーメッセージは見栄えが良くなり、誤ったコード行を含むスクリーンショットが表示されるようになったことで、エラーを修正しやすくなりました。
Whoopsのエラー例:
もう1つのクールなトリックは、Whoopsを使用すると、指定したファイルをIDEまたはエディターで直接開くことができるようになることです。 この関数は、エディターがインストールされているマシン上のPHPファイルにローカルアクセスできる場合にのみ機能します。 設定するには、app / Exceptions / Handler.phpを開き、次のスニペットを追加します。
[...] use Illuminate\Filesystem\Filesystem; use Illuminate\Support\Arr; use Whoops\Handler\PrettyPageHandler; [...] class Handler extends ExceptionHandler { [...] protected function whoopsHandler() { return tap(new PrettyPageHandler, function ($handler) { $files = new Filesystem; $handler->setEditor('sublime'); $handler->handleUnconditionally(true); $handler->setApplicationPaths( array_flip(Arr::except( array_flip($files->directories(base_path())), [base_path('vendor')] )) ); }); } }
app \ Exceptions \ Handler.php
このスニペットは、ライン$handler->setEditor('sublime')
を使用してメインクラスのwhoopsHandler()
メソッドをキャンセルし、Sublime Textでリンクを開きます。 別のエディターを使用している場合は、githubの記事でサポートされているすべてのエディターのリストと独自のエディターの追加方法を確認してください。 Macを使用している場合は、これを機能させるために崇高なURLプロトコルをダウンロードしてください。
カスタム例外の報告方法
以前のバージョンでは、特別な方法でカスタム例外を構成する場合、Handler.phpファイルのレポートメソッド内にそれらを配置する必要がありました。 たとえば、次のように:
[...] public function report(Exception $exception) { if ($exception instanceof CustomException) { // Do something } if ($exception instanceof MyOtherException) { // Do something } if ($exception instanceof MyOtherCustomException) { // Do something } return parent::report($exception); } [...]
アプリ/例外/ Handler.php
たとえば、50の主要な例外がある場合、このファイルはひどいものに変わります。 Laravel 5.5では、カスタム例外の場合に何が起こるかを示すために、例外内にreport()
メソッドを作成できます。
[...] class CustomException extends \Exception { public function report() { // send email } } [...]
アプリ/例外/ CustomException.php
モデルファクトリージェネレーター
Laravel 5.5は、モデルファクトリを作成する新しいチームを導入しました。 モデルファクトリは、テスト用の偽データまたは新しいオブジェクトを生成する必要がある場合に非常に便利です。
特定のクラスのファクトリーを作成するには、次のコマンドを実行します:
php artisan make:factory Post
データベース/ファクトリを開くと、PostFactoryクラスが表示されます。
[...] $factory->define(App\Post::class, function (Faker $faker) { return [ // ]; });
データベース/工場/ PostFactory.php
私たちは責任を共有しているため、これはよりエレガントなアプローチだと思います。 Laravelの以前のバージョンでは、すべての工場は同じapp/factories/ModelFactory.php
。
検証済みデータを返す
これで、バリデーターからデータを取得してcreate
メソッドに渡すことがcreate
。 Laravelの以前のバージョンでは、次のような新しいオブジェクトを作成しました。
{ $this->validate(request(), [ 'title' => 'required', 'body' => 'required' ]); // return Post::create(request()->only(['title', 'body'])); or return Post::create(request()->all()); }
Laravel 5.5では、検証済みのデータからオブジェクトを直接作成できるようになりました。
public function store() { $post = $this->validate(request(), [ 'title' => 'required', 'body' => 'required' ]); return Post::create($post); }
リクエストから直接validate
コマンドを呼び出すこともできます:
public function store() { $post = request()->validate([ 'title' => 'required', 'body' => 'required' ]); return Post::create($post); }
ただし、この方法でオブジェクトを作成するときは注意が必要であることに注意してください。検証メソッドの外に残す属性は重要ではないからです。 この問題に対処するために、値が検証を必要としない場合でも、このオブジェクトの検証メソッド内で作成するすべての属性を渡します。
$post = request()->validate([ 'title' => 'required', 'body' => 'required', 'notRequiredField' => '', ]); return Post::create($post);
したがって、このフィールドは許可された要求データに自動的に追加されますが、検証規則に限定されません。
カスタム検証ルール
Laravelの以前のバージョンでは、 Validator::extend
メソッドを使用して設定できました。 しかし、中央集権化はありませんでした。 AppServiceProvider
ファイルにルールを追加しinside the resources/lang/en/validation.php
ファイルinside the resources/lang/en/validation.php
メッセージを追加しました。 Laravelのドキュメントでは、これがバージョン5.4でどのように行われるかについて詳しく説明しています。
Laravel 5.5には、カスタム検証を定義する新しい職人チームがあります。 このコマンドは、 Rule
コントラクトを実装する新しいクラスを作成します。 新しいルールを作成して、中身を確認しましょう。
php artisan make:rule CustomRule
app/Rules/CustomRule.php
を見ると、 app/Rules/CustomRule.php
メソッドとmessage
メソッドの2つのメソッドpasses
ありmessage
。 passes
メソッドは2つのパラメーターを取ります。 attribute
とvalue
。ブールvalue
を返します。 混乱している場合、 $attribute
は検証されるフィールドであり、 $value
は属性に渡される実際の値です。
たとえば、ユーザーに特定の名前を付けたくないとします。 次に、ルールは次のようになります。
{ [...] public function passes($attribute, $value) { return $value !== 'unwantedname'; } public function message() { return 'You cannot use that as your username'; } [...] }
アプリ/ルール/ CustomRule.php
次に、新しいルールを使用してusername
属性を検証します。
use App\Rules\CustomRule; request()->validate([ 'username' => [ 'required', new CustomRule() ], 'anotherfield' => 'required|min:5' ]);
アプリ/ルール/ CustomRule.php
Laravelの新しいバージョンでカスタム検証がどのように定義されるかは、 Taylor Otwellの記事で詳しく説明されています 。
コレクションにDDとDumpを追加しました
これで、dump()およびdd()メソッドがコレクションに含まれました。 Laravelの以前のバージョンでは、コレクションをデバッグするときにコレクション変数を割り当て、コレクションが変更されるとそれをダンプしました。 Laravel 5.5では、コレクションから直接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はダンプとダイ、リセットとダイを意味します)。 すべてのステップでコレクションからdd()
を呼び出した場合、コレクションからdd()
を呼び出した最初の時点でのみ結果を取得します。 見てみましょう:
366666
$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 } ]
多対多の中間テーブルのカースト
通常、Modelのcastsプロパティを宣言することができます。これにより、属性の格納方法と読み取り方法が決まります。 Postモデルがあり、読み取りおよび書き込み時にフィールドの1つをJSONでシリアル化するとします。 次のコードスニペットがこれに役立ちます。
class Post extends Model { [...] protected $casts = [ 'somefield' => 'array', ]; [...] }
バージョン5.4では、既にカスタムピボットを多対多の関係にキャストできましたが、データの読み取りしかできませんでした。 データの書き込み操作を実行する場合は、最初に属性値を手動でキャストしてから保存する必要があります。 Eloquent\Model
クラスとEloquent\Relations\Pivot
クラスのcasts
プロパティは同じように動作するため、これを行う必要はありません。これにより、ピボットモデルでattach
、 sync
、およびsave
メソッドを使用できます。
カスタムブレード:: if()ディレクティブ
ブレードテンプレートで長い繰り返しチェックコードを使用すると、見苦しくなります。 良いニュースは、テンプレートから重複する検証コードを抽出できるようになったことです。これにより、テンプレートがよりクリーンで読みやすくなります。 次のようなチェック:
@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
カスタムブレードディレクティブを作成するためのロジックは、 AppServiceProvider
クラスのboot
メソッドに追加されboot
。
[...] use Illuminate\Support\Facades\Blade; class AppServiceProvider extends ServiceProvider { [...] public function boot() { Blade::if('subscribed', function () { return auth()->check() && auth()->user()->isSubscribed(); }); } [...] }
app / Providers / AppServiceProvider.php
一部のチェックでは、引数にメソッドを渡す必要がある場合があります。 この場合、カスタムブレードディレクティブに関しては、クロージャーに引数を渡します。
@if (auth()->check() && auth()->user()->isFollowing($user->id))
この条件を例として使用する場合、 $user->id
をisFollowing()
メソッドに渡す必要があることがisFollowing()
ます。 引数として$user->id
を使用するカスタムブレードディレクティブを作成するには、次の手順を実行します。
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
カーネル内の新しい職人チームの自動登録
通常、 php artisan make:command command-name
を使用して新しい職人コマンドを作成します。 その後、コマンドでクラス内にキーを割り当て、カーネルに移動してコマンドを手動で登録します。
カーネルで新しいチームを登録する必要はなくなりました。 app/Console/kernel.php
ファイル内にコマンドディレクトリを追跡し、すべてのファイルパスを名前空間パスに変換する新しいメソッドが追加されました。
[...] protected function commands() { $this->load(__DIR__.'Commands'); require base_path('routes/console.php'); } [...]
カーネルにまだ登録されていないコマンドを呼び出したとします。 commands()メソッドは自動的に接続します。
新しいルート方法
これは最もクールな新機能ではありませんが、2つの追加のルートメソッドがあることに注意してください。
Route::view('/welcome', 'welcome'); Route::redirect('home', 'dashboard');
1つ目は、ウェルカムビューを/ Welcomeパスにバインドし、2つ目は/home
リクエストを/dashboard
リダイレクトします。
Laravel Horizonの紹介
これは、Laravel Redisキューのダッシュボードとコード駆動の構成システムを提供する新しいLaravelパッケージです。
Horizonは、リアルタイムのキューの読み込み、最近のタスク、失敗したタスク、タスクの再起動の試行、スループットとランタイムのメトリック、およびプロセスの数を表示します。
Horizonの機能には次のものがあります。
- タスクの高レベル分析-1分あたりのタスク数や過去1時間のタスクなどの指標
- 特定のタスクおよびキューに固有の分析。
- タグと監視-特定のタグを監視するだけでなく、タスクにタグを追加できます。
- 最近のタスク-最新のタスクに関する情報を取得できます。
- キューバランシング戦略-Horizonは、負荷に応じてすべてのキューにキューワーカープロセスを自動的に分散できます。
Taylor Otwell は彼の記事で、 Horizonとそれに含まれるすべての機能を構成する方法について詳しく説明しています。
新しいデータベース移行特性
これはRefreshDatabase RefreshDatabase
です。 なぜそれが必要なのか疑問に思う人もいるかもしれませんが、その背後にある理由は理にかなっています。 当初、 DatabaseMigrations
およびDatabaseTransactions
特性がありました。
テストでDatabaseMigrations
特性を使用すると、各テストの前後に移行が実行され、 DatabaseTransactions
特性により、各テスト後にデータベースが元の状態に復元されることが保証されます。
RefreshDatabase RefreshDatabase
は、これら2つの機能を組み合わせています。 データベースはテストの開始時に1回移行し、その後、各テストをトランザクションでラップします。 利点は、テストごとにデータベースを再移行する必要がないことです。つまり、テストがより速く合格します。
おわりに
ご覧のとおり、新しいバージョンには多くのクールな新機能があります。 , , , .
Laravel!