а вот наличие уверенности во входных-выходных данных - это круто и важно

любопытно что мне не удалось каких-либо вразумительных тестов показывающих что ts в продакшене действительно работает быстрее

за исключеним совсем уж вакумных не имеющих ничего общего с реальностью

а с чего бы ts работать быстрее

плюс это сильно зависит от того, во что мы транспилируем ts

а вот наличие уверенности во входных-выходных данных - это круто и важно

а тесты не должны покрывать такие кейсы? я вот все таки видимо не вижу пока причин натягивать сову на глобус =)

для того чтобы увидеть перфоманс неизменяемых типов данных - в проекте нужны функции, которые будут запускаться тысячи раз

а тесты не должны покрывать такие кейсы? я вот все таки видимо не вижу пока причин натягивать сову на глобус =)

тесты - это вообще не про это

тесты проверяют поведение системы

Мне просто нравится строгая типизация

для того чтобы увидеть перфоманс неизменяемых типов данных - в проекте нужны функции, которые будут запускаться тысячи раз

похоже на правду

типы - декларируют это поведение

>а с чего бы ts работать быстрее

во-первых потому-что движки оптимизируют код не с первого вызова, а во-вторых, потому-что разница производительности между a='' и a=null не такая значительная, чтобы заметить ее на маленькой выборке

на любых больших проектах строгая типизация - однозначное добро и почти необходимость

потому что позволяет быть уверенным в правильности использования интерфейсов и в правильности их употребления

про однозначность - я бы поспорил

при всей популярности реюзабельного кода - такие ситуации возникают редко внутри самого проекта

ок, разверну мысль "однозначное добро если вводить ее с самого начала"

в основном все пишется под одноразовое использование

а значит при изменении структуры - не сложно отследить что еще нужно поменять

ну не знаю. Потом это одноразовое саппортить и расширять

а вот время на написание типов тратится

сильно меньше чем на тот кусок тестов, который не нужен при наличии типов

ну не знаю. Потом это одноразовое саппортить и расширять

расширяй, кто же тебе мешать будет? код все равно везде править придется, Flow только подскажет где эти изменения нужно сделать

а есть тут те кто ТС использует на работе?

А про повторное использование - кардинально не соглашусь

нагавногодить и забыть

Вон мы работали в thomas cook - одна и та же логика переиспользуется в куче разных мест, со сложной композицией - на главном сайте, на саттелитах, в виджетах. при этом одна и та же форма поиска на самом деле может содержать разные поля в зависимости от региональной специфики и т.д.

сильно меньше чем на тот кусок тестов, который не нужен при наличии типов

а вот тут я готов поспорить, если мы предполагаем, что кто-то может упустить правки кода, при изменении структуры типа - одного использования типов не достаточно. потому-что разраб поправит код, забыв что-то пофиксить, и просто изменит тип в аргументах функции, к примеру

и код уже не рабочий

хотя типы будут совпадать

И да, в этом и суть что система типизации вовремя напомнит, что вот здесь я передаю в поиск объект, где нужно поле ip, а у меня на основании текущих типов оно может быть undefined

а вот тут я готов поспорить, если мы предполагаем, что кто-то может упустить правки кода, при изменении структуры типа - одного использования типов не достаточно. потому-что разраб поправит код, забыв что-то пофиксить, и просто изменит тип в аргументах функции, к примеру

я сейчас говорю об интеграционных, а не о юнит тестах

более того если он изменил тип в аргументах функции - то с большой вероятностью где-то этот тип не устроит кого-то по самому коду функции

так тип же можно изменить автоматически по всему коду

просто Replace'ом

и вся эта типизация нужна была только для …

не ясно зачем

как по мне, то если разрабы в компании добросовестные - то изменяя структуру объекта в одном месте, они проверят использование этого объекта и подстроят его везде, а если не добросовестные, то типизации аж ни чуть не спасет ситуацию

И да, в этом и суть что система типизации вовремя напомнит, что вот здесь я передаю в поиск объект, где нужно поле ip, а у меня на основании текущих типов оно может быть undefined

