extjs - ExtJS 5 的 TypeScript 定义

Question

有人在为 ExtJS 5 研究 TypeScript 定义吗？我一直在检查绝对类型，但没有事件:

https://github.com/borisyankov/DefinitelyTyped/tree/master/extjs

Answer 1

我开始认真研究这个问题，但发现搜索结果相当不令人满意。

首先，here is a small discussion which provides some insight into Sencha's view on TypeScript .

虽然我找不到任何特定于 ExtJS 5 的内容(抱歉)，但我确实找到了 this link ，它声称使用从 ExtJS 文档开始的过程生成 TypeScript 声明文件。这些示例针对 ExtJS 4.1，但也许它可以与 ExtJS 5 一起使用。如果是这样，它将解决您的问题。这当然不是答案，但也许是线索。

顺便说一句，上面提到的谈话并不适合我。它始于一个看似无害的请求，让 Sencha 考虑 TypeScript 为静态工具提供的潜力。

TypeScript

I just spotted TypeScript (http://www.typescriptlang.org/), and it looks promising. Has anybody had a chance to play around with it yet? I want to understand if it would be possible to produce a TypeScript declaration file to declare all the types from the Ext JS and Sencha Touch frameworks. I'd love to have better static analysis and tool support for my Sencha development work.

Thanks!

这是来自 Sencha 高级论坛经理的回应:

Just another thing to make things ugly [TypeScript]

[EDIT] Regardless of how many times I say this comment was obviously a personal comment, it's still personal. If you haven't talked to me or followed me on Twitter or anything, I'm anal about my code and the syntax that TypeScript (even ES6) is ugly.

真是太狠了!

我个人不认识论坛经理，所以我不会谈论他对 TypeScript 的特殊偏见。但我确实认为我可以提供一些见解，说明为什么 Sencha 代表可能不支持它的成功。也许这会帮助您理解为什么许多人可能不会优先考虑为 ExtJS 5 创建定义文件。

请注意，我可能是错的，那里有一个 ExtJS 5 定义文件，但还没有将它加入到确定类型中。我的搜索远非详尽无遗。

typescript

Here is a simple example of the model of object-oriented programming that TypeScript uses. .请注意，构造函数是一个函数，它返回一个实例，该实例的状态可能已从其原型(prototype)的状态修改或特化:

function Mammal() {
    //...  
}

构造函数的原型(prototype)属性恰好是构造函数返回的对象的原型(prototype)，然后可以使用方法和属性进行扩展(在 ES5 Object.defineProperty 意义上)。不必为构造函数创建的每个实例重新创建在原型(prototype)上声明的成员:

Mammal.prototype = function giveBirth() {
    //...
}

从这个意义上说，构造函数扮演了一个类的角色，它的原型(prototype)属性的结构定义了构造函数创建的对象的类型。虽然这种模式在 ES3 和 ES5 中相当冗长，尤其是在添加继承所需的额外机制时，但 ES6 使用它来定义类的概念。因此，它是 TypeScript 编译器用来编译类的模式。

有关 JavaScript 中这种经典面向对象编程形式的更完整处理，以及使经典继承更加简洁的技术，请参见 this post by Douglas Crockford .

值得注意的是，类型的概念仅存在于设计时，并且由 TypeScript 编译器强制执行以帮助您编写更可靠的代码。

ExtJS

在 TypeScript 出现之前，我已经熟悉 Sencha 的 ExtJS 框架采用的经典继承模型。该模型提供了一种使用多种模式(包括模块模式、原型(prototype)模式和工厂模式)定义类并从其对应类型创建实例的方法。如果您是 ExtJS 程序员，您会发现这些模式非常熟悉，但作为引用，请参阅 Learning JavaScript Design Patterns 的相应部分。通过艾迪奥斯曼尼。

作为一个纯 JavaScript 开发者，这种经典的面向对象编程方法非常强大。它在许多方面与 TypeScript 编译器使用的经典面向对象编程模型相似，但有一个关键区别。在 ExtJS 中，类及其类型是框架已知的，因此在运行时存在。 ExtJS 最好的事情之一是它模拟了创建类的语法，就像在 Java 或 C# 中所做的一样。但与在 TypeScript 中指定类的方法相比，它显得苍白无力。

刚开始介绍的时候，我对 ExtJS 使用的类定义方法非常着迷，于是我创建了一个自己的库，名为 classical .我受到了足够的启发，创建了自己的库，以便探索和扩展 JavaScript 中的类定义，并为我自己的教育而实现它。如果您单击上面的链接，您会注意到该项目已经从类似 ExtJS 的类系统演变为 TypeScript 的基类库。

为什么要改变？

首先，TypeScript 提供了一个面向对象编程模型，它不仅让我能够使用熟悉的 OOP 设计模式，而且还为我提供了一个静态类型系统和所有与之相关的设计时工具。当第一次发现 TypeScript(0.8 版)时，我最初的 react 是为经典创建一个类型定义文件，这与为 ExtJS 创建一个类型定义文件类似(但要简单得多)。在我完成这项任务后，生成的库的语法简直是一场灾难!我想探索出了什么问题，我将使用 ExtJS 中的一个简单示例来进行。

这段代码取自上面提到的讨论，看起来像一个标准的 ExtJS 类定义:

Ext.define('WebApp.model.RenderableRecord', {
    extend: 'Ext.data.Model',
    idPropert: 'id',

    isRenderableRecord : true,

    fields: [
        { name: 'id', type: 'string' },
        { name: 'name', type: 'string' },
        {
            name: 'renderable',
            convert: function (val, model) {return val;}
        },
    ],

    renderItems: function (renderer: Function) {
        var me = this;
        return function (config: Object) {
            renderer(me.get('renderable'), config);
        }
    },

});

考虑由上面的原型(prototype)定义的接口(interface)。如果需要 TypeScript 中的静态类型，可以创建一个如下所示的界面:

module WebApp {
  module model {
    export interface RenderableRecord extends Ext.data.Model {
      idPropert: string;
      isRenderableRecord: boolean;
      fields: Array<Field>;
      renderedItems(renderer: Function);
    }

    //Assume Ext.data.Model and Field are defined already
    //and that the Field interface looks something like this:
    export interface Field {
      name: string;
      type: string;
      convert: Function;
    }
  }
}

不仅该接口(interface)必须与 ExtJS 定义一起定义，而且实例必须将它们的类型指定两次，一次作为 WebApp.model.RenderableRecord(或作为调用 Ext.create 时的同名字符串)，然后再次通过将其转换为适当的 TypeScript 类型。要获得静态类型需要做很多工作，也就是说，作为转换的结果，仍然容易出错!

那么有什么问题呢？

问题是有两种类型系统在起作用。一种是 TypeScript 编译器强制执行的设计时类型系统。另一种是 ExtJS 定义的运行时类型系统。这两种类型系统在实现方式方面非常相似，但它们都有不同的语法，因此必须单独指定。如果必须维护每个接口(interface)的两个副本，则静态类型系统的大部分值(value)都会丢失。

Here is a more complete treatment of the hurdles that one must overcome when integrating TypeScript and ExtJS .它还引用了上面的 GitHub 项目。作者得出的结论是

Unfortunately, TypeScript and ExtJs do not seem to work too well together.

最重要的是，ExtJS 和 TypeScript 都定义了自己的类型系统，它们的规则并不完全相同。因此 ExtJS 和 TypeScript 从根本上是不兼容的......

...从根本上说是一个词太强了，但是要有效地将这两个工具一起使用需要做很多工作。因此，如果我是 Sencha 的高级论坛经理，我可能也不会支持 TypeScript。

就个人而言，我更喜欢 ES6 预览版、静态类型系统和 TypeScript 提供的设计时工具。很遗憾我什至不得不选择，因为两者不是同一类型 - 一个是框架，另一个是语言。有些人肯定会这样做 go to great lengths to make them compatible .

ExtJS 是一个强大的 JavaScript 框架，我相信它只会随着时间的推移变得更加丰富。但事实上，当用作 JavaScript 框架时，ExtJS 处于最佳状态。或者引用同一个论坛管理员的话:

...you can write correct and productive JavaScript without the need of any compiler like coffeescript or typescript.

ExtJS 作为框架提供了一种在 JavaScript 中实现经典的面向对象继承的方法。 TypeScript 提供了第二种方法作为语言。如果您对 TypeScript 感兴趣，请查看 classical .它远不是像 ExtJS 这样的专业框架，但它确实提供了关于为 TypeScript 开发人员构建的工具可能是什么样子的意见。