Comments 44
Компонентов сколько мигрировали? Какие codemod может посоветуете?
Какие инструменты использовали для унификации type-guards при работе с thunk/saga?
Никому и никогда не советую внедрять Flow в свой проект )
https://flow.org/try/#0PTAEHsFsHNQRgFAG04BpQDsCuAbH6BmAXQDoAzASxwBcBTAJwAoNQBeAPlGoE8AHW8GUxtWrUAHJskAEYNxAShKQAhr2ZtOLAFTwADPISGQEGKABMCAMbgMAZ2qghY5gC5Q9+hQywAPpiwyDPIaoADeCACQ1nYOFLYAcgGy9GxcfAJCLKJikklyCKCFoPS01Fj0LHGJgSkA-MI6cLqgbhgIAL6GQA
К сожалению, TypeScript с этим не лучше справляется.
Верно, я как раз посмотрел на сингнатуру filter https://github.com/microsoft/TypeScript/blob/master/src/lib/es5.d.ts#L1141 и увидел, что filter его таки использует. Так что, в принципе, будет работать даже такой вариант:
[1, null, 3].filter((n): n is number => typeof n === 'number').map(n => n * 10);
С тайпгуардами отдельная проблема: сами-то они не тайпчекаются. Можно и так написать, и компилятор ничего не скажет:
function isNumber(x : unknown) : x is number {
return typeof x === "string";
}
Можно переопределять парсер для разных типов файлов, см. пример
> Проблема: Импорт компонентов/функций из разных типов файлов.
Разве ж это проблема, если она решается парой строчек в конфигах?
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
JSON 29 20 0 617229
TypeScript 3482 20179 148729 490138
JavaScript 35 1805 1438 18802
HTML 17 230 7 1757
C 1 95 28 580
CSS 7 50 45 476
C/C++ Header 1 9 3 27
Bourne Shell 1 1 0 6
SVG 1 0 0 1
-------------------------------------------------------------------------------
SUM: 3574 22389 150250 1129016
-------------------------------------------------------------------------------Тут огромный JSON это просто выгрузка из БД для независимости тестов от БД.
Из 500K Тайпскрипт кода 200K это новое двигло и конвертер кода, 300К сконвертированный код приложения которое в оригинале написано на ActionScript 3.0
И как же я рад что в 2016 году выбрал typescript. Ключевой момент для меня — открытость разработки, возможность обсуждать фичи, пул реквест который правит багу был смержен в мастер за 4 (!) часа. Закрытые процессы FB и близко рядом не стоят. Ну и вообще по общему впечатлению не жалею о выборе ни разу. Начал присматриваться к ts с версии 1.3 и хочу сказать что развитие впечатляющее.
Два или три года на Flow, потом на чистом JS, теперь больше года на TS.
Проблемы плюс-минус одни и те же, кроме поддержки в IDE.
Код только для TS (тайпгварды или явные as/any/object) и тут приходится писать примерно в том же обёме, причём некоторые вроде очевидные проверки TS не ловит, например, при типе возвращаемого значения T|T[]|null|undefined (привет, react-select) простой проверки !Array.isArray недостаточно чтобы исключить T[] из обработки. Кажется, выражения условия isT(val) || val === null || val === undefined тоже не понимает как исключение T[].
Некоторые типы писать очень сложно с одной стороны, а с другой типобезопасность в моём понимании из-за структурной типизации не очень: ошибки, когда при копипасте забыл заменить user на Organization, не ловит, если нужны только id и name
В целом пока типы ведут себя так как ожидаешь, то профит от использования TS/Flow есть — ловит глупые ошибки. Но непонятно компенсирует ли это ситуации, когда полдня или больше тратишь на попытки обойти сообщения о ошибках типов системой типов без явного приведения или громоздких честных тайпгвардов, а в конце-концов просто делаешь какой-то хак.
с другой типобезопасность в моём понимании из-за структурной типизации не очень: ошибки, когда при копипасте забыл заменить user на Organization, не ловит, если нужны только id и nameЕсли использовать Flow с классами (вместо простых объектов), то такой проблемы не будет — Flow применяет к классам номинативную типизацию (или номинальную, не уверен, как лучше).
например, при типе возвращаемого значения T|T[]|null|undefined (привет, react-select) простой проверки !Array.isArray недостаточно чтобы исключить T[] из обработки
Странно, а у меня работает.
Но на самом деле, это баг и работать оно не должно: ведь не любой T[] пройдет проверку isArray...
Я попытался упростить для примера, видимо где-то что-то упустил.
Разобрался что упустил, вам должно понравиться: не просто T[] а readonly T[]: не работает
Вот этот баг похоже https://github.com/microsoft/TypeScript/issues/17002 с патчем https://github.com/microsoft/TypeScript/pull/28916
Допустим, в TS-файле импортируется и используется компонент, написанный на JS+Flow, откуда TS узнаёт сигнатуру этого компонента?
двойная проверка на nullЗвучит странно и непонятно, хотелось бы больше деталей. У меня не получилось воспроизвести эту проблему, всё работает и без лишнего if'а.
Во Flow сначала привлекли зависимые типы и большая строгость, но все преимущества обесцениваются сырой реализацией.
Сейчас действительно не смог их найти в документации к Flow, но, если я правильно помню, одно время говорили об их поддержке.
"JavaScript – это один из языков с динамической типизацией. Такие языки удобны для быстрой разработки приложений"
Каким образом они более удобны для быстрой разработки?
Не первый раз слышу подобную фразу но всегда без объяснения этого удобства.
Среди мэйнстрим языков не могу вспомнить языков динамической типизацией с компилятором, выводящим типы. Пример можно? Чтоб именно компилятор по умолчанию и именно типы выводил, а не присвавиал тип динамического выражения?
Либо что вы подразумеваете под «выводил»? Я подразумевал как раз присваивание значения любого типа, без необходимости объявлять его заранее.
Я под выводом типов подразумеваю именно вычисление типа выражения до вычисления его значения без необходимости объявлять его заранее. Тому же jit может быть очень полезно знать, что Math.sin(x) всегда возвращает number, например.
Это называется не "вывод типов", а "статическая типизация". Собственно, это и есть её определение — когда тип выражения можно узнать не вычисляя его значение.
Довольно очевидно, что среди языков с динамической типизацией вы языка со статической типизацией не нашли :-)
Я знаю чем отличаются динамическая от статической. :) Я комментировал фразу "Они [языки с динамической типизацией] удобны тем, что типы выводит компилятор и снимает с вас эту работу. Вот такого я не припоминаю, даже если считать, что "компилятор" — синоним "транслятор". Вывод типов для меня признак статического языка, не необходмый, но достаточный на практике. Статический язык без вывода типов — не экзотика. Динамический с ним — особо и представить не могу, если небрать всякие jit как деталь реализации
Можно менять типы данных в рантайме, а не пользоваться исключительно заданными или выведенными в компайлтайме. Возможность менять что-то удобнее невозможности, не так ли?
Плюс очень-очень часто путают динамическую типизацию с нестрогой, с, например, неявным приведением к булевой истине значений отличных от ноля, null, пустой строки… Если что, Си — язык со статической, но не строгой типизацией. Некоторые относят его вообще к языкам без типизации как ассемблер.
Опыт перевода большого проекта с Flow на TypeScript