web-dev-qa-db-ja.com

React +バックエンド-コード共有時のプロジェクト構造

ReactフロントエンドとExpressを使用したバックエンドを処理する場合、 here を見るとわかるように、私は本当にフォルダ構造が好きです。

_root
├── backend
|   ├── node_modules
|   ├── public
|   ├── src
│   │   └── Server.ts
|   ├── package.json
|   └── tsconfig.json
├── frontend (created using create-react-app)
|   ├── node_modules
|   ├── public
|   ├── src
│   │   └── Index.js
|   ├── package.json
|   └── tsconfig.json
_

フロントエンドとバックエンドは基本的に完全に異なるものであるため、個別の_node_modules_を使用して個別のパッケージを持つことは合理的だと思います。 g。異なるノードモジュールが必要です。また、このモジュール式のアプローチは視覚的に魅力的であり、リポジトリは整然と見えます。

ただし、フロントエンドとバックエンドの間でコンテンツを共有する必要がある場合、この構造で問題が発生します。独自の_tsconfig.json_、_package.json_などの独自のプロジェクトを含むプロジェクトのルートの下にsharedフォルダーを追加しました。このアプローチは、アプローチ here と here を組み合わせたものです。バックエンドの場合、これは完全に機能します。_tsconfig.json_を適切に設定すると（ TypeScript Project References および aliased imports を使用して）、ファイル_root/shared/src/myFile.ts_のように：

_import { myFunction } from @shared/myFile;
_

私はReactフロントエンドを_create-react-app_ を使用して作成しました。エイリアスのインポートが機能しなくても問題ないので、使用する必要があります（フロントエンドのsrcフォルダー内）：

_import { myFunction } from '../../shared/src/myFile';
_

残念ながら、これらのsrcディレクトリ外からのインポート サポートされていません by _create-react-app_で、ejectを使用したくない私はwebpackの経験がなく、すべての構成ファイルを自分で維持したくないので（最初に_create-react-app_を使用したのはそのためです）。

共有コンテンツをフロントエンドのsrcディレクトリに移動できることを知っています。しかし、これは TypeScriptのプロジェクト参照 を使用するために必要なタグを追加する必要があることを意味します。 g。フロントエンドの_tsconfig.json_でcompositeをtrueに設定すると、私には奇妙に思え、ハックのように感じられます。共有コンテンツを含む別のnpmプロジェクトが欲しいのですが。

_create-react-app_は本質的にsrcディレクトリの外部からのインポートをサポートしていないので、全体像が間違っているのではないかと思いました。現在使用しているフォルダー構造は、Reactプロジェクトをバックエンドでセットアップする有効な方法ではありませんか？_create-react-app_は、フロントエンドとバックエンド？srcフォルダーとその中に2つのフォルダーbackendとfrontendがあるルートプロジェクトがあると考えることもできます。しかし、これは、ルートの1つの共有_node_modules_フォルダー。

これは、Reactを使用した最初のプロジェクトです。この種のアーキテクチャの問題のベストプラクティスを知りたいと思います。信頼できるリソースへのリンクフルスタックのプロジェクト構造React開発が説明されている場所は本当に役に立ちます。ありがとうございます????

javascriptnode.jsreactjstypescriptcreate-react-app
4
New3D

フロントエンドとバックエンドの間でコードを共有したいのは、まったく理にかなっていると思います。 RubyまたはPHPではなく、JavaScriptでコーディングする理由の1つです。

Npmの代わりにヤーンを使用して希望どおりの結果を得ることができます： https://yarnpkg.com/lang/en/docs/workspaces/ 。トップレベルで、package.jsonに3つのモジュール/パッケージを設定します（それぞれのpackage.jsonファイルでワークスペースに正しく名前を付けていることを確認してください）。

"workspaces": {
    "packages": [
        "backend",
        "frontend",
        "shared"
    ]
},

これを行うと、CRAアプリまたはバックエンドに共有コードを次のように簡単にインポートできます。

import { myFunction } from 'shared/src/myFile';

唯一の欠点は、CRAを使用している限り、sharedディレクトリからfrontendに反応コンポーネントをインポートできないことです。反応アプリは1つしかないので、これによる影響はありません。複数のプロジェクト間で反応コンポーネントを共有する必要がある場合は、bit.devのような上記の提案のいくつかを調べてください。

これは唯一の方法ではありませんが、最も単純で最も簡単な方法の1つです。

1
Robert Moskal

  1. フロントエンドとバックエンドに別々のサブプロジェクトを用意することは、依存関係が大きく異なるため、完全に理にかなっています。混在させると、運用環境でのディスク容量の消費が増加し、セキュリティガイドラインに違反します。あなたのフォルダー構造は合理的です（私が確信がないpublic/サブフォルダーを除いて、おそらく何かが足りない）。

  2. import { myFunction } from @shared/myFile;のアプローチは問題ありません。 CRAは使用しないでください。

  3. フロントエンドとバックエンドが1つのプロジェクトの場合、shared\トップレベルフォルダーは不要です。フロントエンドが「UIの真実」の唯一のソースであるためです（たとえば、UIに関連するタイプとコンポーネントのソース）これはフロントエンドによって消費され、バックエンドはフロントエンドとバックエンドの両方によって消費される「APIの真実」の唯一のソースです。この配置では、共有する必要があるのは@backend/api_shared_stuffのみです。

  4. フルスタックのプロジェクト構造が信頼できるリソースへのリンクReact開発が説明されていると非常に役立ちます。一方では、通常、プロジェクトの作成者は多くのことを説明する必要があります他のものと、一方でドキュメント（通常はREADME）を合理的に簡潔にしてください。サブディレクトリ構造がこれであり、それがそうではない理由を説明/説明することが最優先事項ではなかったことがわかります。

1
winwiz1