Comments 75
В целом поддерживаю, только Babel на мой взгляд уже давно не нужен.
Webpack пока первой версии, но собираемся перейти на вторую.
Уже версия 3 давно.
TypeScript не умеет кэшировать. А babel умеет хранить готовые ES5 скрипты в папке.
Awesome-typescript-loader. Он умеет кешировать и компилить асинхронно
В целом поддерживаю, только Babel на мой взгляд уже давно не нуженА как же гибкость? У бабела хорошая база transformation плагинов и их апи пока лучше, чем в ts.
В 7м бабеле (пока еще бета) запилили поддержку синтаксиса typescript: babel-preset-typescript. Так что можно сказать, что и ts для целей сборки не нужен.
Интересно, что будет, если в flow запилят поддержку ts и плагинов для Language Service API?
возможно ошибка актуальна только для нашего набора пакетов
у нас как раз с ним (awesome-typescript-loader) вышла трабла: куча ошибок Duplicate identifier '...'. и пришлось вернутся на ts-loader
возможно ошибка актуальна только для нашего набора пакетов
Нет, github.com/s-panferov/awesome-typescript-loader/issues/135
Да, мы в курсе про вторую :) думаю, там с переходом небольшая разница.
Пробовали atl — не увидели роста производительнсти. В любом случае проверку типов мы в тот же процесс сборки не вернем — это все равно затратно.
TS -> EsNext -> Babel — лучший вариант — поддержка плагинов + конфигурируемая транспиляция
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] ManageableArea.js
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] template.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] targetingContainer.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] aurora.containers.js
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:81196
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:112675
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:113265
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:129537
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:132732
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:134699
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:147881
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:147971
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:149320
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:229550
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:253789
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:264000
unreachable code after return statement[Подробнее] portallibs-core.min.js:54:266888
unreachable code after return statement[Подробнее] portallibs-core.min.js:73:2434
window.controllers/Controllers является устаревшим. Не используйте его для определения UA. portallibs-core.min.js:54:25181
Синхронный XMLHttpRequest в основном потоке является устаревшим из-за его пагубного влияния на работу конечного пользователя. Для получения дополнительной помощи обратитесь к xhr.spec.whatwg.org portallibs-core.min.js:2:81642
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] loader_bundle.min.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] header.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] sbt.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] atc-libs.min.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] Breadcrumb.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] push-notifications.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] common.maven.min.js
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] SBO.svg
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] content
Public-Key-Pins: Сайт указал заголовок, в который не был включён подходящий pin.[Подробнее] identifier
Public-Key-Pins: Сайт указал заголовок, который не удалось успешно распарсить.[Подробнее] shared.css
Загрузка
Вы показываете что-то странное, уверены что это с сбербанк бизнес онлайн? Поверьте мне, если у нас на каких-то страницах просто белый экран — мы уже про это знаем и скорее всего это уже починено ;)
Возможно один из ваших плагинов в браузере что-то ругается.
f.pb @ VM346:2
(anonymous) @ VM346:2
check @ VM346:2
(anonymous) @ VM346:2
setTimeout (async)
start @ VM346:2
f.K @ VM346:2
start @ VM346:2
d.tf @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
setInterval (async)
a @ VM346:2
f.Vd @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM345:1
(anonymous) @ VM345:1
x.onreadystatechange @ grlb.js?ver=27hf.001.00:18
XMLHttpRequest.send (async)
cb @ grlb.js?ver=27hf.001.00:18
VM346:2 Refused to connect to 'https://127.0.0.1:80/' because it violates the following Content Security Policy directive: «connect-src 'self' bf.sberbank.ru:9443 *.group-ib.ru sbrf.livetex.ru www.google-analytics.com nlb-efsd1.sbrf.ru:444».
f.pb @ VM346:2
(anonymous) @ VM346:2
check @ VM346:2
(anonymous) @ VM346:2
setTimeout (async)
start @ VM346:2
f.K @ VM346:2
start @ VM346:2
d.tf @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
setInterval (async)
a @ VM346:2
f.Vd @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM345:1
(anonymous) @ VM345:1
x.onreadystatechange @ grlb.js?ver=27hf.001.00:18
XMLHttpRequest.send (async)
cb @ grlb.js?ver=27hf.001.00:18
VM346:2 Refused to connect to 'https://127.0.0.1:22/' because it violates the following Content Security Policy directive: «connect-src 'self' bf.sberbank.ru:9443 *.group-ib.ru sbrf.livetex.ru www.google-analytics.com nlb-efsd1.sbrf.ru:444».
f.pb @ VM346:2
(anonymous) @ VM346:2
check @ VM346:2
(anonymous) @ VM346:2
setTimeout (async)
start @ VM346:2
f.K @ VM346:2
start @ VM346:2
d.tf @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
setInterval (async)
a @ VM346:2
f.Vd @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM345:1
(anonymous) @ VM345:1
x.onreadystatechange @ grlb.js?ver=27hf.001.00:18
XMLHttpRequest.send (async)
cb @ grlb.js?ver=27hf.001.00:18
VM346:2 Refused to connect to 'https://127.0.0.1:445/' because it violates the following Content Security Policy directive: «connect-src 'self' bf.sberbank.ru:9443 *.group-ib.ru sbrf.livetex.ru www.google-analytics.com nlb-efsd1.sbrf.ru:444».
f.pb @ VM346:2
(anonymous) @ VM346:2
check @ VM346:2
(anonymous) @ VM346:2
setTimeout (async)
start @ VM346:2
f.K @ VM346:2
start @ VM346:2
d.tf @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
setInterval (async)
a @ VM346:2
f.Vd @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM346:2
(anonymous) @ VM345:1
(anonymous) @ VM345:1
x.onreadystatechange @ grlb.js?ver=27hf.001.00:18
XMLHttpRequest.send (async)
cb @ grlb.js?ver=27hf.001.00:18
VM346:2 Refused to connect to 'https://127.0.0.1:5985/' because it violates the following Content Security Policy directive: «connect-src 'self' bf.sberbank.ru:9443 *.group-ib.ru sbrf.livetex.ru www.google-analytics.com nlb-efsd1.sbrf.ru:444».
4. Поиск разработчиков с опытом на TypeScript. Это отдельные слезы нашего HRЯ вас правильно понимаю, что вы ищете именно TypeScript разработчиков, не JS (остальной набор технологий достаточно популярный). Конечно JS и TS различаются, кроме типов еще различия в классах и т.п. Но все же много общего. Да и TS в итоге транслируется в JS.
Нет, ищем js разработчиков в основном, знание ТС просто плюс. Да, набор технологий популярный, но тех, кто дальше песочницы с ним работал — не так много.
кто дальше песочницы с ним работал — не так много.
Это вы про 18 летних студентов за 50 000 рублей?
200 000 рублей и такой специалист у вас в кармане
Специалистов полно, только они не готовы работать за вшивые 120 000 рублей. (если кто-то читает эту строку и недоумевает, поздравляю, тебе сбили самооценку и ты поддался под влияние работодателя, перейди по двум ссылкам ниже что бы восстановить свой разум)
labor-union.wikia.com/wiki/Main
labor-union.wikia.com/wiki/Lifehacks
(СОВЕТУЮ ВСЕМ ПОЧИТАТЬ)
А про студентов, скорее так: 25 летние новоиспеченные jsники после курсов, пару песочниц и они уже хотят далеко не 50.
На все речи бизнесменов, рассказывающих о нехватке специалистов на российском рынке труда, нужно отвечать так: «С чего вы взяли, что в РФ есть нехватка квалифицированных кадров? Кто мешает лично вам зайти на LinkedIn и сегодня же найти на едином глобальном рынке труда русскоговорящих квалифицированных специалистов для вашего бизнеса, переманив их с других проектов? Если вам не хватает денег, то это ваши проблемы. Бизнесмену никто ничего не обещал. Ему некто не обещал, что его бизнес будет рентабельным. Вы — лузер, и ваш бизнес не имеет права на существование, потому что вы не вписались в рынок»
У меня такая же реакция была. 2 дня, ну максимум неделя понадобится программисту чтоб освоиться с ТС. Это если он ну совсем никогда не сталкивался со строго-типизированными языками. Да, придется разобраться с дженериками и смириться с тем, что ты не можешь передавать и возвращать всё что угодно куда угодно (что в итоге пойдёт только на пользу). Причем писать и понимать код программист начнёт сразу, а не через 2 дня.
Ой не скажите.
Когда в аргумент передается функция все становится тяжело
const negate = (fn: Function) => (...args: any[]) => !fn(...args)
Или когда пробуешь описать React типы.
Дженерики говорите простые?
Вот я писал
export const mapReplace = <A extends {}, U extends {}>(
array: A[],
test: (item: A) => boolean,
replacement: (item: A) => U
): (A | U)[] => {
return array.map((item: A) => {
return test(item) ? replacement(item) : item
})
}
И как вам такое? Сходу понятное?
А когда ошибки какие-то странные пишутся? Например size из лодаша (меряет размер массива, или количество элементов в объекте) иногда может не захотеть принимать любой объект. Потому что оказывается генерик
<T>size(objectOf<T>) => number
это не правильный генерик. Должно быть any вместо T
Что-то вы сами себе все усложнили.
export function mapReplace<A,U>(
array: A[],
test: (item: A) => boolean,
replacement: (item: A) => U
): (A | U)[] {
return array.map(item => test(item) ? replacement(item) : item);
}
Нормально пишется и читается.
Без
mapReplace = <A extends {}, U extends {}>
не заработает из-за конфликта с jsx (хотя я сейчас проверил — у меня заработало, магия какая-то)
https://stackoverflow.com/questions/32696475/typescript-tsx-and-generic-parameters
Ну а функцию да, можно в одну строку записать
Когда в аргумент передается функция все становится тяжело
Ну что вы хотите, писать на «фп» и чтобы у вас из ноги кровь не текла? Тут или одно или другое
И как вам такое? Сходу понятное?
Мне меньше всего понятен смысл этого:
(A | U)[]
. Зачем массив с двумя разными типами? Как с ними работать вообще? То есть вот у вас есть A[], с ним понятно как работать, а потом, после этой функции в этом массиве начинает попадаться то A, то U. А потом как? if (x instanceof U)
? Код, конечно, не самый изящный, но проблема скорее в архитектуре.Плюс еще названия. A и U — просто рандомные буквы? Вот так было бы значительно понятнее:
export function mapReplace<TCurrent, TReplace>(
array: TCurrent[],
test: (item: TCurrent) => boolean,
replacement: (item: TCurrent) => TReplace
): (TCurrent | TReplace)[] {
return array.map(item => test(item) ? replacement(item) : item);
}
Никогда не понимал, почему некоторые к именованию дженериков относятся так наплевательски. Переменная у вас ведь названа не
a
, а item
. Впечатление, что это специально, чтобы потом жаловаться, что дженерики такие непонятные.Проблемы с этим кодом две — неправильная архитектура и именование переменных. Как видите, TS в этом списке нету.
Никогда не понимал, почему некоторые к именованию дженериков относятся так наплевательски.
Каюсь, недостаток опыта. В простых дженериках все понятно было (Ну например описание мапа).
Мне меньше всего понятен смысл этого: (A | U)[]
Честно говоря уже не вспомню почему именно так нужно было, и не ошибся ли я когда это писал — но все дело в том что после реплейса возвращался новый элемент.
То есть если условиях совпадало возвращался тип А — а если модифицировался то тип U
А потом как? if (x instanceof U)
Ну типа того.
Ну, не настолько разные они по отношению к JS. Про soundness в быту поспорить можно, но для обычной разработки вперёд, как показала практика, это не даёт такого большого выигрыша, как например, более развитый туллинг и экосистема.
Собственно, на первый взгляд flow и ts про одно и то же. Если немного приглядеться, то flow всё же больше про js + types и система типов более правильная. Зато у ts сильно лучше туллинг и сильно больше библиотек уже искоробки. Потому ts всех и победил. Хотя, как по мне, flow интереснее.
так что год это ещё очень даже неплохо
а TypeScript, да, я считаю это прорыв, очень удобный и выразительный язык, особенно после js
TypeScript, это типизация следующего поколения
А можно поподробнее? Очень любопытно.
Радует, что две из четырёх описанных болячки вылечили еще в прошлом году.
Интересно, а есть ли статьи, описывающие негативный опыт внедрения TS? У меня лично от него позитивные впечатления, не понимаю почему многие его боятся.
Ребятам приходится вникать сразу в несколько вещей: например, в TS, React, Redux, в сам проект и в термины нашего банка.
Но честно говоря, у них есть на это время, пока получают доступ к системе испытательный срок закончится ;)
Да, на JS можно написать код грамотно и правильно, но он тебя не подстрахует так, как TS.
А в случае с Eclipse это невозможно вообще, только не говорите, что вам таки купили WebStorm??? )))
Необходимость актуализации версий .d.ts для внешних библиотек. Слава Богу, закончилась пора с tsd > typings. И теперь все можно качать сразу через npm > @types.
И не мешает отсутствие интернета? Nexus разве уже поддерживает @группы?
2) У нас круче — Idea.
3) У нас nexus поддерживает @subfolder и есть интернет. В двух словах: когда общий нексус СБТ не поддерживал, суперадмины нашего проекта подняли свой (новой версии) специально для нас, а позже мы вернулись в общий. Все решается, было бы желание!
не халивара ради, в мир js я пришел из java — привык к строго типизированным языкам, но учитывая весь сахар es6/es7 у меня еще не было ни разу ситуации в которой мне реально не хватало бы типизации в js
В разрезе react мне за глаза хватает типов в PropTypes
я не против ts но вопрос зачем остается открытым, хотелось бы какого то реального сравнения такой то кейс на js пишется за столько то на ts за столько, есть риск вот таких багов и экономия в будущем такая
Из очевидных:
- Code completion как у взрослых языков (новому программисту гораздо проще понять код)
- Видишь все ошибки при рефакторинге. Мы как-то переносили проект с angular 1 на angular 2, так у меня после переноса и изменения (допила-перепила) нескольких десятков файлов всё заводилось с первого раза. За годы работы со сквозной типизацией такое воспринимается как чудо
- Застрахован от очень многих ошибок рантайма. Тот же PropTypes покажет вам ошибку только когда она уже случилась (поправьте если это не так). Как говорится, со строгой типизацией сложнее по случайности отстрелить себе ногу. Например, при использовании Promise.all вы получаете массив значений в результат. И вот тут очень легко всё зафакапить, по ошибке указав не тот индекс. Тайпскрипт такого не допустит.
с промисами согласен, но пока особенно не мешало
1, 2 во многом решает webstorm
Да не возможно это так же качественно сделать как в ts.
Еще такой момент. Обычно, при устройстве на работу, в контракте есть пункт, о том, что девелопер обязуется предоставить лучшие практики разработки доступные на текущий момент. Понятно что этот пункт весьма спорный и чаще всего трудновыполнимый. Но в неиспользовании тайпскрипта по причине "нам и без него хорошо" (других причин я натурально не способен придумать) видится банальное нарушение условий контракта. Такие дела.
Знает ли webstorm что когда вы пишите, условно, foo.addEventListener("bar", e => e.|);
какие будут свойства у параметра e? А если знает, то что делать с более сложным случаем?
mobx.observe(foo, e => {
if (e.type == "update") {
e. // 1
}
if (e.type == "splice") {
e. // 2
}
});
Знает ли webstorm что в точках (1) и (2) будут разные списки доступных свойств?
mobx.observe(foo, e => {
if (e.type == "update") {
(e as update). // 1
// Либо
(<update>e). // 1
}
if (e.type == "splice") {
(e as splice). // 2
// Либо
(<splice>e). // 2
}
});
Понятно, что для JSX подходит только первый вариант, т.е. as-синтаксис.
Но зачем писать лишний код когда компилятор и так все понимает?! Кстати, не update и splice — а IArrayChange<T>
и ArraySplice<T>
, причем тип T еще нужно где-то найти...
Не разглядел mobx, т.к. с mobx не пересекался. Подумал, что в свойстве e.type хранится тип самого объекта e, т.е. update и splice — суть возможные типы объекта e. Соответственно, конструкции: (e as update). и (e as splice). помогут webstorm знать в точках (1) и (2) списки доступных свойств.
3 не совсем корректно PropTypes проверка работает только в dev
А если мы хотим один из этих пропсов передать во внешнюю функцию? Ну типа того же
mapReplace
, что повыше. Вы как будете пропТайпами типизировать? Зачем этот сломанный костыль, если есть адекватное решение, которое работает на всем коде, а не только там, где повезет?
Как минимум это спасает от опечаток — в js (с бабел и вебпак) код скопмилится и сломается в рантайме — с typescript-ом просто не скомпилиться
Иногда даже не обновляешь версии, а в пн бах — и уже не собирается, потому что где-то косвенная зависимость нестрого: ^0.1.1 версию тянет и все, как было недавно с babel-transform-generator (если не изменяет память). Npm-Shrinkwrap нас спасет!
Жаль, что про Flow вы не знали, впрочем сейчас ReasonML набирает обороты (это то, что может стать стандартом в будущем).
TypeScript хорош с Angular и только там ему место
Идеология TypeScript в корне противоречит функциональному подходу принятому в React и использовать их в такой связке неверно.
Псевдо-функциональный подход принят исключительно в Редаксе. Реакт — вполне себе мультипарадигменный и даже больше ООПшный, чем ФПшный. Мы его использует с TS и MobX, и не знаем бед — у нас ВСЕ статически-типизированно, никакого сомнительного кода.
> Жаль, что про Flow вы не знали
Видимо, вы про Flow тоже не в курсе, иначе бы знали, что он от Typescript, в плане поддержки функциональных подходов, не отличается.
> впрочем сейчас ReasonML набирает обороты (это то, что может стать стандартом в будущем)
Не станет, т.к. фейсбук _очень_ плохо в типах разбираются, что flow показал. Тут надежды как раз на мелкомягких, они себя уже очень хорошо в этой области зарекомендовали — как в чисто теоретических рокет-саенс разработках, так и в доведении их до практики. Фактически, они последнее десятилетие тут локомотив прогресса и законодатели мод.
Видимо, вы про Flow тоже не в курсе, иначе бы знали, что он от Typescript, в плане поддержки функциональных подходов, не отличается.
Flow это не столько язык, сколько Type cheker, для чего и создавался, поэтому неправильно говорить, что он не отличим от TypeScript. Это просто разные вещи. TypeScript — же это мощной язык, агрессивно насаждающий ООП, там где это не нужно.
Не станет, т.к. фейсбук _очень_ плохо в типах разбираются, что flow показал
Наивно так утверждать, хотя согласен, что Microsoft хорош в развитии языков.
Моя критика относится к людям которые пытаются скрещивать ужа с ежом (TypeScript и React). Не думаю, что Microsoft ставила такую задачу, думаю Microsoft как раз понимают, что делают, в отличие от некоторых фронтендеров
Flow — это вполне отдельный язык, точно так же, как TypeScript, прошу, не повторяйте буллшит, которым кормят маркетологи фейсбука.
> Моя критика относится к людям которые пытаются скрещивать ужа с ежом (TypeScript и React). Не думаю, что Microsoft ставила такую задачу
Вы не поверите — но ставила. Задача, которая ставилась перед системой типов TS — максимально простая и безболезненная типизация существующих JS-идиом (в том числе и тех, что используются в реакте или редаксе или еще где — оно ведь на JS), пусть и в ущерб soundness (сам факт наличия TSX, кстати, говорит о том, что и отдельная задача совместимости с реактом существовала в явном виде).
Система типов Flow, с другой стороны, дизайнилась в первую очередь с расчетом на soundness, пусть и ценой дополнительных трудностей в выражении типов для существующего кода.
Собственно, это и есть единственное важное отличие Flow от TS, все остальное — просто следствия этой разницы на уровне идеологии.
Flow — это вполне отдельный язык, точно так же, как TypeScript, прошу, не повторяйте буллшит, которым кормят маркетологи фейсбука
здесь не я повторяю буллшит, а вы пытаетесь додумывать за фейсбук
сам факт наличия TSX, кстати, говорит о том, что и отдельная задача совместимости с реактом существовала в явном виде
JSX это не весь React, и создание TSX ни о чём не говорит
en.wikipedia.org/wiki/Soundness
могу посоветовать интересный доклад Ильи Климова с конференции HolyJS 2017 Piter, где он сравнивает TypeScript и Flow
Вот он https://youtu.be/etKOc80-cw0
Теперь можно проверить типы в чистом JS — достаточно добавить файлы “.js” в проект и allowJs флаг.
Пожалуйста, покажите на примере, как это работает?
Чем хорош (и чем плох) Typescript: опыт UI-разработчиков