完全限定名称与进口丛林
完全限定名称与进口丛林
最初发表于 魂斗罗
打开任何 Node.js 项目和该项目中任何深度嵌套的文件，您将看到的第一件事是：
从“@sentry/node”导入 {configureScope}；
从“序列化错误”导入 { serializeError }；
导入 { type CommonQueryMethods, sql } from 'slonik';
从'zod'导入{z}；
从'../../Logger'导入{记录器}；
从'../services'导入{ type CustomerIOService }；
从'../types'导入{ type SendPlainEmailOptions }；
从'./fetchUserSettings'导入{ fetchUserSettings }；
您所看到的是来自应用程序中各种路径的大量导入。
Debating between different import path strategies
老实说，我不知道我们为什么要这样做。明确是好的，但是当试图弄清楚有多少 ../ 添加到你的导入路径时，它是以不断猜测游戏为代价的，而且一般来说，需要记住所有东西的位置。
在 TypeScript 中，我们可以通过使用来减少猜谜游戏 路径映射 .一个常见的配置将是 “路径”：{“@/”：[ _“”_ ]} 现在允许使用绝对路径导入所有内容。这有助于将上述代码重写为以下内容：
从“@sentry/node”导入 {configureScope}；
从“序列化错误”导入 { serializeError }；
导入 { type CommonQueryMethods, sql } from 'slonik';
从'zod'导入{z}；
从'@/Logger'导入{ Logger }；
从“@/customer/services”导入 { type CustomerIOService }；
从'@/customer/types'导入{ type SendPlainEmailOptions }；
从“@/customer/routines/fetchUserSettings”导入 { fetchUserSettings }；
我认为上面的内容已经更容易理解了，因为我们拥有整个上下文，只需查看代码就可以知道正在导入的内容。而对于相对路径，我们需要做心理操来计算相对路径解析到什么。然而，这种模式仍然需要记住一切都在哪里。为什么？它有什么好处？也许有更好的方法……
使用完全限定名称
如果我们可以从一个文件中导入所有项目依赖项不是更容易吗？
进口 {
配置范围，
序列化错误，
键入 CommonQueryMethods，
sql,
z,
记录仪，
输入 CustomerIOService，
键入 SendPlainEmailOptions，
获取用户设置
} 来自“@/index”；
这种方法的好处是我们永远不需要记住某个东西的路径来导入它——我们只需要知道我们想要导入什么。这也使得在处理错误时更容易存根依赖项和猴子补丁依赖项。
缺点是它要求代码库中具有公共接口的每个方法和变量都必须具有唯一的名称（因此是完全限定的）。尽管这不是常态，但我肯定会认为这是一个好处，因为它强制选择描述性的函数名称，而当你不能选择时，它可能表示代码异味。
我看不出我们不这样做的充分理由。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
