プロジェクト

全般

プロフィール

Wiki » 履歴 » リビジョン 2

リビジョン 1 (AppTime 管理, 2024/04/21 08:10) → リビジョン 2/6 (AppTime 管理, 2024/04/21 08:19)

# Wiki 

 ## コーディング規約 

 基本的に下記に書かれている一般的なベストプラクティスを適用する 

 https://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md 

 ### ルーティング 

 一般的なRESTの規則に従って実装をします 

 - index - リソースの一覧を表示します。 
 GET /photos 
 - create - 新規リソース作成用のフォームを表示します。 
 GET /photos/create 
 - store - 新規リソースを作成します。 
 POST /photos 
 - show - 特定のリソースを表示します。 
 GET /photos/{photo} 
 - edit - 既存のリソースを編集するフォームを表示します。 
 GET /photos/{photo}/edit 
 - update - 既存のリソースを更新します。 
 PUT/PATCH /photos/{photo} 
 - destroy - 既存のリソースを削除します。 
 DELETE /photos/{photo} 

 ####    例外のルート 

 上記の命名規則では対応しきれないルートは別名を付けて良いものとする 
 例:`search`、`register` 
 基本は上記の命名で、対応しきれない場合のみ例外を適用する 

 #### ルートモデルバインディング 

 上記の show、edit、update、destroy ではパラメータに {photo} を使用しています。これはLaravelのルートモデルバインディング機能を利用するためです。 

 PhotoController の各アクションメソッドでは、Photo モデルのインスタンスを直接受け取ることができます。 

 ```php 
 // app/Http/Controllers/PhotoController.php 
 public function show(Photo $photo) 
 {     アーキテクチャは一般的なRESTで実装する 
     return view('photos.show', compact('photo')); 
 } 
 ``` ただし、`Auth`配下はLaravel Breezeによって自動生成されたもののため、このルールの適用外とする 

 -     外部APIサービスを利用するようなものなどはServiceクラスを作る 
 

 -     型定義を引数、プロパティ、戻り値に全て必ず記述する 

 -     PHPDocにServiceクラスなどを作る際はメソッドなどはわかりやすいように説明を記述する 

 -     テーブルに区分値がある場合は`app/Enums`配下にEnumを作る 

     -     例に既にいくつか作っているため参考にしてください 
     -     boolean型などの真偽値は定数を作らなくて良いです 

 -     フロントエンドはスタイリングにtailwindcssを使う 
     -     Laravel Breezeに既に使われているため、統一する 

 - フロントエンドで動的な操作が必要になった場合、**Alpine.js**、複雑な操作は**Livewire**を利用する 
     -     **jQueryは使わないこと**、Alpine.js、またはLivewireで同等のことがより簡単な記述で実現ができます 

 -     共通のスタイルのみ外に出し、基本は直接bladeファイルにtailwindでスタイルを書いていく