React+后端-共享代码时的项目结构

我真的很喜欢这里的文件夹结构，当使用express:处理React前端和一些后端时

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单独的包是合理的，因为前端和后端基本上是完全不同的东西，例如，它们需要不同的节点模块。此外，这种模块化方法在视觉上对我很有吸引力，而且存储库看起来很整洁。

然而，当我需要在前端和后端之间共享内容时，我遇到了这种结构的问题。我在项目的根目录下添加了一个shared文件夹，其中包含自己的项目和自己的tsconfig.json、package.json等等。这种方法是这里和这里的混合方法。对于后端，这完全可以：适当地设置了tsconfig.json(使用TypeScript项目引用和别名导入)后，我可以像这样引用文件root/shared/src/myFile.ts：

import { myFunction } from @shared/myFile;

我使用create-react-app创建了React前端。别名导入不起作用对我来说没关系，所以我必须使用(在前端的src文件夹中)：

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

遗憾的是，create-react-app不支持这些从src目录外导入的内容，我不想使用eject，因为我没有使用webpack的经验，也不想自己维护所有配置文件(这就是我最初使用create-react-app的原因)。

我知道我可以将共享内容移动到前端的src目录。但这意味着，我必须在TypeScript中添加使用项目引用所需的标记，例如，在前端的tsconfig.json中将composite设置为true，这对我来说似乎很奇怪，感觉更像是一次黑客攻击。我想有一个单独的npm项目与我的共享内容。

由于create-react-app本质上不支持从src目录外导入，所以我想我可能误解了大局。我现在使用的文件夹结构不是一种有效的方式来设置带有后端的React项目吗？create-react-app提供了什么机制来在前端和后端之间链接文件？我还可以考虑有一个带有src文件夹的根项目，其中有两个文件夹backend和frontend。但这意味着，我们在根目录中有一个共享的node_modules文件夹。

这是我使用React的第一个项目，我很想了解一些解决这类架构问题的最佳实践。一些链接到可靠的资源，其中解释了全栈React开发的项目结构，这将非常有帮助。非常感谢。😊

希望在前端和后端之间共享代码是完全合理的。这也是用javascript而不是Ruby或PHP进行编码的原因之一。

通过使用yarn而不是npm和yarn工作空间，您可以完全实现您想要的：https://yarnpkg.com/lang/en/docs/workspaces/.在顶层，您在package.json中设置了三个模块/包(确保在各自的package.jsn文件中正确命名工作区)：

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

一旦你这样做了，你就可以在CRA应用程序或后端导入共享代码，就像这样：

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

缺点是，只要使用CRA，就不能将react组件从共享目录导入前端。这不会影响你现在，因为你只有一个反应应用程序。如果您需要在多个项目之间共享react组件，请查看上面的一些建议，如bit.dev.

附录！！！如果用CRACO替换CRA，现在可以使用CRA和yarn工作区共享React代码。您所要做的就是使用共享的react代码创建另一个工作区。然后在您想要访问的每个模块中创建一个符号链接：

root
├── fontend-one
|   ├── symbolic link to frontend-shared
├── frontend-two
|   ├── symbolic link to frontend-shared
├── frontend-shared

每个CRA前端模块模块还需要一个craco.config.js文件，您可以在该文件中告诉web包不要遵循符号链接：

module.exports = {
// ...
webpack: {
configure: {
resolve: {
symlinks: false
}
}
}
};

您通常从共享前端导入：

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

这是一个不错的低保真解决方案，但在我们使用它的一年里，它已经被证明是强大的

体系结构是一个棘手的问题，每个人都有不同的意见，每个选项都有优点和缺点。

就我个人而言，我认为最好将后端和前端分离为单独的项目，并保持这种状态。现在，随着JavaScript/Rect/Node鼓励基于组件的方法，在它们之间共享代码的一种非常好的方式是Bit.dev.

https://bit.dev

我目前正在使用它在三个web应用程序和几个Node微服务之间共享组件和功能。

React应用程序的一个良好结构可以在这里找到，这个结构运行良好，扩展性很好：

https://hackernoon.com/fractal-a-react-app-structure-for-infinite-scale-4dab943092af

至于Express，有很多方法可以构建项目，但个人建议为Routes创建一个文件夹，为Controllers创建一个子文件夹，这就是Routes的逻辑所在。然后从那里走。查看此链接：

https://www.freecodecamp.org/news/how-to-write-a-production-ready-node-and-express-app-f214f0b17d8c/

根据你的建筑，你可能甚至不需要完整的后端，你可以在这里查看JAMStack了解更多信息：

https://jamstack.org

我会考虑将它们分开，不过随着项目的规模扩大，管理起来会容易得多。你可以在Netlify之类的平台上发布你的前端，然后使用AWS或Azure之类的平台来托管你的Node/Express服务器。

由于依赖性差异很大，为前端和后端提供单独的子项目是非常有意义的。将其混合使用会增加生产部署中的磁盘空间消耗，并违反安全准则。你的文件夹结构是合理的(除了我不确定的public/子文件夹，也许我遗漏了什么)。
方法import { myFunction } from @shared/myFile;是好的。只是不要使用CRA。
对于具有单个前端和单个后端的项目，不需要shared顶级文件夹，因为前端是前端消耗的"UI真相"(例如，与UI相关的类型和组件的来源)的唯一来源，而后端是前端和后端消耗的"API真相"的唯一来源。通过这种布置，仅需要共享@backend/api_shared_stuff。
一些指向可靠资源的链接，其中解释了全栈React开发的项目结构，这将非常有帮助一方面，通常项目作者必须解释大量其他内容，另一方面保持文档(通常是自述文件)合理简洁。您可能会发现，提供子目录结构是这个而不是那个的理由/解释并不是首要任务。

相关内容

最新更新

热门标签：