嵌套名称空间与ES模块 [英] Nested namespaces vs. ES modules

问题描述

使用传统的JavaScript命名间隔技术，即使在多个文件上，我也可以创建嵌套的逻辑分组.如何将其替换为ES模块别名导入.

With traditional JavaScript namespacing techniques I am able to create a nested logical grouping, even over multiple files. How should I replace that with ES modules alias import.

考虑以下情况:我希望所有代码都位于CompanyName命名空间中，然后按产品分组，在一个产品中，我可能有一组共享函数，并且可以按主题分组(在Java，C#等许多语言中很常见)等等.).

Consider the case where I want all my code in a CompanyName namespace, then group by products and within a product I may have a group of shared functions and these could be grouped by topic (very common in many languages like Java, C# etc.). F.e.

CompanyName = {
    ProductName1: {
        Shared: {
            Database: {
                enumerateDatabases: function() {
                    ....
                }
                ...
            }
        }
    },
    ProductName2: {
        ....
    }
}

如果我正确理解ES模块，则允许我恰好使用一个别名来创建名称空间，例如.

If I understand correctly ES modules allow me to use exactly one alias to create a namespace, f.e.

import * as CompanyName from ...

仅像CompanyName这样的别名肯定不够具体.别名

An alias like CompanyName only is certainly not specific enough. An alias like

import * as CompanyNameProductName1SharedDatabase from...

几乎是不可读的，并且是一个简单的别名，例如

is almost unreadable and a simple alias like

import * as Database from...

可能很快就会变得模棱两可，而我不得不使用类似的别名

may quickly become ambiguous and I would have to go with aliases like

import * as MyDatabase from...
import * as YourDatabase from...

这是否意味着无法对代码进行如上所示的分组?还是应该同时使用这两种技术?

Does that mean there is no way of grouping code as shown above? Or should I go with a mixture of both techniques?

推荐答案

如果我正确理解ES模块，则可以使用一个别名来创建名称空间

If I understand correctly ES modules allow me to use exactly one alias to create a namespace

是的，别名必须是简单的标识符，没有嵌套.请注意，与 Companyname.Productname1.Shared.Database 相比， CompanynameProductname1SharedDatabase 并不那么糟糕-即使使用其他语言，您也不会每次都写完整的程序包名称，但是它是一个合理的别名.甚至可以使用 CPSDb 这样的缩写.

Yes, aliases must be simple identifiers, there is no nesting. Notice that CompanynameProductname1SharedDatabase isn't that bad compared to Companyname.Productname1.Shared.Database - even in other languages you wouldn't write the whole package name every time, but give it a reasonable alias. Maybe even with abbreviations like CPSDb.

一个简单的别名，例如 import * as from ...... 可能很快就会变得模棱两可

A simple alias like import * as Database from... may quickly become ambiguous

不，不应该.Product2不太可能需要导入Product1的数据库.如果您确实在同一模块中确实有多个数据库，则只需消除歧义即可.

No, it should not. It's quite unlikely that Product2 would need to import Product1's database. You would only need to disambiguate if you really have multiple databases in the same module.

只需为 current 模块选择合理的别名.这可能意味着根据要导入的位置使用不同的别名，这很好:

Just choose reasonable aliases for the current module. That might mean using different aliases depending on where you are importing it, and that's fine:

// src/productname1/shared/index.js
import * as Database from './database.js';

// src/backend/init.js
import * as Productname1SharedDatabase from '/productname1/shared/database.js';

还要注意，在JS中完全不使用名称空间导入是很不常见的，仅当您从模块导入许多绑定并且需要从其他模块消除歧义时才使用它们.您会看到

Also notice that it's rather uncommon in JS to use namespace imports at all, they're only used when you import many bindings from a module and need to disambiguate them from other modules. You'll see

import { enumerateDatabase } from './database.js';

的使用频率更高，而且很显然，可以在数据库模块中找到 enumerateDatabase 函数.请注意，JavaScript中没有隐式绑定:如果您忘记了标识符的来源，您将始终在当前文件中找到其(导入)声明，因此可以轻松地查找它.此外，您的IDE将通过显示名称解析到的位置来为您提供帮助.

much more often, and it's clear already that an enumerateDatabase function would be found in the database module. Notice that there are no implicit bindings in JavaScript: if you forgot where an identifier came from, you will always find its (import) declaration in the current file so you can easily look it up. Additionally, your IDE will help you by showing where the name resolves to.

这篇关于嵌套名称空间与ES模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！