короче я для этих целей использую докстринги в функциях, но в моем случаее оно не проверит так ли это, а в случае с flow проверит

понятно

наверное, единственный плюс который я вижу в типизации, это возможность найти описание структуры объекта

как по мне, то если разрабы в компании добросовестные - то изменяя структуру объекта в одном месте, они проверят использование этого объекта и подстроят его везде, а если не добросовестные, то типизации аж ни чуть не спасет ситуацию

иногда эти использования слишком неявные. Особенно когда объект идет сквозь всю систему не целиком. а дробится на части и т.д.

опять же сужу по своему опыту "добросовестной" разработки на проекте с командой фронта в 80 человек

flow может отследить такое?

конечно

я бы не стал доверять такую задачу тулзе

в этом и основная (как я вижу) задача системы типов: грамотный ВЫВОД типов

т.е. математически обоснованные суждения о том каких возможных типов может быть вот эта переменная в отсутствии явной декларации типов

и в этой части typescript все еще отстой, хотя справедливости ради потихоньку развивается

но некоторые детские ошибки с промисами и типами напрочь отбивают желание писать на нем в frp стиле

https://goo.gl/ewsd6h vs https://goo.gl/eI7oqY . Here typescript lost type of x (Foo). Sample is synthetic but it occurs quite often with FRP

вот сегодня ныл на эту тему про TS

Кстати если курс дорогой - берете пишете автору что вы бедный студент

80% авторов делают скидку процентов в 50

(с конференциями тоже работает)

я так когда был студентом пару курсов покупал

а тесты не должны покрывать такие кейсы? я вот все таки видимо не вижу пока причин натягивать сову на глобус =)

Тогда тестов будет сильно больше самого кода, у меня сейчас такая же проблема в либе: 200 строк кода, 200 строк каких-то тестов

Так у тебя с flow так-то тоже строк бдет не мало + еще и тесты

любопытно что мне не удалось каких-либо вразумительных тестов показывающих что ts в продакшене действительно работает быстрее

А посему он должен быть быстрее то? Насколько я понял, компилятор ts транслирует ts в js Вот если б в webassembly то прирост был бы

Так у тебя с flow так-то тоже строк бдет не мало + еще и тесты

Как я понимаю, flow это рантайм

Вот кстати

тогда он будет работать медленее?

ERROR: S client not available

Сколько строк дополнительно надо писать для flow?

Ну так, навскидку

тогда он будет работать медленее?

Ну вообще да

Даже в исходниках vue, кажется где-то около vdom ts/flow не используется

Типо нужна максимальная производительность, там прям так и написано

Кстати если курс дорогой - берете пишете автору что вы бедный студент

i try, надеюсь ответит

vue/patch.js at dev · vuejs/vue https://github.com/vuejs/vue/blob/dev/src/core/vdom/patch.js

ну в общем не такая уж это и бесполезная затея, насчет статической типизации в js

иногда и в питоне хочется, но крайне редко

иногда и в питоне хочется, но крайне редко

А всякие там cpython?

в критичных местах можно проверить самому

А всякие там cpython?

сpython это и есть python =) ты про cython, наверное

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

сpython это и есть python =) ты про cython, наверное

Ога

Попутал, со всеми бывает)

Народ кто дружил vue и google maps? В примерах какая-то дичь в основном типа window.Vue = Vue и т.д.

Народ кто дружил vue и google maps? В примерах какая-то дичь в основном типа window.Vue = Vue и т.д.

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

Мне точку для контакта вывести онли

есть vue-google-maps, но он оверфункционален

Мне точку для контакта вывести онли

а вью тут зачем?

Я видел

если тебе внутри компонента надо отобразить карту, то просто сделай в mounted этого компонета инит карты и добавление маркера

Внутри vue

Мне точку для контакта вывести онли

может тогда вообще статик мап сделать?

Пробую но вот ругается на инит

что именно ругает

Не может найти объект

Maps

залей на jsfiddle и тебе помогут гораздо быстрее

Maps

ну а ты импортишь либу до импорта твоего аппа или после? =)

семен семеныч