Ответ 1

Я начал серьезно изучать этот вопрос, но нашел результаты поиска довольно невыполненными.

Прежде всего, вот небольшая дискуссия, которая дает некоторое представление о представлении Sencha на языке TypeScript.

Хотя я не мог найти ничего конкретного для ExtJS 5 (мои извинения), я нашел эту ссылку, которая утверждает, что создает файлы декларации типа TypeScript, используя процесс, который начинается с документации ExtJS. Примеры нацелены на ExtJS 4.1, но, возможно, он может работать с ExtJS 5. Если это так, это решит вашу проблему. Это, конечно, не ответ, но, возможно, это лидерство.

В стороне, разговор, упомянутый выше, не сидел прямо со мной. Он начинается с кажущейся невинной просьбы Sencha рассмотреть возможность, которую TypeScript предоставляет для статического инструментария.

Машинопись

Я просто заметил TypeScript (http://www.typescriptlang.org/), и он выглядит многообещающим. У кого-нибудь есть шанс поиграть с ним еще? Я хочу понять, можно ли создать файл объявления TypeScript для объявления всех типов из структур Ext JS и Sencha Touch. Я бы хотел, чтобы мой статичный анализ и поддержка инструментов для моей разработки Sencha.

Благодарю!

Это ответ Старшего менеджера Sencha:

Еще одна вещь, чтобы сделать вещи уродливыми [TypeScript]

[EDIT] Независимо от того, сколько раз я говорю, что этот комментарий был явно личным комментарием, он по-прежнему личный. Если вы не разговаривали со мной или не следили за мной в Твиттере или что-то еще, я анал о своем коде и синтаксисе, что TypeScript (даже ES6) является уродливым.

Это довольно грубо!

Я лично не знаю менеджера форума, поэтому я не собираюсь говорить с его конкретным уклоном от TypeScript. Но я действительно думаю, что могу дать некоторое представление о том, почему представители Sencha, возможно, не укореняются за успех. Возможно, это поможет вам понять, почему многим людям не может быть очень важно создать файл определения для ExtJS 5.

Обратите внимание, что я могу ошибаться, и есть файл определения ExtJS 5, который еще не дошел до DefinitelyTyped. Мой поиск был далеко не исчерпывающим.

Машинопись

Вот простой пример модели объектно-ориентированного программирования, который использует TypeScript. , Обратите внимание, что конструктор - это функция, которая возвращает экземпляр, состояние которого потенциально может быть изменено или специализировано по сравнению с его прототипом:

function Mammal() {
    //...  
}

Свойство prototype конструктора, которое является прототипом объекта, возвращаемого конструктором, затем может быть расширено с помощью методов и свойств (в смысле ES5 Object.defineProperty). Члены, объявленные в прототипе, не должны воссоздаваться для каждого экземпляра, созданного конструктором:

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

В этом смысле конструктор играет роль класса, а структура его свойства prototype определяет тип объекта, который создается конструктором. Хотя эта схема довольно подробно в ES3 и ES5, особенно при добавлении дополнительного оборудования, необходимого для наследования, это шаблон, используемый ES6 для определения понятия класса. Таким образом, это шаблон, используемый компилятором TypeScript для компиляции класса.

Более полное обращение к этой форме классического объектно-ориентированного программирования в JavaScript, а также методы для наложения классического наследования более подробны, см. Этот пост Дугласа Крокфорда.

Примечательно, что понятие типа существует только во время разработки и выполняется компилятором TypeScript, чтобы помочь вам написать более прочный код.

ExtJS

До того, как TypeScript существовал, я познакомился с моделью классического наследования, используемой платформой Sencha ExtJS. Эта модель предоставляет средства для определения классов и создания экземпляров из их соответствующих типов с использованием нескольких шаблонов, включая шаблон модуля, образец прототипа и шаблон фабрики. Если вы программист ExtJS, вы найдете эти шаблоны достаточно знакомыми, но для справки, пожалуйста, обратитесь к соответствующим разделам " Изучение шаблонов проектирования JavaScript" Адди Османи.

Как чистый разработчик JavaScript, этот метод классического объектно-ориентированного программирования является мощным. Он во многом похож на модель классического объектно-ориентированного программирования, используемого компилятором TypeScript, но с одним ключевым отличием. В ExtJS класс и его тип известны структуре и поэтому существуют во время выполнения. Одна из лучших вещей в ExtJS заключается в том, что он имитирует синтаксис создания класса, как и в Java или С#. Но он бледен по сравнению с методом указания класса в TypeScript.

Когда я впервые был представлен, я был настолько очарован методом определения класса, используемого ExtJS, что создал собственную библиотеку, называемую классической. Я был достаточно вдохновлен, чтобы создать свою собственную библиотеку, чтобы исследовать и расширить определение класса в JavaScript и реализовать его для моего собственного назидания. Если вы нажмете ссылку выше, вы заметите, что проект эволюционировал от системы классов типа ExtJS и в библиотеку базового класса для TypeScript.

Почему это изменение?

Во-первых, TypeScript предоставил модель объектно-ориентированного программирования, которая не только позволила мне использовать привычные шаблоны проектирования ООП, но также предоставляла мне систему статического типа и все инструменты времени разработки, которые соответствовали ей. При первом обнаружении TypeScript (версия 0.8) моя первоначальная реакция заключалась в создании файла определения типа для классического, что было бы аналогичным (но гораздо более простым) стремлением создать его для 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);
        }
    },

});

