Next.jsのディレクトリ構成をどうするか
いろいろ参考にする components/ 全ページ共有、ページ固有のコンポーネントを分ける pages/ componentを呼び出す services/ ユーザーのアクションに応じて、データの加工（結合や集計など）を行うコードを置いておきます。 加工元となるデータ取得は、repositories配下の関数を呼び出す ユーザーの1アクションに対して、1つのサービス関数を作るイメージ repositories/ DBやSaaSにアクセスする models/ entities/ servicesで加工したデータと、repositoriesで取得したデータの区別が付きやすいように、servicesで生成するオブジェクトについては、モデル名にXXXDataのようなサフィックスをつけるようにしています libs/ 使用しているライブラリ固有のコードで、初期化や設定のコードなど、データ取得に絡まない
私のフロントエンドディレクトリ構成・テスト観点 2022
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します（あくまで執筆現在の脳内アウトプットになりますのでご了承ください） フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの？」と思うこともあるので、とくに要望がなければ、筆者は「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
