TL;DR 概要
- SonarQubeはReactとJSXのコードベースに特化したルールを提供し、フロントエンド開発者が一般的なReact特有のバグやコード品質の問題を本番環境に到達する前にキャッチするのを助けます。
- SonarQubeがReactコードで検出する主な問題には、不適切なフックの使用(フックのルールに違反)、リストレンダリングでのキーの欠如、JSXでのアクセシビリティ違反が含まれ、これらはユーザビリティに影響を与える可能性があります。
- SonarQube for IDEは、VS Codeや他のIDE内でReactコードにリアルタイムのフィードバックを提供し、コードレビューの下流ではなく、書いている瞬間に問題をキャッチします。
- Reactアプリケーションを構築する開発者は、CI/CDパイプラインにSonarQube CloudまたはSonarQube Serverを統合して、フロントエンドコードベース全体で一貫したコード品質基準を強制することができます。
SonarQube Server 10.4が最近リリースされました。10.3から10.4の間に、48の新しいルールと1つの更新されたルールがリリースされ、Reactアプリケーションでコード品質を向上させるのに役立ちます。
SonarはすでにReactプロジェクトに対していくつかのルールを提供しており、JavaScriptのプロダクトマネージャーであるGabriel Vivasが3部作のブログシリーズ「Lesser-spotted React Mistakes」で説明しています:Hooked on a Feeling、Zombie Methods、What Are We Even Rendering?
この最新のSonarQube Serverのアップデートは、非推奨メソッドの回避、悪いプラクティスの回避、アクセシブルなアプリケーションの作成の3つの領域に焦点を当てています。この投稿では、React開発者がこのアップデートでSonarQube Serverから期待できることの概要を説明し、私のお気に入りの新しいルールをいくつか紹介します。
これらのルールを自分のコードベースで試したい場合は、エディタにSonarQube for IDEをインストール(常に無料で、SonarQube Serverと同じアナライザーを使用)し、Reactアプリケーションの作業中に使用を開始してください。
非推奨メソッド
Reactの進化が進む中で、Reactチームは古いパターンや関数を非推奨にしています。非推奨の関数は、同じ機能を達成するためのより良い方法に置き換えられ、最終的には削除されるため、古い使用を徐々に置き換え、新しいコードでの使用を避けるべきです。Reactの標準に従うことで、コードが一貫性を持ち、最新のReactバージョンに更新しやすくなります。
例えば、クラスコンポーネントでは、インスタンスの実際のDOMノードを選択するためにfindDOMNodeをまだ使用できます。これは2018年からReactのStrictModeで非推奨ですが、GitHub上でfindDOMNodeを参照している133,000のファイルがあります(もちろん、その中には関数の実装も含まれています)。公式のReactドキュメントによれば、findDOMNodeの代わりにrefを使用するべきです。
SonarQube Serverが非推奨メソッドを避けるために強制する新しいルールは次のとおりです:
- 非推奨のAPIは使用しない(この既存のルールはReact用に拡張されました)
- ReactのfindDOMNodeは使用しない
- ReactのisMountedは使用しない
- 文字列参照は使用しない
- Reactのレガシーライフサイクルメソッドは使用しない
これらのルールはすべて製品内で見つけることができます。
悪いプラクティス
進行中のプロジェクトでは、不整合や単なるミスがコードベースに入り込むことがよくあります。運が良ければ、ブラウザでアプリケーションをリロードしたりテストを実行したりするときに何かが壊れていることに気づくでしょう。通常は、バグが本番環境で発見されたときにデバッグする必要があります。意図的なコードを書いていることを確認し、これらの悪いプラクティスを避けるためのルールを持つことは、発見したときにすぐに修正できるため、時間を節約できます。
私がよくやってしまうことの一つは、DOM要素に間違ったプロパティ名を使用することです。私は常にclassと書いてしまい、classNameを使用するべきなのに、クラス名が適用されていないことに気づきます。JSX要素が未知のプロパティや属性を使用してはいけないというルールがこれをキャッチし、SonarQube for IDEは私が間違ったプロパティ名を選んだことをすぐに知らせてくれます。
これらの悪いプラクティスを避けるための16の新しいJavaScriptルールの完全なリストは次のとおりです:
- Reactのthis.stateは直接変更してはいけません
- JSX要素は未知のプロパティや属性を使用してはいけません
- Reactのchildrenはプロップとして渡してはいけません
- 冗長なReactフラグメントは削除するべきです
- ReactDOM.renderの戻り値は使用してはいけません
- useStateの戻り値は分割代入され、対称的に命名されるべきです
- setStateは前の状態を参照するときにコールバックを使用するべきです
- 関数コンポーネントでthisを使用してはいけません
- childrenとdangerouslySetInnerHTMLを一緒に使用してはいけません
- shouldComponentUpdateはReact.PureComponentを拡張するときに定義してはいけません
- JSXの特殊文字はエスケープされるべきです
- 未使用のReact型付きプロップは削除するべきです
- ユーザー定義のJSXコンポーネントはパスカルケースを使用するべきです
- インライン要素間のスペースは明示的であるべきです
- Reactコンポーネントはプロップタイプを検証するべきです
- すべてのdefaultPropsは必須でないPropTypesを持つべきです
そして、子コンポーネントでプロップを変更できないことを保証するTypeScript専用のルールが1つあります。
- Reactのプロップは読み取り専用であるべきです
アクセシビリティ
アプリケーションがアクセシブルであることを保証することは非常に重要です。アクセシブルなアプリケーションを構築することは、能力に関係なく誰もが完全に使用できることを意味します。実際、アクセシブルなアプリケーションは障害を持たない人々にも利益をもたらすことがよくあります。例えば、アプリがキーボードでアクセス可能であることを確認することは、マウスを使用できない人々だけでなく、マウスを壊してしまった人々にも役立ちます。アクセシブルなアプリケーションをもたらすコードを書くことは私たちの責任です。
高度にインタラクティブなアプリケーションを構築する際にアクセシビリティを正しく行うことは難しい場合がありますので、ガイドするための自動化は非常に貴重です。これは、マウスイベントを持つ要素がキーボードイベントにも応答するべきであることを思い出させることや、<div>ではなく<button>要素でボタンを実装するべきであることを思い出させることなどです。
アクセシブルなアプリケーションを達成するのに役立つ新しいおよび更新されたルールの完全なリストは以下のとおりです:
- マウスイベントには対応するキーボードイベントがあるべきです
- DOM要素のARIAプロパティには有効な値があるべきです
- ARIAロールを持つDOM要素には必要なプロパティがあるべきです
- ARIAロールを持つDOM要素にはサポートされているプロパティのみがあるべきです
- タグをARIAロールより優先するべきです
- ARIAロールを持つDOM要素には有効な非抽象ロールがあるべきです
- 冗長なARIAロールはないべきです
- aria-activedescendantプロパティを持つDOM要素はタブキーでアクセス可能であるべきです
- サポートされていないDOM要素にはARIAロールやプロパティを持たせてはいけません
- フォーカス可能な要素にはaria-hidden属性があってはいけません
- アンカーにはアクセス可能なコンテンツが含まれているべきです
- 画像、エリア、画像付きボタン、オブジェクト要素には代替テキストがあるべきです
- DOM要素はautocomplete属性を正しく使用するべきです
- tabIndexの値は0または-1であるべきです
- 非インタラクティブなDOM要素にはインタラクティブなARIAロールがあってはいけません
- インタラクティブなDOM要素には非インタラクティブなARIAロールがあってはいけません
- アンカータグはボタンとして使用されるべきではありません
- 非インタラクティブなDOM要素にはtabIndexプロパティがあってはいけません
- DOM要素はaccesskeyプロパティを使用してはいけません
- 非インタラクティブな要素にはイベントハンドラがあってはいけません
- 非インタラクティブなDOM要素にはインタラクティブなハンドラがあってはいけません
- HTML要素には有効な言語属性があるべきです
- ヘッダー要素にはアクセス可能なコンテンツがあるべきです
- 画像には冗長でない代替説明があるべきです
- インタラクティブなロールを持つ要素はフォーカスをサポートするべきです
- ラベル要素にはテキストラベルと関連するコントロールがあるべきです
- iFrameにはタイトルが必要です
- メディア要素にはキャプションがあるべきです
コードレベルですべてのアクセシビリティ問題をキャッチすることは不可能ですが、上記のルールは確かに役立ちます。axe-coreやPa11yのようなツールをレンダリングされたアプリケーションに対して実行して、実行時に問題を検出するのを助けることができ、手動テストを実施することもできます。
Reactにおけるコード品質
この新しいルールのコレクションにより、SonarQube Server、SonarQube Cloud、およびSonarQube for IDEは、Reactアプリケーションで一貫性があり、意図的で、適応性があり、責任あるコードを書くのを助けるためにすべて設定されています。SonarQube Server 10.4の最新バージョンの他のアップデートをここで確認してください。
まだSonarQube Serverを使用してReactプロジェクトをスキャンしていない場合は、コミュニティビルドで始めるか、SonarQube for IDEをインストールして、エディタでの推奨事項を確認してください。

