Laravel 5.4 で導入された Laravel Mix で Vue 2 + JSX を利用できるようにすることは難しくありません。
ただ、ちょっと作業がいるだけで。
Laravel Mix で Vue の JSX レンダリングを利用する
Laravel-Mix で HMR を利用する
Laravel 5.4 から採用されたフロントスクリプトのビルドツール、 Laravel Mix では、Webpack の HMR (Hot Module Replacement) がデフォルトで利用できます。
(HMRは)画面の再描画すること無しにJSの変更をブラウザに適用してくれる開発ツールです。
Hot Module Replacementの設定と仕組みを理解する – Qiita
Laravel でこれを利用すると、たとえば Vue コンポーネントの変更がリロード無しに反映できます。
Vue コンポーネントにモデル (Entity) を渡す
Laravel で Blade テンプレート上に記述した Vue コンポーネントに Laravel の Model を渡す場合。
{{ hoge }}を使うと渡した値は e() によりHTMLエスケープされるが、Vue コンポーネントのディレクティブとしてエスケープされたJSONを渡した場合もちゃんとオブジェクトとしてパースされpropsに入ってくれる。
(そもそもHTMLで属性に e() した値を渡してもエスケープ前の文字列として扱われるから当然といえば当然)
Markdown メール通知を作成する
Laravel 5.4 より組み込まれた Markdown を用いたメール通知 を作成します。
Markdown Mail Notificationの作成はartisan make:notificationを利用するとViewテンプレートまで自動生成できるのでおすすめです。
今回は、Laravelのデフォルトのユーザー登録時にメールアドレス検証用のメールを送信するという体でサンプルを作成します。
MailCatcher でメールを外部に送信せずにキャッチする
Laravel でローカルでメール送信が行われる作業でメール送信を確認しつつ外部にメールが送られてしまうのを防ぎたい時、MailCatcherでキャッチしてしまうと便利です。
MailCatcher は Ruby で書かれた疑似 SMTPサーバーで、アプリケーションから送信したメールをブラウザで確認できる定番ツールです。
メールをHTMLで表示する以外にもテキストで表示したりメールのDLやソースの表示も可能。
もちろんLaravelだけでなく、メールの送信にSMTPを利用するすべてのアプリケーションに利用できます。
間違って本番のメールアドレスがDBに入っていても顧客にテスト環境のメールが送信されるのを防げます。
フラッシュメッセージ付き リダイレクト
Laravel でリダイレクトを行う時、Flashメッセージをセッションに載せてリダイレクト先のページで表示したい時。 “フラッシュメッセージ付き リダイレクト” の続きを読む
開発に欠かせない Laravel Debugbar の導入
Laravel を使ったアプリケーションの開発には欠かせない Laravel Debugbar のインストール。
Laravel Debugger では現在のリクエストの任意の時点の変数のダンプをフロントに表示するのはもちろん、パフォーマンス確認したり無駄なクエリ追ったりするのにも重宝する。
リダイレクトが起こったページもstackedとして表示してくれるし、そもそもログを記録しているので過去に遡って確認することもできる。
(実体はPHP Debug Bar)
トランザクション後にイベントを発火する
例えば注文を受けてトランザクション内でDBを更新し、その注文についての通知を飛ばす場合。
Sample
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
public function order(OrderRequest $request) { /** @var Order $order */ $order = $request->createOrder(); try { $res = \DB::transaction(function () use ($order) { $order->save(); // (トランザクション内の操作は出来るだけDBに関わるものに絞る) return back()->with('message.success', '注文を受け付けました。'); }); event(new OrderShipped($order)); return $res; } catch (\Throwable $exception) { return back()->with('message.error', $exception->getMessage()??'エラーが発生しました。'); } } |
memo
DB::transaction(callback)を用いた場合、コールバックの前後でbeginTransaction、commitが呼ばれる。コールバックの返り値が返されるのでそれをDB::transactionの返り値として使用できる。
例外発生時はtransaction内部で補足してロールバックして外に投げてくれる。
transactionの第二引数(int)を指定した場合例外が投げられたらその回数リトライするが、PHP7+のErrorが投げられた場合はその時点で潔く諦めてロールバックする。
トランザクション内が複雑な場合はDB::beginTransaction, DB::commitを呼んでもいいがコールバックで済ませれる程度のほうが無駄なロックを生まなくできるよう意識しやすい気がする。
あと手動でやる場合はロールバックを忘れずに。