<div class="p-input">
<form @submit.prevent="sendMessage">
<div class="p-input_box">
<textarea v-model="newMessage" class="js-input-autoheight" rows="1"></textarea>
<button type="submit" class="p-send">
<i class="fa-light fa-paper-plane-top p-icon"></i>
</button>
</div>
</form>
</div>
送信ボタンを押してもリロードしたくないときは「@submit.prevent」で実装できるっぽい
→基本的にチャットは送信のタイミングではリロードしないから実装した
api.phpのこれはなにをしているのか
構造の説明
phpコードをコピーする
Route::middleware('auth:api')->get('/user', function (Request $request) {
return $request->user();
});
このコードは、LaravelのAPIルート定義の一部で、特定のエンドポイントにアクセスするためのミドルウェアとコントローラのロジックを設定しています。以下に詳細を説明します。
1. Route::middleware('auth:api')
この部分は、**/userエンドポイントにアクセスする際に適用されるミドルウェアを指定しています。auth:api**は、API認証を行うためのミドルウェアです。このミドルウェアは、リクエストが適切に認証されているかを確認します。
2. >get('/user', function (Request $request) { ... })
この部分は、HTTP GETリクエストに対応するルートを定義しています。具体的には、**/user**エンドポイントにGETリクエストが送られた場合に実行されるコードを指定しています。
3. function (Request $request)
この部分は、クロージャ（無名関数）であり、リクエストが送られてきたときに実行される処理を定義しています。**Request**オブジェクトが引数として渡され、リクエストに関する情報にアクセスできます。
4. return $request->user();
この部分は、認証されたユーザー情報をレスポンスとして返します。**$request->user()**メソッドは、認証されたユーザーを取得します。
全体の流れ
- クライアントが**
/user**エンドポイントにGETリクエストを送信します。 - **
auth:api**ミドルウェアがリクエストを検証し、適切なAPIトークンが提供されているかを確認します。 - ミドルウェアがリクエストを通過させると、クロージャが実行され、リクエストオブジェクトが渡されます。
- クロージャ内で**
$request->user()**が呼び出され、認証されたユーザー情報が取得されます。 - そのユーザー情報がレスポンスとして返されます。
このルート定義は、認証されたユーザーが自分の情報を取得するための標準的な方法を提供しています。
それを下記のように変更して、
**api.phpのルート定義を次のように変更し、UserController**にメソッドを追加する場合の変更点について説明します。
変更後のルート定義
phpコードをコピーする
Route::middleware('auth:api')->get('/user', [UserController::class, 'show']);
UserControllerのメソッド
phpコードをコピーする
class UserController extends Controller
{
public function show(Request $request)
{
return $request->user();
}
}
変更点の詳細
1. ルート定義の変更
ルート定義がクロージャからコントローラメソッドに変更されました。これにより、エンドポイント**/userにアクセスする際に、UserControllerのshow**メソッドが実行されるようになります。
2. コントローラメソッドの利用
クロージャ内の処理が**UserController**のメソッドとして定義されました。これにより、コントローラ内での処理がより明確になり、他のコントローラメソッドと一貫して管理できます。
具体的な違い
-
クロージャからコントローラメソッドへの移行: ルート定義内に直接記述されていた処理が、**
UserControllerのshow**メソッドに移動しました。これにより、ルート定義がシンプルになり、コントローラ内での処理が一元管理されます。 - 可読性と管理の向上: ルート定義が複数ある場合や、より複雑なロジックが必要な場合、コントローラにメソッドを定義することでコードの可読性と管理が向上します。特に、同じコントローラ内で関連する処理をまとめることができます。
- テストの容易さ: コントローラメソッドにすることで、ユニットテストや機能テストが容易になります。コントローラの各メソッドを個別にテストすることができるため、コードの品質を向上させることができます。
実際の動作
動作自体はほとんど変わりません。ユーザーが**/userエンドポイントにGETリクエストを送ると、auth:apiミドルウェアがリクエストを認証し、その後UserControllerのshow**メソッドが呼び出され、認証されたユーザー情報が返されます。
この変更により、コードの構造が改善され、可読性とメンテナンス性が向上します。
どっちがいいとかありますか？
ChatGPT
どちらの方法が良いかは、アプリケーションの規模や構造、チームのコーディングスタイルに依存します。以下にそれぞれの方法の利点と欠点を挙げますので、プロジェクトの特性に応じて選択することをお勧めします。
クロージャを使用する場合
利点
- シンプル: 小規模なアプリケーションや簡単なルートに適しています。追加のクラスやファイルを作成する必要がありません。
- 迅速: クイックプロトタイピングや単純なエンドポイントを迅速に作成するのに便利です。
欠点
- 再利用性の低さ: 同じロジックを複数のエンドポイントで使う場合、コードの重複が発生しやすくなります。
- スケーラビリティの問題: アプリケーションが大きくなると、ルートファイルが混雑し、管理が難しくなります。
コントローラを使用する場合
利点
- 組織化: ロジックをコントローラに移動することで、コードが整理され、ルートファイルがすっきりします。
- 再利用性: コントローラメソッドを他のルートやコントローラ内で再利用することが容易です。
- テストのしやすさ: コントローラメソッドは個別にテスト可能であり、ユニットテストや機能テストの作成が容易です。
- メンテナンス性: 大規模なアプリケーションでは、ロジックをコントローラに集約することで、メンテナンスが容易になります。
欠点
- 初期設定が少し複雑: 新しいコントローラやメソッドを追加するための初期設定が必要です。
- シンプルなケースには過剰: 小規模なプロジェクトや非常にシンプルなルートの場合、コントローラを使うのは過剰かもしれません。
結論
- 小規模なアプリケーションや単純なエンドポイントの場合: クロージャを使うことで、素早く簡単に実装できます。
- 中規模から大規模なアプリケーションや複雑なロジックが必要な場合: コントローラを使用することで、コードの整理、再利用性、テストのしやすさ、メンテナンス性が向上します。
最終的には、プロジェクトの特性やチームの開発スタイルに応じて最適な方法を選択するのが良いでしょう。
whereDoesntHave
whereHasの逆で、不一致のレコードを取得します。
// 紐づくposts.title === $titleのレコードがないユーザーのみを取得
$users = User::whereDoesntHave('posts', function ($query) {
$query->where('title', $title);
})->get();
コントローラーに↓これ書いて未読数のバッジを表示させた
public function getUnreadCounts(Request $request)
{
$user = Auth::user();
$unreadCounts = TrThreads::withCount(['thread_messages as unread_count' => function ($query) use ($user) {
$query->whereDoesntHave('read_management', function ($q) use ($user) {
$q->where('user_id', $user->id);
})->where('created_id', '!=', $user->id); // 自分以外の投稿を対象とする
}])->get()->pluck('unread_count', 'order_id');
return response()->json($unreadCounts);
}