Тайп-фу в TS
У нас тут есть сторонний HTTP-сервис, возвращающий либо { success: true } либо { error: 42, description: "because" }. Ну и по openapi.yaml генерится в таком духе декларация (за правильность кейвордов не ручаюсь):
export interface Foo {
bar:
| { success: boolean }
| { error: number, description: string }
}Ну и есть ( Read more... )
export interface Foo {
bar:
| { success: boolean }
| { error: number, description: string }
}Ну и есть ( Read more... )
Comments 13
А если там вызов функции, которая 146% выбрасывает исключение, он тоже узнает, что есть обрыв потока управления? Например
function throw_new_Error(desc) {
throw new Error(desc)
}
....
if ('error' in foo) {
throw_new_Error(foo.description)
}
> Ну и это конечно непонятно как на наших гребцов ляжет. Разрешу им везде as unknown as any писать чтобы батька потом чинил :)
А нельзя перед написанием кода с алгебраическими типами слегка подумать? Это же язык с выводом типов, там всегда можно добавить ещё один вариант. Конечно, оно не такое гибкое, как какой-нибудь Питон/JS, где можно лепить вообще поток сознания. Но это и не кондовый Java.
Reply
Reply
С этим справится любой галерщик за 2-3 стори пойнта - легко найти виноватого, легко сопрорвождать, изолировать баги, саппортить
Это на много надёжнее чем дрочить с типами.
Пакет ставится через управление зависимостями, в го с этим проще в разы чем в джавапетоне (поэтому нахуй джавапетон)
Что там внутри этого пакета - ебля с типами или any , да насрать вообще . Лишь бы 100% каверидж, потому что это внешнее апи
Этот же подход в принципе универсален - не только для внешнего апи, но и например для фряшной zfs
Reply
Ну и вот для экономии букв вместо этого предлагается лепить псевдо-OpenAPI спеку. Это пилотный маленький проект, так что посмотрим на реакцию гребцов и по итогам в будущих проектах уберём то, что окажется слишком "заумным".
Вопрос был скорее, как выглядит типизированный API для работы с вариантами/ветвлениями/юнионами/типами-суммами. А уж как он написан - руками ли или генератором - дело десятое.
Reply
то есть openapi.yaml это ваше творчество, и вы хотите написать сваггер спеку для внешнего апи ? Слишком хитрый план. Тупо беру первое попавшееся под руку широко используемое апи elasticsearch, и не вижу ни одной попытки его сваггеризировать (хотя там тоже можно навертеть тайп сумм), зато много много биндингов/сдк. Но сама идея написать спеку сваггера по доке мне нравится. Теоретически можно получить профит если вы пишете клиентов для внешнего апи на разных языках , например гуи для всех на свете платформ например. Но опять таки сомневаюсь что это в принципе возможно, иначе эластик бы сваггеризировали, а не писали биндинги к нему
> как выглядит типизированный API
играл в эту же игру давно на F# . Взял betfair API, и такой - а давайте распишем обёртки для всех вызовов с тайпсуммами etc. Результат более чем разочаровал, мб потому что F# всратый язык.
Reply
А это у вас просто reproduction. А у меня free inquiry, другой подход. К сожалению, потерял ссылку на free inquiry.
> Но сама идея написать спеку сваггера по доке мне нравится.
Не совсем. План ещё хитрее. План стар как мир - на внешние интерфейсы (из которых может прийти "что попало") посадить IDL, по которому генерить и типы, и рантайм-валидатор.
В качестве этого идла использовать (в вольной манере) жсон схему/openapi.
Ну и идея сэкономить путём написания вместо двух простыней одной "упрощённой" и "стандартной" простыни. Ну и унифицировать везде логику валидации, чтобы она "когнитивно не мозолила глаза".
Отчасти это из-за отстутствия дсл для типизированных парсеров жсона (который есть, например, в C#).
> Результат более чем разочаровал
Ну тут вопрос о том, что вынос работы с апи в типизированный модуль так или иначе все делают. И вопрос был о том, как выглядит этот типизированный модуль в общем виде. При этом не обязательно оборачивать вызовы "один в один".
Reply
Reply
Reply
Меня вот привлекают 3 вещи:
- вебсторм (в условиях, когда команда умеет лепить рефакторингами)
- ловля забытых ретурнов и эвэйтов
- сокращение рантайм-проверок, так как всё делается "на входе", и в дальнейшем коде нуллов не может быть
Второе, как я понимаю, чисто жс-проблема и лечится переходом на условный Го/шарп.
Reply
Но с типами можно навернуть так, что сам потом не разберешься. Ну или в тайпинги библиотек залезть и офигеть. В общем, бывает непросто. И то что там в type-challenges - меня даже и не пугает. Но оно того стоит.
При этом всём, система типов не сильно тебя ограничивает, как в том же C#. Возможности динамического языка - не сильно теряются.
Так что TS - лучшее что случилось с фронтом в этом веке, после реакта. Какой-то так.
Reply
Leave a comment