個人的見解 Handler でハンドリングして返すのが正しいと思う。 そこ以外でハンドリングするとなると多分 trait を FormRequest で use するとかそんな方法になってしまう。それはそれで正しいとは思うけども本当に正しいのだろうか？と考えた結果Handler.phpで返すことに決めた 実処理 app/Exceptions/Handler.php <?php declare(strict_types=1); // 省略 class Handler extends ExceptionHandler { /** * @const string */ const ROUTE_PREFIX = 'api'; // 省略 public function render($request, Exception $exception): void { if(collect(explode('/', $request->route()->getPrefix()))->first() === self::ROUTE_PREFIX ) { $this->apiReqponse($exception); } } // 省略 private function apiResponse(Exception $exception): void { if ($exception instanceof ValidationException) { $this->throw($exception->errors(), 400); } // 他のexceptionを羅列することが可能 } private function throw(array $errorMessage, int $code): void { throw new HttpResponseException( response()->json( [ 'status' => 'fail', 'code' => $code, 'error_message' => $errorMessage ], $code ) ); } } 返却値 返却内容は、ぶっちゃけエラーとわかりかつ、フロント側で処理が行いやすいものならなんでもいいかなと思う。 { 'status': 'fail, 'code': 400, 'error_message': { 'field name': [ 'エラーです' ] } } 余談 こっからは余談ですが、API の実装をしている基本的な返却形式は統一すべきだとおもってますし実際それは、スタンダードな考えだと思っています。今回Validationエラーに関して Handler でハンドリングを行うようにしたことによって統一できました。さらにいうとこれでテストの実装に関してはも形式が同じになったことにより楽になりました。

今の自分の中で Vue のディレクトリ構成の最適解 そもそも色々と疑問があった。 なぜ component は毎回個別に import するのか？ なぜ JS は一個の object でどうにかしようとしているのにすべては詰め込まないのか でっかい object だとまぁーメモリやら通信速度やら問題は、あるのはわかっているがそもそも論が始まりそうだし宗教問題に発展してそうな雰囲気 答えは OSS で生まれるのかも 人気のある FW やライブラリに関しては、いろんな人がいろんな提案し今の最適解を出そうとしているし他人にコードを読んもらうことを意識した書き方をしているためかリーダブルであることが多くとても有意義 エンジニアリングは、エンジニアのスキルをあげることにも一役買っていると思う。 答え出なくても draft にはなる 最適解が生まれづらい JS という世界では、現時点でベストであるというだけでも十分かなと思う。 ##　で最初の表題へ戻る ├── components ├── container ├── lib ├── router └── store 途中段階だけど上記のような流れになるかなと いちいち components を import するのはだるいので中規模もしくは、ページ数が少ない、ないし小規模ならばグローバルに登録してしまえって思う。特に管理画面系を作成するならなおのこと思う 都度 import をする記述が減るって happy だと思う また sotre の中も色々考えるけど mutations, getters, actions等々分けてもいいわけだし なんなら機能単位もしくは、ドメイン単位でサブディレクトリをmodulesみたいな作ってstoreに modules で登録すればいいねって思った さすれエンドポイントの file の記述が少なからず減るし 全体的な可読性が高まると思う。 ヒントというか元になったのは vuetify の管理画面関連の OSS の構成

目的 Go の勉強で Hugo を触ってみたものの自分としては、んー今じゃない感がありました。機能としては十分だし、成熟しつつあるドキュメントも多いんだけども Go をちゃんと学習してからだなと思った次第 ちゃんとというのは曖昧で正確に言えば基礎を一通りしてからでってことですね。最初の過程をすっ飛ばしました。 そこで代わりになるものはないかなーできれば Vue か React 関連で。。。っとおもったら vuepress なるものがあるらしいとのことで触ってみた 触った所感 わかりやすい。ただその一言ですね。ただ日本語ドキュメントは、Hugo とくらべてあまりない印象 コードを書いた際のスニペットもいい感じでした。 絵文字も見れますしね。 ひとまず導入手順のみ書き残そうと思った次第です 導入手順 VuePress 下記コマンドを実行 yarn init yarn add -D vuepress echo '# Hello VuePress' > README.md package.json に追加 "scripts": { "dev": "vuepress dev", "build": "vuepress build" }, yarn dev // サーバーを起動しブラウザで確認 yarn build // buildを行いディレクトリを作成 touch .vuepress/config.js 以下を記述 base: ‘/dirName/’ // GitHub Pages の公開ディレクトリ dest: ‘docs/’, // build 時の出力先指定 module.exports = { title: "GitHub Pages product by vuepress", // 公開ページのタイトル desctription: "VuePress 挑戦", // ページの説明 dest: "docs/" // build字の出力先指定 } 最終的には、サーバーを立ち上げればHello Worldが確認できます。