Skip to main content
このドキュメントには、コードを書く際に従うべきルールが含まれています。 ここでの目標は、一貫性があり、読みやすく、メンテナンスしやすいコードベースにすることです。 そのためには、簡潔すぎるよりも少し冗長な方が良いです。 常に念頭に置いておくべきなのは、コードは書くよりも読む機会の方が多いということです。特に、誰でも貢献できるオープンソースプロジェクトでは、その傾向が強くなります。 ここでは定義されていない、多くの規則がありますが、リンターにより自動的にチェックされます。

React

関数コンポーネントを使用する

常にTSXの関数コンポーネントを使用してください。 constを使ったデフォルトのimportは避けてください。読むことや、コード補完でのインポートが難しくなるからです。

プロパティ

プロップスの型を作成し、エクスポートの必要がない場合にはそれを(ComponentName)Propsと呼んでください。 プロップスの分割代入を使用する。

プロップス型の定義にReact.FCまたはReact.FunctionComponentを使用しない

JSX要素内で単一の変数プロップスプレーディングを使用しない

{...props}のようにJSX要素内で単一の変数プロップスプレーディングを避けてください。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。 この方法は、コンポーネントが受け取るプロップスを不明確にするため、コードの可読性が低下し、メンテナンスが困難になります。
根拠:
  • ひと目で、コードがどのプロップスを渡しているかが明確になり、理解とメンテナンスが容易になります。
  • これにより、コンポーネント間のプロップスによる密結合を防ぐのに役立ちます。
  • プロップスを明示的にリストすれば、lintingツールが綴り間違いや未使用のプロップスを特定しやすくなります。

JavaScript

??(ヌリッシュ合体演算子)を使う

?.(オプショナルチェイニング)を使う

TypeScript

typeを使い、常にinterfaceの代わりにする

typeは多くの場合、interfaceと重複し、typeの方が柔軟性が高いため、常にtypeを使用してください。

列挙型の代わりに文字列リテラルを使う

文字列リテラル は、TypeScriptで列挙型のような値を扱うための推奨方法です。 それらはPickやOmitで拡張するのが簡単で、特にコード補完を伴う開発者の体験を向上させます。 それらはPickやOmitで拡張するのが簡単で、特にコード補完を伴う開発者の体験を向上させます。 Pick や Omit で拡張しやすく、特にコード補完の面で、より良い開発者体験を提供します。 なぜTypeScriptが列挙型を避けることを推奨しているかはここをご覧ください。

GraphQLと内部ライブラリ

GraphQLのcodegenが生成する列挙型を使用する必要があります。 内部ライブラリを使用する際にも列挙型を使用する方が良いので、内部ライブラリが内部APIに関連しない文字列リテラル型を公開する必要がなくなります。 例:

スタイリング

StyledComponentsを使用する

コンポーネントをLinaria styledでスタイル設定する。
スタイル付きコンポーネントを”Styled”で接頭辞にして、“本物の”コンポーネントと区別する。

テーマ

大部分のコンポーネントのスタイルをテーマに基づかせるのが推奨される手法です。

測定の単位

Styledコンポーネント内でpxまたはrem値を直接使用しない 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。 必要な値は一般的にテーマに既に定義されているため、これらの目的でテーマを利用することが推奨されます。

カラー

新しい色を追加するのではなく、テーマから既存のパレットを使用してください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。 パレットが適合しない場合には、コメントを残してチームがそれを修正できるようにしてください。

タイプ無しのインポートの強制

タイプインポートを避けてください。 この標準を強制するために、Oxlint のルールがあらゆる型インポートをチェックして報告します。 これにより、TypeScriptコードの一貫性と可読性が維持されます。

なぜタイプなしインポートなのか

  • 一貫性: 型インポートを避け、型と値の両方に単一のアプローチを使用することで、モジュールインポートスタイルの一貫性が保たれます。
  • 可読性: 型専用インポートは、値をインポートしているのか型をインポートしているのかを明確にすることで、コードの可読性を高めます。 これにより曖昧さが減り、インポートされたシンボルの目的を理解しやすくなります。
  • 維持性: コードベースの維持性を向上させます。開発者がコードを確認/変更する際に、タイプのみのインポートを特定して見つけることができるからです。

Oxlintルール

Oxlint のルール typescript/consistent-type-imports は、型インポート禁止の標準を強制します。 このルールは、タイプインポート違反のエラーや警告を生成します。 このルールは、意図せず型をインポートしてしまう稀なエッジケースに特化して対処することに留意してください。 TypeScript自体、TypeScript 3.8 リリースノートでこのプラクティスを避けています。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。 ほとんどの状況で、タイプのみのインポートを使用する必要はありません。 コードがこのルールに準拠していることを確実にするため、開発ワークフローの一環として Oxlint を実行してください。