如何解决打字稿中的循环依赖

Question

设置：

想象一下以下设置：

有一个 api，其中包含文件夹 foo 和 bar。这些文件夹将所有公共内容导出到本地 index.ts ，这将通过 export * from [...] 重新导出公共内容，以使其更加方便。

在我的示例中，存在循环依赖关系，因为 foo.ts 需要 bar 的一部分，反之亦然 - 我完全理解为什么会出现这种情况。

请参阅下面的屏幕截图：

问题：

如何在具有数百个类、函数、常量、类型、枚举等的环境中使用 TypeScript 有效解决此问题？ 我想我需要某种帮助文件来解决共性。

即使我创建了某种需要foo和<的foobar文件夹， code>bar 然后将所有内容导出到一个大导出文件中，它可能很快就会变得混乱。 如果我只需要 bar 或仅 foo 怎么办？命名导出足够好吗？

我也想避免将来出现问题，所以我正在寻找一个强大的解决方案。调用优先级不是我在这里尝试解决的主要问题。更多的是关于如何以智能的方式设置依赖关系。

目标：

我想分别使用 foo 和 bar，它们应该能够彼此共享函数/类型/枚举/接口等。

可以在这里找到一个非常简单的代码片段：

codesandbox。 io

Answer 1

你的例子似乎很通用，所以我尝试描述一些一般的经验法则，但它们可能在某种程度上是固执己见的。

1. 如果 foo 和 bar 之间存在循环依赖，消除它的最简单方法是将所有循环依赖单元提取到单独的模块/目录中，例如 foobar.你提到了这个解决方案，但是依赖的方向应该是不同的。 foo 和 bar 都应该需要 foobar 来提供提取的共享代码。这样您仍然可以单独导入 foo 和 bar （暂时导入 foobar）。
2. 这也适用于您提到的每个 functions/types/enums/interfaces - 如果 foo 和 bar 都使用了某些东西，那么应该放置它在单独的模块/目录中。
3. 关于诸如函数/类型/枚举/接口之类的名称 - 我会考虑使用此类名称作为最后的手段（例如，作为目录树中叶子目录的名称），因为它们通常传达不相关的信息。更好的方法是围绕业务域概念而不是与实现细节相关的名称来组织（并置）代码。这提高了代码的可发现性并降低了代码组织的脆弱性。例如

<sourcesRoot>/api/functions/getUser.ts
<sourcesRoot>/api/functions/getPosts.ts
<sourcesRoot>/api/enums/UserRole.ts
<sourcesRoot>/api/types/User.ts
<sourcesRoot>/api/types/Post.ts
<sourcesRoot>/api/index.ts

，不要考虑使用：

<sourcesRoot>/users/api/getUser.ts
<sourcesRoot>/users/model/User.ts
<sourcesRoot>/users/model/UserRole.ts
<sourcesRoot>/users/index.ts

<sourcesRoot>/posts/api/getPosts.ts
<sourcesRoot>/posts/model/Post.ts
<sourcesRoot>/posts/index.ts

4. 保持 foo 和 bar 小。尝试将 foo 或 bar 中的一些子域/区域/上下文提取到单独的目录中。这应该会生成更小的 index.ts 文件。
5. 这可能是固执己见且不受欢迎的......考虑避免桶文件。在我看来，如果你发布了一个库，barrel 文件会很好地工作。在这种情况下，您可以精确指定公共成员（假设 CommonJS 模块）。然而，在我看来，目录树中较低级别的桶文件没有提供太多价值。您仍然可以直接导入模块（绕过桶文件）。它们使重构速度变慢，因为在许多情况下您需要手动更新桶文件。如果您忘记更新它们，它们有时会创建一个非常讨厌的循环依赖，在运行时以未定义值的形式表现出来。您可能拥有看起来更干净的导入路径，但实际上很少手动使用导入路径。这是 IDE 的工作。

Answer 2

很抱歉给大家带来了关于命名的误解。不幸的是，我有机会在实际应用程序中看到类似的名称，并以某种方式错误地认为您也想使用此约定。当谈到“最终要么是所有东西都堆积起来的巨大文件，要么是超级小文件”。这是一个找到良好平衡点的问题。我不介意很多小文件（js 模块），它们专注于单一功能 - 这是一个标志，表明人们已经从一些更大的用例中正确地提取了更小的职责。这会生成更易于理解、测试和维护的代码。大文件（js 模块）或大类/函数通常是 SRP 损坏的标志。关于 sandbox.io 示例 - 我无法理解它，也不理解 hello 和 world 函数背后的意图。它们只是简单的函数，相互递归调用（导致堆栈溢出）。最简单的重构是仅使用共享函数，例如放置在 foobar 目录中的 buildGreeting(msg1, msg2) 。从 foo 目录导出 const world = 'world'，从 bar 目录导出 const hello = 'hello'，然后在其他一些同级目录中创建一个带有如下调用的模块：

import {hello} from '../foo'
import {word} from '../bar'

buildGreeting(hello, word);

但是，很难说明此示例代码的任何有意义的改进，因为它没有说明任何实际用例。