Comments 12
то, что индекс начала берется не включительно, а индекс конца - включительно - мне показалось не очень очевидным
Тем не менее в примере как будто и первый и второй индекс берутся включительно
Тут тоже есть интересные штуки.
Вот честно, что-то Typescript где-то свернул не туда, или я неправильно понимаю его назначение. Вся эта арифметика типов уже похожа на какое-то извращение отдельный язык, созданный для усложнения жизни программиста. Почему в других языках не возникает таких ситуаций, где нужно «все вот это»?
Потому что в других языках какая-нибудь форма обычно не выглядит так:
["foo", { value: "bar", name: "baz" }, ["foobaz", "foobar"]]
А в веб - обычное дело :) Отсюда и получается какой-нибудь тип string | SelectInputValue | ArrayInputValue и нужно как-то с ним работать. Тут скорее надо говорить о том, что веб свернул не туда, но это совсем другая история
Да, это и есть отдельный, полный по Тьюрингу, язык описания типов для упрощения жизни программиста, за счет того, что можно точнее описать ожидания от кода и они, при этом, еще проверяться будут (берет на себя некоторую часть ответственности тестов). Какие-то сложные типы в реальности редко используются, и, в основном, в библиотечном коде. После ts в других языках иногда гибкости не хватает, особенно union types, duck typing. В статье, кстати, каких-то особых извращений нет, а вот тут есть
Представляете. Это все нужно в обычном CRUD: creatable тип не имеет Id - его назначает сервер. updatable или patched тип может иметь не полный состав полей, да ещё ранее поля были опциональны, а должны стать nullable - так как json не передаёт undefined. Read/select собственно это обычная структура, из которой мы генерим производные типы выше.
И так для каждой сущности.
Почему в других языках не возникает таких ситуаций, где нужно «все вот это»?
Возникает конечно же, просто смотря о каких "других" языках речь. В условной Java "не возникает" потому что ей и близко не хватает выразительности для этого, соответственно программисты там не мыслят такими категориями вообще, вот им и "не нужно". У соседней Scala например подобные инструменты есть, и там разработчики вполне себе видят в них пользу.
Ну или самый банальный пример - С++. То, что там вытворяют, тайпскрипту в страшном сне не приснится.
К слову об именовании, Either c английского переводится как любой, оба, тоже, либо, каждый (в зависимости от контекста, выбирайте сами).
Тут как раз все понятно любому англоговорящему. По смыслу переводится как "любой из", другие варианты используются в частных случаях ("either of two will be bad" – дословно "любой из двух будет плох", по-русски скорее напишут что-то вроде "оба плохи").
Простыми словами смысл в том, чтобы сделать из указанных (вторым аргументом) ключей один (только один!) ключ опциональным с неопределенным типом, т.е. нежелательным (правда, по такой логике, при передаче в качестве второго аргумента только одного ключа (как в первом примере), соответствующее ему поле тоже должно было бы стать нежелательным, но что-то не срослось. Будем считать, что тоже "не баг, а фича" :) ).
Наоборот же: смысл в том, чтобы из указанных ключей только один был представлен в объекте (при этом второй становится нежелательным). Поэтому, когда указывается всего один ключ, то конструкция не имеется смысла, она просто оставляет тип как есть.
Тут как раз все понятно любому англоговорящему. По смыслу переводится как "любой из", другие варианты используются в частных случаях ("either of two will be bad" – дословно "любой из двух будет плох", по-русски скорее напишут что-то вроде "оба плохи").
Возможно. У меня сложилось впечатление, что слово either не имеет строгого аналога в русском языке
Наоборот же: смысл в том, чтобы из указанных ключей только один был представлен в объекте (при этом второй становится нежелательным). Поэтому, когда указывается всего один ключ, то конструкция не имеется смысла, она просто оставляет тип как есть.
Вы, кажется, правы. Тогда пазл сходится
Сравнение utility types библиотек или тайпскрипт на стероидах