【Laravel6.x〜】デバッグするならdd()?いやいや、ddd()を使おう!!
概要
ZennやQiitaでLaravelの記事を色々見ていたらたまたまddd()
というデバッグ用のヘルパー関数を見つけたので実際に使ってみました。
結論:今後はddd()
を使う!!
環境
$ composer -V
Composer version 1.10.20 2021-01-27 15:41:06
$ php artisan --version
Laravel Framework 6.20.16
dd()とddd()とは
どちらのデバッグ用のヘルパー関数です。
デバッグ関数 | 概要 |
---|---|
dd() | Laravel本体のヘルパー関数 |
ddd() | facade/ignitionのヘルパー関数 |
(ヘルパー関数:PHPとは別にLaravelや各パッケージが用意している関数)
ddd()
はLaravel6.xから統合されたfacade/ignition
のヘルパー関数だそうです。
Laravel Ignition Introduces the ddd() Helper
Laravel本体のヘルパー関数でないから
でも見つけることができませんでなかったわけですね。
※ddd()がfacade/ignitionのヘルパー関数であることはこの記事へのコメント、Twitterで教えていただきました。ありがとうございます🙇♂️(どちらもLaravel本体のヘルパー関数だと思っていました)
サンプルケース
記事投稿アプリで特定のidの記事の編集画面表示の処理とします。
ViewからControllerのアクションに記事(Article)クラスのインスタンス(=編集する記事データ)を渡している仕様とします。
class ArticleController extends Controller
{
// 略
/**
* 記事編集画面表示
*
* @param App\Article $article
* @return \Illuminate\Http\Response
*/
public function edit(Article $article)
{
return view('articles.edit', compact('article');
}
// 略
}
dd()使用時の画面
class ArticleController extends Controller
{
// 略
/**
* 記事編集画面表示
*
* @param App\Article $article
* @return \Illuminate\Http\Response
*/
public function edit(Article $article)
{
// dd()
dd($article);
return view('articles.edit', compact('article');
}
// 略
}
モデルインスタンスの場合、多くの場合
- attributes:デバッグ対象のプロパティ
- relations:デバック対象のリレーション関係にある情報
を見るかと思いますし、dd()
で取得できるのはそれくらいかと思います。
ddd()使用時の画面
class ArticleController extends Controller
{
// 略
/**
* 記事編集画面表示
*
* @param App\Article $article
* @return \Illuminate\Http\Response
*/
public function edit(Article $article)
{
// ddd()
ddd($article);
return view('articles.edit', compact('article');
}
// 略
}
【Debugタブ(初期表示)】
これはdd()
で表示される内容と同じですね。
【Stack Traceタブ】
スタックトレースとは、こちらの記事でこう書かれています。
エラーが発生するまでに、どんな処理を、どの順番で呼び出したか表現したもの
こうは書いていますが、今回のように処理を中断した場合は中断したところまでの処理の流れを追えるようになっています。
今回の場合でいうとpublic/index.php
の55行目がまずは実行されて、最終的にapp/Http/Controllers/ArticleController.php
の89行目(ddd($article);
)が実行されて処理が中断されているという流れがわかります。
(ここまでに計44個の工程があるんですね〜)
【Requestタブ】
リクエストの情報が記載されています。
- GETであること
- CSRFトークンの値
- リクエストヘッダー
などが一目でわかります。
【App】
- Controller:実行したアクションメソッド
- Route name:ルーティング名
- Route Parameters:アクションメソッドに渡したパラメーター(引数にあたる)
- Middleware:ルーティングに設定したミドルウェア
こんな情報が一目で確認できます。
【User】
Userタブではログイン中のユーザーの情報が表示されます。
この情報は
dd(Auth::user());
で取得できるUserクラスインスタンスのattributesプロパティからpassword
の情報を除いたものです。(これはセキュリティの観点からなのかな...?)
【Context】
- Repository:GitHubのリポジトリ
- Message:最新のコミットメッセージと
- Laravel version:Laravelのバージョン
- Laravel locale:言語設定
- Laravel config cache:設定ファイルのキャッシュをクリアしたか(※)
- PHP version:PHPのバージョン
(※)
この画像ではfalse
になっていますが、
$ php artisan config:cache
実行後に再度、ddd($article);
するとtrue
に変わっていました。
config系のキャッシュをクリアしてない(=config系の設定が反映されてない)ことに起因するエラーの発見もしやすくなりそうですね。
まとめ
ddd()
、めっちゃ良い!!
- UI(タブ切り替えでわかりやすい)
- 情報量(ログインユーザーや設定情報もすぐわかる)
の観点から完全にdd()
の上位互換な印象ですね。
ddd()
ではなくdd()
を使う理由が見つからないので今後はddd()
使います。
(もっと早く知りたかった...🤦♂️)
Discussion