VS
Через enum красивее, глаз выцепляет сразу
Как ваше решение Enum на js будет юзаться, так и не понял. Можете обьяснить, или ссылочку кинуть?
Size: a a a
2021 March 03
VS
Через enum красивее, глаз выцепляет сразу
Удобнее юзать через юнион. Так как ide подсветит возможные значения параметра метода в и будет автокомплит.
TS
Vlad Sobenko
Как ваше решение Enum на js будет юзаться, так и не понял. Можете обьяснить, или ссылочку кинуть?
TS
Vlad Sobenko
Удобнее юзать через юнион. Так как ide подсветит возможные значения параметра метода в и будет автокомплит.
это вы балуваные
DH
та да - лень по гиту пошукать
A
Vlad Sobenko
Удобнее юзать через юнион. Так как ide подсветит возможные значения параметра метода в и будет автокомплит.
Точно как я и говорил - тайпскрипт то утилита для автокомплита :)
DH
не серьезный подход
VS
Как это будет юзаться клиентами не понятно с тех тестов. Например метод зависит он вашего enum. Нужно будет описать его в jsdoc?
Кто проверит, что передали именно Enum, а не что то левое?
Кто проверит, что передали именно Enum, а не что то левое?
VS
Точно как я и говорил - тайпскрипт то утилита для автокомплита :)
Нет, не только. Но одна из главных.
A
Vlad Sobenko
Нет, не только. Но одна из главных.
Да, если добавить тайпдок, то можно красивую доку по апи генерить. На этом точно все фичи заканчиваются.
VS
Я вообще привык разрабатывать через контракты.
Как писал на том же пхп. Пишу модуль. Вижу, что нужна абстракция, для того же репозитория, или какие то вычисления. - Я сразу создают интерфейс для этой репы, для вычислений. Только потом пишу реализации. Часто одна имплементация для прода. 1 для тестов.
Как писал на том же пхп. Пишу модуль. Вижу, что нужна абстракция, для того же репозитория, или какие то вычисления. - Я сразу создают интерфейс для этой репы, для вычислений. Только потом пишу реализации. Часто одна имплементация для прода. 1 для тестов.
VS
Да, если добавить тайпдок, то можно красивую доку по апи генерить. На этом точно все фичи заканчиваются.
Стат анализ. Описание контрактов. Описание сложных типов. Мало?
VS
Но хз, стоит ли этот спор продолжать. Уже не раз он происходил. Все остаются при своих всегда)
A
Vlad Sobenko
Стат анализ. Описание контрактов. Описание сложных типов. Мало?
1. еслинт
2. та же документация
3. описали сложный тип, а потом делаем JSON.parse(someString) as MyAwsomeComplexType, где someString = ""
2. та же документация
3. описали сложный тип, а потом делаем JSON.parse(someString) as MyAwsomeComplexType, где someString = ""
VS
1. еслинт
2. та же документация
3. описали сложный тип, а потом делаем JSON.parse(someString) as MyAwsomeComplexType, где someString = ""
2. та же документация
3. описали сложный тип, а потом делаем JSON.parse(someString) as MyAwsomeComplexType, где someString = ""
1. Еслинт для других целей. Он не дает всех возможностей для этого.
2. Доку кто то проверяет? Тс сразу же будет ругаться при следующем запуске, что контракт не соблюдается.
3. Все адекватные делают рантайм проверки типов для этого.
2. Доку кто то проверяет? Тс сразу же будет ругаться при следующем запуске, что контракт не соблюдается.
3. Все адекватные делают рантайм проверки типов для этого.
TS
Vlad Sobenko
Я вообще привык разрабатывать через контракты.
Как писал на том же пхп. Пишу модуль. Вижу, что нужна абстракция, для того же репозитория, или какие то вычисления. - Я сразу создают интерфейс для этой репы, для вычислений. Только потом пишу реализации. Часто одна имплементация для прода. 1 для тестов.
Как писал на том же пхп. Пишу модуль. Вижу, что нужна абстракция, для того же репозитория, или какие то вычисления. - Я сразу создают интерфейс для этой репы, для вычислений. Только потом пишу реализации. Часто одна имплементация для прода. 1 для тестов.
Слодный контракт, например async iterable типами описать мало, у него есть сложное поведение и типы могут совпадать, а поведение другое
A
Vlad Sobenko
1. Еслинт для других целей. Он не дает всех возможностей для этого.
2. Доку кто то проверяет? Тс сразу же будет ругаться при следующем запуске, что контракт не соблюдается.
3. Все адекватные делают рантайм проверки типов для этого.
2. Доку кто то проверяет? Тс сразу же будет ругаться при следующем запуске, что контракт не соблюдается.
3. Все адекватные делают рантайм проверки типов для этого.
1. Для тех же самых.
2. Доку проверяет разработчик. Соблюдение контракта - тесты. Надеятся на тайпскрипт в этом плане это как полагаться на калитку в чистом поле без забора
3. Значит в этом пункте тайпскрипт бесполезен. Вычеркиваем.
2. Доку проверяет разработчик. Соблюдение контракта - тесты. Надеятся на тайпскрипт в этом плане это как полагаться на калитку в чистом поле без забора
3. Значит в этом пункте тайпскрипт бесполезен. Вычеркиваем.
UT
Один вопрос, а зачем тогда на Nodejs писать если так больно без типов?
VS
1. Для тех же самых.
2. Доку проверяет разработчик. Соблюдение контракта - тесты. Надеятся на тайпскрипт в этом плане это как полагаться на калитку в чистом поле без забора
3. Значит в этом пункте тайпскрипт бесполезен. Вычеркиваем.
2. Доку проверяет разработчик. Соблюдение контракта - тесты. Надеятся на тайпскрипт в этом плане это как полагаться на калитку в чистом поле без забора
3. Значит в этом пункте тайпскрипт бесполезен. Вычеркиваем.
Можете ваш сбросить ваш конфиг eslint, посмотреть, что у вас там проверяется?
DH
Слодный контракт, например async iterable типами описать мало, у него есть сложное поведение и типы могут совпадать, а поведение другое
и что в таком случае посоветуете делать?