Comments 40
Мы перевели сервер на NodeJS на тайпскрипт + файберы и невероятно счастливы. Тесты стали писаться проще, кода работает стабильнее, качество кода повысилось. Что бы выкатить какую-нибудь лажу типа
there_is_typo_in_this_fction() уже и забыли. Немного разражает отсуствие байндингов для свежих версий библиотек, и время компиляции.
тень необъектного JS
Перестал читать на этой строчке.
Строгая / статическая типизация основная фича, остальное и в JS нормально реализуется.
Так вот кто знаком с Cи конструкция reference хоть и находится формально под комментарием является аналогом include. И самое главное, код перестанет работать если вы не в том порядке подключите скрипты.
Начиная с 0.9.1 (на дворе уже давно 1+) конструкция reference нужна только для ссылок на файлы вне проекта.
пофайлово видеть код на JS все же удобнее
Так генерируем code map и браузер в отладчике автоматом подтянет все исходники на typescript.
использую проект ASP.NET — он ничего не знает о TS, кроме того, что я ему указываю как генерировать в post build
У вас какая студия? У меня в 2013 такой же проект (мигрированный с 2012), и там прекрасно все работает без референсов.
Собственно, TypeScript Tooling в студии не зависит от типа проекта.
Скажите, а вы держите TS-файлы под VCS? Если да, то где и как вы генерите JS-файлы?
С присвоением ссылки на функцию, т.е. с созданием калбэка тоже есть непонятки. Но они скорее дисциплириуют, но могут адептам JS показаться не естетвенными. Те кто привык к JS частенько, думаю, занимаются передачей ссылок на функцию, даже не думая о безопасности этого. К примеру, в .NET намеренно запретили прямую работу с ссылками, т.к. это приводит часто к багам. Но при ООП это часто не нужно, вместо этого передаются ссылки на объекты, и затем получающий объект использует public часть класса, используя нужные ему члены класса. Еще лучше если класс реализует интерфейс, и передается ссылка на интерфейсы. Увы, этого в JS нет, и поэтому часто пользуются не безопасной передачей ссылок на функцию.
What?
(1) В TS нет никаких «непоняток» с передачей делегатов, эта передача работает точно так же, как в JS.
(2) В .net вообще и в C# в частности делегаты передаются так же (с точки зрения программиста), как и в JS, разница в поведении
this.(3) Что небезопасного в том, как передаются делегаты в JS?
(4) Передача ссылок (точнее, указателей) и передача делегатов — две совершенно разные вещи, непонятно, зачем вы их впихнули в один абзац.
Как человек, написавший на TS несколько проектов «клиент на Angular + сервер на Node» и в последствии перевевший на него всю свою команду, я попросил бы вас статью убрать в черновики (слишком много фактических ошибок) и прежде чем писать на TS и о TS прочесть JavaScript: The Definitive Guide, 6th Edition by Flanagan (JavaScript. Подробное руководство, 6-е издание).
«В TypeScrip просто не объявляйте внешних переменных с помощью declare var.» В данном случае, declare ничего не объявляет, а указывает компилятору, что во время выполнения будет такая переменная с таким типом, чтоб он не ругался на её использование. За счет этого работают файлы деклараций для сторонних библиотек.
«TypeScript поддерживает настоящие наследование, чем оно отличается от JS наследования поговорим позже.» Ничем. Вы вообще смотрели внутрь файлов, которые вам сгенерил TS? Посмотрите вот тут хотя-бы дефолтный пример www.typescriptlang.org/Playground. Классы TS это удобный сахар над классами JS с их прототипным наследованием. Если быть более точным, это даже не сахар, а синтаксис ECMAScript 6, который сейчас потихоньку внедряется в браузеры, но в TS просто обратно компилится в ECMAScript 3/5.
«Получаем такой бонус как полноценную поддержку конструкторов в классах. Без них надо изобретать т.н. фабрики с методами init()» — см. пункт выше про классы.
«Мы получаем строгую типизацию» нет, мы получаем только её проверку на этапе компиляции.
«Скажу лишь одно, с помощью интерфейсов реализуется множественное наследование, и легко можно сложный интерфейс public часть всего класса, поделить на ряд сваязанных интерфейсов, после чего передавать ссылки не на весь класс, а ссылки на выделенный интерфейс.» Вы тоже самое получите просто помечая члены класса как public \ private. Обратите, кстати, внимание, что в скомпиленном JS они всегда public. То-есть, имея private свойство вы все равно можете сделать myVar['privateVarName'] в TS, а в JS и этого не надо.
В общем, не пишите, пожалуйста, о технологиях, в которых не разбираетесь.
«В TypeScrip просто не объявляйте внешних переменных с помощью declare var.» В данном случае, declare ничего не объявляет, а указывает компилятору, что во время выполнения будет такая переменная с таким типом, чтоб он не ругался на её использование. За счет этого работают файлы деклараций для сторонних библиотек.
«TypeScript поддерживает настоящие наследование, чем оно отличается от JS наследования поговорим позже.» Ничем. Вы вообще смотрели внутрь файлов, которые вам сгенерил TS? Посмотрите вот тут хотя-бы дефолтный пример www.typescriptlang.org/Playground. Классы TS это удобный сахар над классами JS с их прототипным наследованием. Если быть более точным, это даже не сахар, а синтаксис ECMAScript 6, который сейчас потихоньку внедряется в браузеры, но в TS просто обратно компилится в ECMAScript 3/5.
«Получаем такой бонус как полноценную поддержку конструкторов в классах. Без них надо изобретать т.н. фабрики с методами init()» — см. пункт выше про классы.
«Мы получаем строгую типизацию» нет, мы получаем только её проверку на этапе компиляции.
«Скажу лишь одно, с помощью интерфейсов реализуется множественное наследование, и легко можно сложный интерфейс public часть всего класса, поделить на ряд сваязанных интерфейсов, после чего передавать ссылки не на весь класс, а ссылки на выделенный интерфейс.» Вы тоже самое получите просто помечая члены класса как public \ private. Обратите, кстати, внимание, что в скомпиленном JS они всегда public. То-есть, имея private свойство вы все равно можете сделать myVar['privateVarName'] в TS, а в JS и этого не надо.
В общем, не пишите, пожалуйста, о технологиях, в которых не разбираетесь.
А вы не пишете свои глупости и на этом разойдемся.
Я так понимаю, что по существу ответить нечего?
Ну, я рад, похоже уже и без меня разобрались… надо еще что-то ответить или разберетесь со школьником сами?
Ну вообще-то в комментарии KIVan было намного больше одного пункта, а вы не смогли аргументированно ответить ни на один. Так что пока что выходит так, что вам по существу сказать как не было ничего, так и нет.
Ну и не стоит называть школьником человека, который сказал что-то, с чем вы не согласны.
Ну и не стоит называть школьником человека, который сказал что-то, с чем вы не согласны.
Скромнее надо быть. Он пишет всё по делу, а вы только только ознакомились с TS и едва знакомы с JS и уже пытаетесь тыкать кого то носом.
Да, нет там ничего по делу :) Объяснять очевидности мне тут не интересно. Но если вам реально интересно, пишите в личку — попробуем разобраться. А так это очередной холивар, мне он не интересен.
Опыт общения с вами «в личке» показывает, что вы там ничем не отличаетесь от здесь. Так что особого смысла нет.
Мы уже подробно разбирались с вами по поводу того самого кода с глобальным xmlhttp. На должность стажёра я бы вас взял — потенциал у вас явно есть, а опыта почти нет (зато вместо опыта есть много заносчивости). То, что вы решили разобраться с TS это похвально, а вот то, что вы пытаетесь преподнести своё трёхдневное знакомство с TS как глубокое понимание предмета — это не похвально. Кроме того, судя по ошибкам в статье, вы также мало знакомы с C# (с JS вы точно мало знакомы — мы уже разбирали ваш код в личке).
Ну, и кто это здесь заносчив :) заканчивайте говорить в стиле Ad hominem — это Вас не красит.
" трёхдневное знакомство с TS как глубокое понимание предмета"
Однако, мне этого было достаточно, чтобы перевести мое проектик. Все остальное придумыли Вы сами, я же поделился теми трудностями с которыми столкнулся. Ну, и в скобках заметим, Вы читаете мою статью — с удовольствиям почитал бы статьи здешних умников, однако таких статей нет.
«судя по ошибкам в статье, вы также мало знакомы с C#»
смешно :) Может стоит вначале назвать в чем ошибка, а потом уже что-то утверждать?
P.S.
Приезжайте к нам, может и я устрою вас на работу :)
" трёхдневное знакомство с TS как глубокое понимание предмета"
Однако, мне этого было достаточно, чтобы перевести мое проектик. Все остальное придумыли Вы сами, я же поделился теми трудностями с которыми столкнулся. Ну, и в скобках заметим, Вы читаете мою статью — с удовольствиям почитал бы статьи здешних умников, однако таких статей нет.
«судя по ошибкам в статье, вы также мало знакомы с C#»
смешно :) Может стоит вначале назвать в чем ошибка, а потом уже что-то утверждать?
P.S.
Приезжайте к нам, может и я устрою вас на работу :)
Однако, мне этого было достаточно, чтобы перевести мое проектик.
Чтобы «перевести проектик» на TS достаточно пары часов — потому что TS работает с JS side-by-side (а интеграцию вы до сих пор не доделали, да и на вопрос с VCS не ответили, что тоже показательно). А если говорить о том, что вы весь JS-код переписали на TS — то тоже особо хвастаться нечем, потому что с одной стороны непонятен объем, а с другой — насколько реально вы пользуетесь возможностями TS.
any => any писать просто…Например, явно видно, что вы еще плаваете в том, как именно TS захватывает и трактует контекст (иначе бы вы не писали, что «дело в том, что теперь на уровне класса вы больше не можете объявлять локальные переменные с помощью var.»).
На ошибку указал lair:
(2) В .net вообще и в C# в частности делегаты передаются так же (с точки зрения программиста), как и в JS, разница в поведении this.
(2) В .net вообще и в C# в частности делегаты передаются так же (с точки зрения программиста), как и в JS, разница в поведении this.
На должность стажёра я бы вас взял
Не стоит. С таким уровнем можно брать 20-ти летних. А тут случай тяжелый, мужику за 30 уже, в голове каша, фундаментального понимания программирования нет, желания учиться, судя по всему, тоже.
Написал 20-летний стажер :)
Понятно, даже посмотреть в юзеринфо теперь лень (ну или считать не умеете). Мелко.
Не стоит заострять внимание на возрасте. 20-ти летний стажёр который кодит лет пять (а есть такие, которые начинают этак лет в 7) будет во всех отношениях лучше большого и взрослого дядьки который только только начал что то там кодить. Вон, например, Магнус Карлсен обставлял всех в шахматы уже в 17 лет.
Хвастаться надо не возрастом, а рейтингом AGA или ФИДЕ.
Хвастаться виртуальными бонусами еще смешнее :) Может лучше все же годами опыта?
Годы опыта сами по себе не значат ни-че-го.
(удивительно, что вы свой единственный, если не ошибаюсь, разрешенный комментарий в день тратите на petty bickering, а не на ответ по существу. Ну или не очень удивительно.)
(удивительно, что вы свой единственный, если не ошибаюсь, разрешенный комментарий в день тратите на petty bickering, а не на ответ по существу. Ну или не очень удивительно.)
Уж лучше тогда зарплатой — она всё таки более материальна чем годы эфемерного опыта.
«легко можно сложный интерфейс public часть всего класса, поделить на ряд сваязанных интерфейсов, после чего передавать ссылки не на весь класс, а ссылки на выделенный интерфейс.» Вы тоже самое получите просто помечая члены класса как public \ private.
Справедливости ради — не то же самое. Интерфейсы позволяют формировать и навязывать необходимый потребителю контракт объекта, при этом потребителю не важно, какого именно типа в реальности объект — достаточно знать, что он реализует конкретный интерфейс. В JS это исторически делалось с помощью duck typing, интерфейсы же делают это более формальным образом.
«Мы получаем строгую типизацию» нет, мы получаем только её проверку на этапе компиляции.
В общем-то очевидно что речь идет о type safe и строгой типизации на этапе разработки (что в принципе очень большое подспорье если кода много и пишут его разные люди), TP ведь не встраивается в браузер как интерпретатор / VM, а просто транслирует потом код в JS.
class Menu extends RequestData
Простите, это у вас действительно такая, кхм, архитектура? Или просто неудачный пример?
Если бы вы поковыряли TS и JS хотя бы пару лет, то написали бы статью совсем по другому. Ну и немного скромности определённо улучшит стиль изложения и избавит от некоторых ошибок.
declare var Window: new (a: any) => any; — как-то не очень понравилось такое написание, имхо весь смысл TypeScripta теряется…
Sign up to leave a comment.
JavaScript to TypeScript — трудности перевода