Comments 32
— Отсутствие модульности
уже нет
— Нелогичное поведение
по мне так в C++ гораздо больше нелогичностей
— Динамическая типизация — нет IntelliSense, из-за чего мы не видим, какие ошибки будут возникать во время написания, а видим их только во время исполнения программы
для этого есть голова
name: «My name»
};
let i: number;
let s: string = «name»;
i = a[s];
Таким же способом можно получить доступ к приватным членам класса… Код, конечно, попахивает. IntelliSense говорит, что все ОК (если бы было i = a[«name»], тогда да — подсветил бы ошибку).
P.S.: За такое и сам бы по руках бил.
Единственный реальный недостаток по сравнению с голым JS — усложняется процесс сборки, нужен дополнительный шаг для компиляции скрипта. Впрочем, чаще всего сборщик все равно используется для чего-то еще, и добавить один шаг обычно очень просто.
За полтора года использования в дизайне языка встретилось несколько багов или недоработок, которые со временем оперативно пофиксили. Был только один неприятный момент, который отказались исправить: нельзя использовать Enum в качестве ключа для Dictionary.
А что думаете насчет отсутствия полной поддержки ES6 ES2015 к примеру Object.assign?
Не пробовали ставить target: "es6" и потом обрабатывать babel'ом? (Вдруг есть такой опыт)
спасибо)
Так Object.assign — это не синтаксис. Это должен поддерживать движок, а не язык. Если движок не поддерживает, есть полифиллы.
Стоп. TypeScript надмножество и поддерживает ES2015, Object.assign — возможность языка. Я в курсе насчет отсутствия полифилов в составе TypeScript. А вот отсутствие в интерфейсе объекта assign мною было замечено. (Сейчас может уже все нормально я не знаю). Но интересно сколько раз сталкивались с таким.
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es6.d.ts#L4403
Всё на месте. А отсутствие assign могло быть связано с тем, что IDE и редакторы часто используют свои lib.es6.d.ts. Например, в идеевском es6.d.ts нет assign.
Коль автора комментария пока нет, мне интересно мнение насчет "той самой боли" typings для не популярных библиотек. Бывают достаточно большие не популятные библиотеки, как быть ?
Можно конечно:
declare var lib;Может вы рецепты знаете какие или статью интересную на эту тему?
ps: пару месяцев пишу на typescript часто беспокоят всякие мелочные проблемы.
спасибо)
typing'а для библиотеки, которую вы используете, варианта действий всего три.Идеальный вариант — написать объявление самому и отправить PR с ним в репозиторий
DefinitelyTyped. И самому будет удобно работать, и сообществу поможете.Самый быстрый вариант — использовать
any и работать с библиотекой так, как бы вы писали на чистом JS — обложиться мануалами, включить автоподсказки IDE, скрестить пальцы и молиться.Компромисс — написать самому частичное объявление, которое покрывает не всю библиотеку, а только то, что вы из нее непосредственно используете, и ждать, когда какой-нибудь альтруист не столкнется с подобной проблемой и не выберет путь #1.
Отдельный вопрос — это существование трансформаций новых фич в более старые целевые платформы. Обычно новые возможности ES2015 внедряют сразу же, но только для целевой платформы ES6, потому что генерируемый код будет практически неизменным. А уже потом добавляют трансформацию, позволяющую использовать эту возможность в более старой платформе ES3/ES5. Например, объявления переменных
let добавили в 1.4, а использовать их в ES5 стало возможно только в 1.5. Генераторы включили в 1.7, а поддержку в ES5 ждем не раньше релиза 2.0. На самом деле, это тоже хорошо — фичи становятся доступными быстрее, а при желании можно использовать постобработку Babel'ом.
Нелогичное поведение.
Аргументы будут или это просто слова?
Динамическая типизация — нет IntelliSense, из-за чего мы не видим, какие ошибки будут возникать во время написания, а видим их только во время исполнения программы.
IntelliSense это как раз наоборот сильная сторона TypeScript, потому что IDE более точно может выводить подсказки, на основе анализа типов, а не показывать весь список идентификаторов, которые нашла.
Функции обратного вызова
От этого вообще выпал. Вы когда с JS познакомились, вчера?
Потом еще зачем-то заголовочные файлы из Си сюда приплели
TSD уже не актуален, нужно пользоваться typings
Это недостаток прокладки между монитором и клавиатурой, но никак не языка.
Посмотрел синтаксис — очень похож на Java.
Уже лет пять-шесть пишу на JS. Особо проблем с типизацией никогда не испытывал.
Но много кто хвалит TS, а читаю статью так и не вынес для себя что либо полезное.
Самое главное: нормальная поддержка классов.
Просто статья плохая. Посмотрите примеры из оф. документации, они нагляднее.
Условно, можно разделить профит на 2 части:
1) Синтаксис. Typescript — это синтаксис из самых свежих спецификаций es (классы, декораторы, деструктуризация) + немного своего сахара (енумы, пространства имён). Профит очевиден: меньше кода с тем же результатом.
2) Собственно система типов. Это можно считать лишь некой дополнительной проверкой кода до его запуска. Потому что штуки, вроде интерфейсов или protected-полей существуют только на этапе компиляции ts в js.
При грамотном подходе к написанию кода профитом будут:
а) Хорошие подсказки кода;
б) Самодокументация кода. Очень часто достаточно просто посмотреть на сигнатуру метода в .d.ts-файлах, чтобы понять, чего в него нужно передавать. В случае с JS во-первых, нужно найти нужный метод или документацию для него, а это порой непросто, и во-вторых, понять, какие сигнатуры в конечном итоге приемлемы, потому что очень часто, когда разбор аргументов идёт в методе, всё становится не очень очевидно.
в) Отлавливание багов, связанных с типами ещё до запуска. Банальный пример: опечатка в имени поля. Код на TS просто не скомпилируется и этот баг всплывёт сразу. В проекте на js это может всплыть в самый неожиданный момент.
в C# такого нет. Там есть синтаксис T?, раскрывающийся в Nullable, и означающий, что если Т — тип-значение, то переменная типа T? может принимать значение null. Но это не значит, что параметр этого типа можно не передавать в метод.
С Typescript развитие и эволюция кода (рефакторинг) становятся очень простыми и лёгкими — изменил сигнатуру функции, и исправляешь все использования просто глядя на диагностический вывод компилятора.
Очень часто бывает такое — пишешь какую-то сложную конструкцию, TS ругается. Пытаешься разбираться и понимаешь, что если бы он не ругнулся, то эту же ошибку ты бы уже получил в рантайме, причём в виде какого-нибудь "Cannot get property of null" или что-то такое.
Короче с TypeScript почти (до стабилизации strictNullChecks) работает уравнение Компилируется === Работает.
Основы синтаксиса TypeScript