フロントエンド プロジェクトを強化するための他の言語およびフレームワークのパターン

私は 12 年間プログラミングを行っており、多くの言語を扱ってきました。これらには、 C 、 C++ 、 Java 、 Python 、 C# 、そして最後にJavaScript が含まれます。すべての言語やフレームワークには独自のルールがあります。たとえば、 Rust では関数名にスネークケースが使用されます。

ただし、私が大切にしている特定のルール、ツール、パターンがあります。これらをフロントエンド アプリケーションに組み込んでいます。これらのルールは私にとってさらに心に響き、コーディングのプロセスをよりスムーズにします。私が特に気に入っているものをいくつか紹介します。

関数型プログラミング

私の最初のヒントは、私が最初に学んだ言語である C から来ています。以前、クラスを使用して Reactを作成したときのことを覚えていますか?考えただけで寒気がします。 React が機能コンポーネントに切り替えると、コードが読みやすくなっただけでなく、テストも簡単になりました。

また、関数型プログラミングの原則ともよりよく一致しています。

このアプローチは、再利用可能なコード部分の作成に重点を置くことが多いため、フロントエンド フレームワークでうまく機能します。フロントエンド開発で関数型プログラミングを使用することは、私にとってこの概念を理解し、新しいフロントエンド機能を構築するのに常に役立ちます。

関数型プログラミングの原則に従うことは、すべてのフロントエンド アプリケーションで必須です。

関数型プログラミングに詳しくない場合は、さらに詳しく調べることを強くお勧めします。この点がこのリストの最初にあるのには理由がありません。開発プロセスに多大なメリットをもたらします。

コードフォーマッタ

私が初めてプログラミングを始めたとき、コードの形式にはあまり注意を払いませんでした。すべては大学で白をテーマにしたクールなCodeBlocks IDEで C++ を学んでいたのが始まりだと思います。

GitHub で 2016 年の古いコードを振り返ると、書式設定にスペースのみを使用していることがわかります。これを自動的に処理するツールは使用しませんでした。

今、それは間違いだったと気づきました。プロジェクト内の何かを自動化できる場合は、必ず自動化する必要があります。現在、私はすべてのプロジェクトの開始時に必ずPrettierとESLintをセットアップします。これに多くの時間を費やしたくない場合は、 Airbnbのような事前に作成された設定を使用できます。

信じてください、後悔はしませんよ！

ああ、IDE でファイル保存アクションの自動フォーマットを設定することを忘れないでください。

コミット前のアクション

素晴らしいフォーマッタを手に入れたので、それを自動化してみましょう。いつプリコミットフックを使い始めたのかよく思い出せませんが、プリコミットフックは私のプロジェクトで非常に役に立ちました。各コミット前に自動化できるのに、なぜ手動でフォーマットする必要があるのでしょうか? huskyやlint-stagedなどのツールを使用すると、この自動化が可能になります。

ファイル名のケバブケース

Angularには多くのファンや批評家がいますが、私は良い点に焦点を当てたいと思っています。大企業や大規模なアプリケーションでは、Angular が最初の選択肢となることがよくあります。 Angular で行われた決定の多くは、保守を容易にすることを目的としていたと思います。

だからこそ、私はすべてのフロントエンド プロジェクトに kebab-case を使用することにしました。次のようないくつかの利点があります。

• シンプルさ: パスカルケース、キャメルケース、またはスネークケースのどれを使用するかを (必要に応じて) 心配する必要はありません。ケバブケースの場合、選択肢は 1 つだけです。

• 一貫性: チームで作業している場合、kebab-case のような単一の命名規則を採用すると、全員が同じ認識を持ち、プロジェクトが整理された状態に保たれるようになります。 unicornパッケージを使用すると、eslint ルールによって kebab-case の使用を強制できることを忘れないでください。

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• クロスプラットフォーム互換性: オペレーティング システムが異なれば、ファイル名の処理方法も異なります。たとえば、Windows では大文字と小文字の区別が考慮されませんが、Linux では大文字と小文字の区別が考慮されます。小文字とハイフンを使用するケバブケースを使用することで、問題を回避します。

• git の問題はありません: git でファイル名を小文字から大文字に変更する際に問題があります。ケバブケースを使えばそんな心配もありません。

私は物事をシンプルにするのが好きです。自分の生活が楽になり、そこから何らかの恩恵を受けることができるなら、私はそれに大賛成です。

ファイルタイプのタグの使用

私が Angular から借用したもう 1 つの点は、ファイルに名前を付ける方法です。 Angular では、ファイルの機能とタイプを反映した方法でファイルに名前を付けることをお勧めします。これにより、プロジェクトの構造をナビゲートして理解することが容易になることがわかりました。 Angular では、ファイル名は通常、機能領域、ファイルの役割、ファイルの種類の 3 つの部分で構成されます。

たとえば、 heroes.component.ts 、ファイルがheroes機能のコンポーネントであり、TypeScript ファイルであることを示しています。 heroes.service.ts heroes向けのサービスです。

私はservicesの大ファンではありませんが、React コンポーネントには同様の構造を使用しています。以下に例を示します。

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

私はフックや関数にもこのパターンを使用しています。このパターンは、テストをそれに関連するファイルの隣に配置することも教えてくれます。

コード生成を自動化する

前に述べたパターンは非常に役立ちますが、自動化することでさらに改善できます。 Angular CLI を使用すると、ユーザーはコードを自動的に生成できます。私は常にplopを使用して同じことを行います。 Plop のテンプレート システムは非常に強力ですが、最も重要なのは時間を節約できることです。

自動化を使用すると、コンポーネントの基本構造について考えることに多くの時間を費やす必要がなくなります。この作業は自動化できるので、本当にやりたいことに集中できるようになります。

「ドメイン」の使用

ここではdomainは何かについて詳しく説明しません。さらに詳しく知りたい場合は、この記事を読むことをお勧めします。現在、私はフルスタック開発者のチームと協力していますが、フロントエンド プロジェクトにドメイン層があることが非常に便利であることがわかりました。

ここに、すべての主要なタイプと操作を配置します。これはアプリの「真実の情報源」として機能します。

私のアプリで「ドメイン」をどのように処理するかを知りたい場合は、 この記事をご覧ください。私はこのトピックの説明に多くの時間を費やしています。

アーキテクチャをテストする

Kotlinを使用した作業中に、ドメイン内のリポジトリで定義された型を使用するなど、ロジックが複数のレイヤー間で混在するという問題に遭遇したことがあります。これはクリーン アーキテクチャの観点からはあり得ないことですが、誰もが間違いを犯します。

そのとき、アーキテクチャの単体テスト用ツールであるArchUnitを発見しました。基本的に、アーキテクチャに正しく準拠しているかどうかをチェックします。

特定のアーキテクチャを維持している場合、ある時点で壊れていないかどうかを確認するツールがあると便利です。この点では、 dependency-cruiserのようなツールが非常に役立ちます。

これで、フロントエンド プロジェクトを強化するための他の言語およびフレームワークのパターンの重要なリストは終わりました。この情報が役に立ち、これらの戦略の少なくとも 1 つがあなた自身の仕事にそれを実装するきっかけになってくれれば幸いです。