Рассмотрим интерфейс, определенный прототипом выше. Если требуется статическая типизация в 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;
    }
  }
}

Мало того, что этот интерфейс должен быть определен наряду с определением ExtJS, но экземпляры должны были бы иметь свой тип, указанный дважды, один раз как WebApp.model.RenderableRecord (или как строка с тем же именем при вызове Ext.create), а затем снова путем литья его к соответствующему типу TypeScript. Это большая работа, чтобы получить статическую типизацию, которая, в результате кастинга, все еще подвержена ошибкам!

Так в чем проблема?

Проблема в том, что в игре есть две системы типов. Одна из них - это система типа времени разработки, применяемая компилятором TypeScript. Другая - система типа времени выполнения, определенная ExtJS. Эти системы двух типов очень похожи в том, как они реализованы, но каждый из них имеет четкий синтаксис и поэтому должен быть определен отдельно. Большая часть значения системы статического типа теряется, если необходимо сохранить две копии каждого интерфейса.

Вот более полное описание препятствий, которые необходимо преодолеть при интеграции TypeScript и ExtJS. Он также ссылается на проект GitHub выше. Автор приходит к выводу, что

К сожалению, TypeScript и ExtJs не работают слишком хорошо вместе.

Суть в том, что ExtJS и TypeScript определяют свои собственные системы типов, которые не совсем играют по тем же правилам. Поэтому ExtJS и TypeScript принципиально несовместимы друг с другом...

... хорошо в корне слишком сильное слово, но для эффективной работы двух инструментов требуется много работы. Поэтому, если бы я был старшим менеджером форума для Sencha, я, возможно, не стал бы корневать для TypeScript.

Лично я предпочитаю предварительный просмотр ES6, систему статического типа и инструментарий времени разработки, предоставляемый TypeScript. И это позор, который я должен выбрать, потому что два не одного типа - один является фреймворком, а другой - языком. И некоторые люди уверены, что идут очень долго, чтобы сделать их совместимыми.

ExtJS - мощная инфраструктура JavaScript, которая, я уверен, только обогатилась во времени. Но как бы то ни было, ExtJS лучше всего подходит для использования в качестве инфраструктуры JavaScript. Или процитировать того же менеджера форума:

... вы можете написать правильный и продуктивный JavaScript без необходимости компилятора, такого как coffeescript или машинопись.

ExtJS обеспечивает один подход к классическому объектно-ориентированному наследованию в JavaScript в качестве основы. TypeScript предоставляет второй подход в качестве языка. Если вас интересует TypeScript, взгляните на классический. Это далеко не профессиональная структура, как ExtJS, но она дает мнение о том, какие инструменты могут выглядеть, когда они созданы для разработчиков TypeScript.

Ответ 2

Недавно я работал над некоторыми определениями машинописного текста для ExtJS, а также вносит свой вклад в другой проект, который предоставляет разветвленный компилятор Typcript, который более совместим с ExtJS.

См. Https://github.com/fabioparra/TypeScript

Ответ 3

Перейдите, чтобы найти определения типов ExtScript - Premium TypeScript для Sencha Ext JS

https://github.com/thanhptr/extts

Поддерживаются почти все последние версии ExtJS 4.x, 5.x, 6.x, последняя версия 6.0.2.437.

Все, что вы можете найти в документе API ExtJS, содержится в определениях типов с строго типизированной поддержкой (например: Ext.dom.Element, ButtonConfig,..)

Ответ 4

Определенно, есть место для определений TS ExtJS. Хотя верно, что TypeScript и ExtJS используют несовместимые системы классов, некоторые стратегии могут использоваться в качестве обходного пути:

Использовать исправленный TS-компилятор

Исключатель ExtJS, разработанный fabioparra и связанный здесь Гаретом, является одним из возможных путей решения проблемы. IMHO главный недостаток заключается в том, что он усложняет интеграцию с IDE, поддерживающей язык TS. Например, нет документации относительно совместимости этого решения с существующими плагинами Eclipse TS. Кроме того, он не уверен, что разработка патча будет сохранена для будущих версий TypeScript.

Использовать статические методы TS в качестве фабрики объектов ExtJS

Идея здесь заключается в предоставлении набора статических методов, заменяющих конструкторы классов ExtJS. Таким образом, становится возможным создавать экземпляры объектов ExtJS при использовании устаревшего компилятора TS. Недавно я представил это альтернативное решение с именем TypExt на github (https://github.com/david-bouyssie/TypExt). Обратите внимание, что он должен использоваться в сочетании с правильными определениями ExtJS TS (https://github.com/david-bouyssie/TypExt/tree/master/typescripts). В настоящее время поддерживается только ExtJS 5.1.1, но я планирую расширить использование TypExt с другими версиями ExtJS.