2022/5/27blog_admin|2022年05月27日フロントエンド41Twitter0Facebook1B!Bookmark1Pocketこんにちは、フロントエンドチームです。今週のフロントエンド定例の内容を記載します。フロントエンド定例について、以前の記事(ランサーズのフロントエンドチームが取り組んでいること)でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。以下、今週の内容です。development)絞り込み時間帯の絞り込みなどのフィルタリングをしてログを探ることができます。ログのカラムなど表示をカスタマイズしたのをSlackのブックマークに登録しているのでそこからみていただくのが早いと思います。スプレッドシートのフィルタによる検索が使い慣れているので10日分ぐらいのログをCSVに出してCONTENTにあるエラーのフィルタリングしてどういったエラーがあるのかみてるときもあります。ログ収集の管理対象として最新のテンプレートテーマに対して開発環境は全てのページ、本番環境は一部のアプリケーションページのみ監視対象にしてどういったログが出ているのか様子見しています。>});のような実装をし、ネットワークエラーのログ収集はしないようにしたり、サービスで使用しているユーザIDもログに残すようにしてエラーの原因調査をできるようにしています。現状一部ビルドファイルのコミット忘れ防止やコンフリクト回避でデプロイ時にビルド実行していますが、Git管理(.gitignoreから外す)するようにし、作業中の段階でコミット忘れがないか検証するようなタスクを置こうかなと思っています。fi個人的にはMPAのモノリスなレポジトリから分離した際にフロントエンドのCIタスク系入れたいというのもありますし、MPAの静的ファイル管理のディレクトリにビルドファイルを置くことをそもそも辞めたいと思ってます。@high_g_engineerReactコンポーネント単体のファイル分割について最近、プロジェクトで個人的に採用しているファイルの分け方について共有します。これは、AtomicDesignの様な全体構成の話ではなく、Reactコンポーネント単体を見た時に、ディレクトリ内でどの様にファイルを分けているかについての話になります。フォーム制御にreact-hook-formとyup紹介したいファイル構成は以下です。errorScheme.ts以下にそれぞれのファイルの役割についての説明を記載しています。各registerにルールを直接記述しないといけないので可読性が良くありません。'必須エラー'});バリデーションをyupで実装する場合resolverに対してバリデーションスキーマを渡すだけでokなので、logic.tsの内容が汚れず、可読性が良い状態になります。logic.ts側はresolverの記述のみでok});実際のerrorScheme.tsの内容は、以下の様な感じです。チェック、正規表現チェックのみを行い、そこからあふれるAPIとの接続が必要になってくるエラーチェックは、logic.ts側で記述する形になります。※実際のファイルは、定数で記述していますが、わかりやすいように数値、文字列をそのまま記述しています。.required('必須入力のエラーメッセージ'),});特に何も考えない場合だと、index.tsxになんでもまとめがちですが、それぞれのファイルで責務を分けることで、保守性が向上したり、複数人開発しやすかったりといったことが期待できるので、個人的にはファイルが肥大化してきたな。感じたら、どんどんファイルを分けるのがオススメです。この辺りは、ベストなパターンが色々あると思いますので、試行錯誤しながら知識を随時アップデートしていけたらと思っています。次回の更新予定は、6/3(金)になります!前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います。©Lancers,inc.。