Рассмотрим класс (например, ExampleUtil
) в файле ExampleUtil.ts
. В настоящее время типы, которые ExampleUtil
использует, хранятся в файле ExampleUtil__TYPES.ts
. Нет проблем при импорте их в ExampleUtil.ts
;в настоящее время в пространстве имен нет необходимости.
Когда я начал использовать ExampleUtil
в других проектах, оказалось, что типы из ExampleUtil__TYPES.ts
зависят от контекста, и их лучше инкапсулировать в пространство имен,Однако имя ExampleUtil
уже используется по классу, поэтому мне нужно выбрать другое имя для пространства имен или разрешить этот конфликт другим методом.
В моей библиотеке я организовал определения типов следующим образом:
import ExampleUtil from "./ExampleUtil/ExampleUtil";
import { Type1, Type2 } from "./ExampleUtil/ExampleUtil__TYPES"
import OtherUtil from "./OtherUtil/OtherUtil";
import { Type3, Type4 } from "./OtherUtil/OtherUtil__TYPES"
// other classes, types and functions from library
/** Re-export for other project.
* Unlike "lodash", where each function is in separate file, herewith
* all files are in same directory, here the developers can organize source files
* by directories, but users does not need to know these directories, because
* they can get everything what they need from single "my-lib.js" file like below:
* import { ExampleUtil, Type1, Type2 } from "my-lib";
* All "my-lib" classes and functions those has not been used, will not be included
* by Webpack to production bundle.
*/
export {
ExampleUtil, Type1, Type2,
OtherUtil, Type3, Type4,
// ... other classes, types and functions from library
};
Если мы обернем Type1
и Type2
без пространства имен ExampleUtil
, конфликт возникнет уже здесь, в my-lib.d.ts
: мы являемся классом импорта и пространством имен с тем же именем, тогда нам нужно повторноэкспортировать оба.
Итак, могу ли я написать код вроде
// ? Namespace
const parameterForExampleUtil: ExampleUtil.Type1 = { /* ... */ };
// ? Namespace ? Class
const result: ExampleUtil.Type2 = ExampleUtil.getSomething(parameterForExampleUtil);
и, если нет, какое имя я могу выбрать для пространства имен? Некоторые хорошие практики из других языков программирования позволяют избежать конфликтов между именем класса и соответствующим пространством имен? Я знаю, что использование префикса I
для интерфейсов, это практика для пространств имен?