フロントエンド開発 コーディングルール - nnnaoki1998/spocon GitHub Wiki

ファイル名の命名規則

以下の形式とする

  • tsxファイルはアッパーケース
    • 理由：reactのコンポーネント名は大文字始まりにする必要があるため、ファイル名をコンポーネント名と揃える
  • tsファイルはキャメルケース
    • 理由：jsの慣例としてはキャメルケースため
  • cssファイルはキャメルケース
    • 理由：一般的にキャメルケースが採用されているため

※ディレクトリ名はキャメルケースとする

例

SignIn.tsx, useSignIn.ts, signIn.css

参考

https://basarat.gitbook.io/typescript/styleguide#filename

ディレクトリ構成

|-- components
    |-- 1_atoms
    |-- 2_molecules
    |-- 3_organisms
    |-- 4_templates
    |-- 5_pages
    |-- utils ◀️ utils配下のファイルはAtomicDesignのどこかのディレクトリ配下で管理したら不要になるかも？
|-- configs
|-- features
    |-- apis
    |-- models
|-- graphql
|-- hooks
|-- pages  ◀️ components/5_pages配下に移動して今後削除する予定
|-- types
|-- utils

components

config

  • フロントエンド全体で利用したいconfigを管理

features

  • プロジェクト特有で利用する機能を管理

apis

  • 外部もしくはバックエンドのAPIのエンドポイントを管理する

models

  • 各モデルごとのビジネスロジックを管理する

graphql

  • amplifyによって自動生成されるディレクトリ
  • GraphQLを使ってリクエストする場合に利用する（主にチャット周りで利用）

hooks

  • プロジェクト固有で利用するカスタムフックを管理

types

  • フロントエンド全体で利用する型定義を管理
  • バックエンドから取得したデータの型など

utils

  • 特定のプロダクトについての知識を持たない処理を管理

type vs interface

  • オブジェクトの定義や冗長な型定義は、typeもしくはinterfaceで定義することができる
  • Spoconではtypeで統一したい気持ちがある
  • 以下理由
    • interfaceは再定義により、上書き、拡張可能
    • typeは再定義するとコンパイルエラーになり、バグの温床になりづらい
    • またinterfaceと同じように拡張したい場合は"&"を使って拡張可能
    • そのため、typeで統一していきたい
  • interfaceはオブジェクト指向のインターフェースとして使うときのみに利用したい

参考

コーディングルールを定めるときに参考にしたい資料