用于定义外部可配置选项的Typescript习语

时间:2017-09-28 18:46:48

标签: typescript configuration instantiation idioms

人们使用哪些习惯用法来定义Typescript中的配置选项,以便其他模块可以使用选项类型定义?

我来自Java的背景,对我来说显而易见的事情 - 将内部类型放在默认导出上 - 由于a bug in Typescript而无法正常工作:

export default class MyClass {

    constructor(opts: Options) {
        //...
    }
}

namespace MyClass {
    export interface Options {
        //...
    }
}

相反,似乎我必须将MyClassOptions导出为模块的兄弟,或者将它们作为默认值导出到单独的模块中。

这些解决方案中的第一个要求我在创建一个只有一个类的模块时非常有创意,因为除了类之外,模块还会公开一个接口。

第二种解决方案会产生大量额外的模块/文件,特别是因为这是Javascript程序员用来配置所有内容的方式。

想到的唯一合理的解决方案如下:

  • 将类和选项界面导出为同一模块的兄弟姐妹。
  • 为该课程命名该模块(例如myclass)。
  • 其他地方,import { MyClass, Options as MyClassOptions } from 'myclass'

也可能是Typescript方法是从单个模块中导出大量类,为调用者的命名空间唯一命名。在这种情况下,也许人们正在做类似import { MyClass, MyClassOptions } from 'bigmodule'的事情。功能齐全,但并不理想。

谷歌搜索并没有让我了解人们实际在做什么。那么常见的习语是什么?我是否完全偏离如何在Typescript世界中使用选项配置?其他一些配置模型更普遍吗?使用命名选项类型进行分配?

更新#1:为什么重要?因为我正在制作一个NPM出版的框架,希望其他人能够轻松熟悉配置问题。

更新#2:我已经了解到上述方法已接近可行的方法,并且更适合重构。该模块将执行此操作:

export class MyClass { // no default

    constructor(opts: Options) {
        //...
    }
}

export namespace MyClass { // with export
    export interface Options {
        //...
    }
}

客户端可以干净利落地导入如下:

import { MyClass } from 'mymodule';

function getOptions(): MyClass.Options {
    //...
}
let obj = new MyClass(getOptions());

但我仍然不知道会有什么样的惯例。当我学习各种框架时,我会回报,除非有人能打败我。

1 个答案:

答案 0 :(得分:1)

模块不等于单个类,它是一组紧密相关的行为。

考虑到这一点,我会建议你现有的建议:

export class MyClass {
    constructor(opts: Options) {
        //...
    }
}

export interface Options {
    //...
}

命名

还有一个技巧来命名诸如模块之类的东西。写一个"同类事物的快速表"然后在你打电话给那些东西之后命名你的模块。

例如,如果您的课程被称为" Crisps",您可以将其展开:

  1. 薯片
  2. 螺母
  3. 猪肉Scratchings
  4. 然后你可以命名你的模块" Snacks"。

    大模块

    如果你因为同样的原因而把代码放在一起,并且当它因为一个不同的原因而发生变化时将它分开,你就不应该找到自己的大模块。