Ответы пользователя по тегу TypeScript
  • Где хранить интерфейсы?

    только рест апи. Надо затипизировать то, что может вернуть бэкенд.

    Тогда почему бы не описать REST API с помощью OpenAPI-спеки и на её основе не сгенерить код?
    Ответ написан
  • Observable что это?

    https://www.typescriptlang.org/docs/handbook/gener...

    нет смысла разжёвывать это в ответе.
    Ответ написан
    Комментировать
  • Js библиотека для сериализации десериализации обьектов?

    Посмотрите на https://github.com/JohnWeisz/TypedJSON или https://www.npmjs.com/package/json2typescript . Общая задача - добавить информацию о сериализуемом объекте в рантайм (т.к. сам TS этого делать не будет by-design), для чего используются декораторы или другие схемы задания этой информации, и затем воспользоваться этой информацией при конвертации в JSON и обратно.
    Ответ написан
    Комментировать
  • Какие инструменты написать самому?

    Новичку можно написать пару проектов для предметных областей по вкусу, а потом быстро станет ясно, каких инструментов ему как разработчику не хватает. Самое главное - не писать библиотек только ради написания библиотек. На гитхаб не обязательно выкладывать только то, что нужно другим разработчикам, можно написать законченное приложение или сервис, которые нужны простым людям.
    Ответ написан
    1 комментарий
  • В чем смысла в TypeScript?

    Комментировать
  • Как реализовать директивы препроцессора в Typescript?

    1. Берёте https://github.com/jsoverson/preprocess .
    2. Ищите лоадер для вашей системы сборки (мы используем с вебпаком).
    3. Профит.
    Ответ написан
    Комментировать
  • Как запретить автоматическое приведение number к enum?

    Никакая, это By Design.
    https://github.com/Microsoft/TypeScript/issues/6131
    It's to allow patterns such as n = n + 1.
    Ответ написан
    Комментировать
  • Как организовать структуру проекта на Node.js правильно?

    Разработчики объясняют это тем, что они используют TypeScript, и он находится в папке src, поэтому вот так все собирается

    Логично, нормальное решение.

    Не нравится идея копировать dist и все вложенные папки

    А в чём проблема? В dist не должно быть лишнего хлама, .git и прочего добра, по сути это готовая сборка приложения для деплоя, почему бы её не скопировать?

    Не рекомендуют запускать npm install заново на сервере, так как по их мнению могут подтянуться совсем другие версии

    А нехрен позволять npm-у ставить нефриженную версию в package.json. Нам вот уже настохорошело что проект ломается сам по себе из-за выхода новых версий библиотек, и мы зафризили все пакеты. Это нормальная ситуация, если у вас не библиотека, а конечное приложение. package-lock.json пытались использовать, но потом отказались - в версиях NPM 5.0-5.2 он работал отвратительно, сейчас уже может получше, не знаю.
    Ответ написан
  • Существует ли в Typescript возможность использования динамической памяти?

    В TypeScript нет и не может быть иной модели управления памятью, нежели в JS, т.к. TypeScript это надмножество JS, добавляющее статическую типизацию и ещё ряд плюшек. Компиляция из TS в JS происходит довольно прямолинейно, ничего вроде своего менеджера памяти или прочих абстракций там нет.

    Поэтому нужность ручного управления памятью (вы ведь это понимаете под динамической памятью?) в TS сводится к вопросу нужности ручного управления памятью в JS. Я не уверен, что последний вопрос корректен, т.к. язык - это набор готовых решений, среди которых стратегия управления памятью - вещь довольно базовая, от неё очень много зависит в языке и его экосистеме, поэтому просто так такая вещь меняться не будет, обычно такие решения принимаются ещё при создании языка и более не пересматриваются.

    Поэтому вопрос переходит к тому, какой язык вам нужен. Хотите попытаться писать браузерный код на C++? Попробуйте поэкспериментировать с WebAssembly.
    Ответ написан
    Комментировать
  • Использование библиотеки не имеющей typescript d.ts?

    Ответ очевиден - написать type definitions самостоятельно.
    Ответ написан
    4 комментария
  • Typescript: нужно ли импортировать все типы, связанные с импортированным интерфейсом?

    Если вы сами используете идентификатор типа TBar - то нужно импортировать, не используете, т.е. например пишете вот так:
    const foo: IFoo = {
        bar: [
            {a: "white", b: 10},
            {a: "black", b: 20}
       ]
    }

    то не нужно.
    Ответ написан
  • Как правильно указывать noEmitHelpers для TypeScript?

    Можно ставить. Это не значит, что "будут недоступны некоторые современные фичи", т.к. тогда не было бы доступно даже extends для классов, а не только современные фичи.

    Если вы поставите noEmitHelpers, то компилятор просто перестанет вставлять хелперы в начало каждого скомпиленного модуля, но продолжит использовать хелперы при необходимости. Для вас это значит, что вы можете добавить хелперы самостоятельно иным способом, например через глобальные переменные. Мы делали такую вещь с помощью webpack.ProvidePlugin, который автоматически инжектил нужные реквайры при использовании TS-ом хелперов (сам компилятор TS не догадывался об этом, он просто не эмитил хелперы в каждом файле). Это всё делалось с целью экономии, чтобы не иметь код хелперов в начале каждого скомпиленного файла.

    Затем в 2.1 появилась опция importHelpers, которую мы долго ждали, и мы сразу перешли на неё, чего и вам советую. В этом случае компилятор вставляет код импорта реализации хелперов из специального пакета tslib, который вам нужно будет добавить в runtime-зависимости в package.json если вы захотите использовать опцию importHelpers.
    Ответ написан
    1 комментарий
  • Почему данный код работает?

    Вот поэтому (исходник: https://github.com/DefinitelyTyped/DefinitelyTyped... ):
    interface NodeRequireFunction {
        (id: string): any;
    }
    
    interface NodeRequire extends NodeRequireFunction {
        resolve(id: string): string;
        cache: any;
        extensions: any;
        main: NodeModule | undefined;
    }
    
    declare var require: NodeRequire;

    Результат работы require типизирован как any, а any можно положить в переменную любого другого типа (так сделано, чтобы any отрабатывал как средство отключения строгой типизации).

    Чтобы выполнять проверку типов, вам либо нужно подключать config.json не как json, а как модуль, и делать это средствами TypeScript, либо парсить JSON средствами, валидирующими по JSON Schema.

    Можете посмотреть этот проект: https://github.com/JohnWeisz/TypedJSON (правда требует работы с декораторами).
    Ответ написан
    Комментировать
  • Что за проблема в объединении типов Array?

    https://github.com/Microsoft/TypeScript/issues/10620

    Комментарий mhegazy о filter, с которым в общем-то такая же ситуация, что и с map:
    This is a bit subtle, but number[] | string[] !=== (number | string)[]. The first one has an assert on homogeneity, while the second does not. just as in the example noted above by @kaotik4266, [0, "1", 2] is not of type number[] | string[].

    There is not a meaningful way to describe the general case for merging unmatching signatures; while filter might be arguably safe, push is not. So merging the signatures of (number[]|string[]).push(...) th same proposed for filter would result in push(a: number | string); which means that we are treating the original type as (number | string)[], which is not type safe.

    So the general case, is there is no common signatures between the two types, and thus the resulting union type does have a filter property but it does not have a signature, and hence the error message Cannot invoke an expression whose type lacks a call signature.

    Можете написать себе свой собственный тайпгвард, который выполнит вам сужение типа:
    function isNumbers(arr: number[] | string[]): arr is number[] {
        return arr.length === 0 || // В случае нулевой длины тип элемента массива нам не важен, примем его за number
            typeof arr[0] === "number"; // Либо проверим фактический тип первого элемента. Этого должно быть
                // достаточно, т.к. в типе 'arr' декларируется однородность массивов
    }
    
    function getHandler(handlers: number[] | string[]): number[] | string[] {
        if (isNumbers(handlers)) {
            return handlers.map(handler => handler);
        } else {
            return handlers.map(handler => handler);
        }
    }
    Ответ написан
    3 комментария
  • Можно учить typescript без нативного js?

    Можно учить typescript без нативного js?

    Можно, но нет смысла - фактически выучите JS с плюшками TS поверх него. Поэтому лучше таки поучить JS а затем разобраться, что добавляет TS сверху. Это всё потому, что TS расширяет синтаксис EcmaScript, и совместим с ним (с какой версией ES - зависит от версии компилятора).
    если нет обоснованной причины писать на ts - не пиши

    Почти всегда есть обоснованная причина писать на TS.
    TS похож на конструктор сайтов. Вроде сайт на TS, но работает на JS. Так в этом конструкторе придется еще и свою локигу вставлять.

    Вообще не понял смысла этого ответа. Возможно, человек спутал TS и Ангуляр. TS похож на конструктор сайтов не больше, чем C#.
    И какие плюсы ts перед js?

    В вашем коде будет порядок, если вы этого захотите.
    Ответ написан
    Комментировать
  • TypeScript для Node.js - как настроить для совместной работы?

    Теперь осталось понять, как включить автоматическое генерирование заголовков для своих модулей и как их публиковать.

    1. https://www.typescriptlang.org/docs/handbook/compi... , --declaration.
    2. Используем SystemJS при генерации кода или используем бандлер.
    3. Публикуем собранный js-бандл.
    Отдельно о публикации - над npm я использую sinopia, хочется работать с похожей утилитой и для ts заголовков.

    С TypeScript 2 никаких утилит не надо, всё публикуется в NPM. Варианта два - либо в своём пакете (имхо, предпочтительнее), либо в @types. Подробнее: www.typescriptlang.org/docs/handbook/declaration-f... . По сути, если вы не делали бандл, то тогда рядом с каждым js будет лежать .d.ts. Если вы делаете бандл, то тогда вам нужно попросить tsc сгенерить .d.ts в виде одного файла для всех имеющихся модулей, и тогда вы в package.json с помощью main и types указываете entry-файл и файл с type definitions.
    Ответ написан
    5 комментариев
  • Какие альтернативы можно выбрать для JavaScript?

    Что кто может сказать про TypeScript?

    Учите, не пожалеете.
    • типизация поставит мозги на место;
    • фичи, связанные с типами и инкапсуляцией надстраиваются над JS, т.е. не нужно знакомиться с полностью новым синтаксисом; даже терминологически разработчики TS стараются не расходиться с JS;
    • язык позволяет не бояться роста проекта; собственно сейчас большой объём фронтэнд-кода и заставил нас переходить на TypeScript; чем больше кода и чем больше команда, тем выгоды от TS перевешивают затраты на внедрение;

    Минусы:
    • усложнение процесса сборки, т.к. нужна компиляция (это относится к любому из не-JS языков);
    • придётся заботиться о наличии type definitions;
    • есть некоторые нетривиальные вопросы во взаимодействии с JS кодом. В общем-то ничего проблемного, просто нужно понимать, что как работает;

    Как человек, привыкший к языкам со статической типизацией, я не вижу для себя смысла писать на чистом JavaScript после освоения TS. Конечно, за исключением случаев поддержки существующего кода и скриптов на 10 строчек.
    Ответ написан
    1 комментарий
  • Почему скомпилированный TypeScript намного читабельнее чем транспилированный ES6?

    1. Потому что одной из целей при создании TypeScript была именно читабельность выходного JS-кода. Цитата из TypeScript Design Goals:

    Goals
    ...
    4. Emit clean, idiomatic, recognizable JavaScript code.
    ...
    Non-goals
    2. Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.

    2. Потому что TypeScript прежде всего - это строгая типизация (а также сокрытие и прочие связанные вещи). Поэтому бОльшая часть рантайм-проверок не нужна в коде, генерируемом TS - компилятор всё проверяет при сборке. Сравним результаты компиляции следующих фрагментов кода Бабелем и tsc:
    фрагмент на ES6:
    class Foo {
      constructor(a, b) {
        this.a = a;
        this.b = b;
      }
      
      bar() {
        return this.a + this.b;
      }
    }

    фрагмент на TS:
    class Foo {
      private a: number;
      private b: number;
    
      constructor(a, b) {
        this.a = a;
        this.b = b;
      }
      
      bar() {
        return this.a + this.b;
      }
    }


    Как вы можете заметить, TS генерирует только самое необходимое, в то время как Бабель в дефолтных настройках генерирует хелперы вроде _createClass и _classCallCheck, которые определены достаточно нетривиально. Зачем он это делает? Затем, что Бабель генерирует код, "безопасный" в райнтайме. Он не рассчитывает на то, что какие-либо проверки будут выполняться при компиляции. Например, в хелпере _classCallCheck проверяется, что конструктор не был вызван, как обычная функция.
    TS считает такие проверки избыточными - его разработчики считают, что все они должны происходить именно при компиляции. Дополнительных проверок для вызывающего кода не производится.
    Ответ написан
    Комментировать