忽略某些TypeScript编译错误?

时间:2013-04-15 15:19:19

标签: this typescript tsc

我想知道在编译时是否有办法忽略某些TypeScript错误?

对于大型项目的大多数人来说,使用 this 关键字时我基本上都遇到了同样的问题,我不想把所有的类方法都放到构造函数中。

所以我有一个这样的例子:

TypeScript Example

这似乎创建了完全有效的JS,并允许我解决关键字问题,但是正如您在示例中看到的那样,typescript编译器告诉我,我无法将该代码编译为关键字这在该范围内无效。但是,我不明白为什么它是一个错误,因为它产生了好的代码。

那么有没有办法告诉它忽略某些错误?我确信有时间会有一个很好的方法来管理这个关键字,但目前我发现它非常糟糕。

==编辑==

(除非您关心此问题的背景和部分咆哮,否则不要阅读)

只是为所有这些添加一些背景,以表明我不仅仅是一些坚果工作(我相信很多人仍然会认为我是)并且我有一些很好的理由为什么我希望能够允许这些错误通过。

以下是我之前提出的一些问题,其中使用TypeScript 当前 实现突出显示了一些主要问题(imo)。

Using lawnchair with Typescript

Issue with child scoping of this in Typescript

https://typescript.codeplex.com/discussions/429350(以及我在底部的一些评论)

我遇到的根本问题是我需要保证所有逻辑都在一致的范围内,我需要能够访问knockout,jQuery等内容以及类的本地实例。我以前用JavaScript中的类声明中的var self = this;做了这个并且效果很好。正如之前的一些问题中提到的,我现在不能这样做,所以我能保证范围的唯一方法是使用lambda方法,并且我可以将其中一个定义为类中的方法的唯一方法是在构造函数中,这一部分非常重视个人偏好,但我发现人们似乎认为使用该语法被归类为推荐模式并且不仅仅是一种解决方法,这一点非常可怕。

我知道TypeScript处于alpha阶段并且会发生很多变化,而且我希望我们能够更好地处理这个,但是目前我要么把所有东西弄得一团糟打字稿工作(这是我正在迁移到TypeScript的数百个文件中)或者我只是在这种情况下调用我比编译器更好的调用(非常危险我知道)所以我可以保持我的代码很好并希望当一个更好的模式出来处理时,我可以将其迁移。

另外,我也知道很多人都喜欢这样一个事实,即TypeScript正在接受并试图保持尽可能接近新的JavaScript功能和已知语法,这很好,但是typescript不是下一个版本因为我没有看到在语言中添加一些语法糖的问题,因为想要使用最新和最好的官方JavaScript实现的人仍然可以这样做。

3 个答案:

答案 0 :(得分:6)

作者关于this的特定问题似乎已经解决,但问题在于忽略错误,对于那些最终在这里寻找如何忽略错误的人:

从TypeScript 2.6(于2017年10月31日发布)开始,如果不能正确解决错误或使用像此处已经建议的那样更合适的解决方法,那么现在a way to ignore all errors from a specific line使用// @ts-ignore在目标行之前。

The mendtioned documentation足够简洁,但要概括一下:

// @ts-ignore
const s : string = false

禁用此行的错误报告。

但是,仅在修复错误或使用(x as any)之类的hack时,此方法才是万不得已的方法,这比丢失一行的所有类型检查要麻烦得多。

关于指定某些错误,我们讨论了here, in Design Meeting Notes (2/16/2018) and further comments的当前(2018年中)状态,基本上是

  

“还没有结论

强烈反对引入这种微调。

答案 1 :(得分:5)

我认为你提出的问题是XY problem。您要找的是如何确保我的某些类方法保证具有正确的this上下文?

对于这个问题,我建议这个解决方案:

class LambdaMethods {
    constructor(private message: string) {
        this.DoSomething = this.DoSomething.bind(this);
    }

    public DoSomething() {
        alert(this.message);
    }
}

这有几个好处。

首先,你明确了解发生了什么。大多数程序员可能不会理解关于成员和方法语法在codegen方面的差异的微妙语义。

其次,从查看构造函数可以清楚地看出哪些方法具有保证this上下文。至关重要的是,从性能角度来看,您不希望以这种方式编写所有方法,只需要那些绝对需要它的方法。

最后,它保留了类的OOP语义。实际上,您可以使用super.DoSomething的派生类实现中的DoSomething

答案 2 :(得分:2)

我确信你知道没有箭头符号定义函数的标准形式。还有另一个TypeScript表达式生成完全相同的代码,但没有编译错误:

class LambdaMethods {
    private message: string;
    public DoSomething: () => void;

    constructor(message: string) {
        this.message = message;
        this.DoSomething = () => { alert(this.message); };
    }
}

那为什么这是合法的而另一个不是?那么根据规范:an arrow function expression preserves the this of its enclosing context。因此,它从声明的范围中保留了this的含义。但是在类级this声明一个函数实际上没有意义。

这是一个错误的例子,原因可能更为清楚:

class LambdaMethods {
    private message: string;

    constructor(message: string) {
        this.message = message;
    }

    var a = this.message;  // can't do this
}

初始化程序通过与构造函数结合起作用的方式是一个不能依赖的实现细节。它可能会改变。

  

我确信有时间会有一个很好的方法来管理这个关键字,但目前我发现它非常糟糕。

TypeScript中的一个高级目标(我喜欢)是扩展JavaScript语言并使用它,而不是对抗它。 this如何运作是棘手的,但值得学习。