Да, конечно, мы не говорим о полноценном приложении, хотя и в данном случае все окей, мы ожидаем в результате Promise<ResultType>, где ResultType это User[], то есть дыры в типизации конечно нет. Там еще много условностей вроде ошибок и некорректных ответов api. Но это упрощение для примера
Все проще! Для себя я это объясняю так: в угловых скобках ПРИ ВЫЗОВЕ указывается тип данных с которым функция будет работать. А в ОБЪЯВЛЕНИИ функции в угловых скобках стоит Generic, обобщенный тип, который принимает тип из ВЫЗОВА. Более сложные конструкции a<b<c>>() – просто описывают "как бы вложенные объекты". a – вернет объект типа b<c>, который вернет объект типа c. Еще раз, как верно подмечено в статье, TypeScript не делает работу, он служит описанием взаимодейстия типов в вашем коде.
Другая большая штука, справедливо не описанная в статье из-за сравнительной сложности, это Generics. Для тех кто пришел из PHP или JS, это может быть немного непонятно с первого взгляда, но вещь очень мощная. Простой пример: функция враппер для обобщенных ajax вызовов:
Функция выше может возвращать разные типы данных, в зависимости от path. Как раз для таких случаев можно смело переходить на Generic:
type User = {
name: string;
}
async function fetchApi<ResultType>(path: string): Promise<ResultType> {
const response = await fetch(`https://example.com/api${path}`);
return response.json();
}
const data = await fetchApi<User[]>('/users')
В данном случае ResultType это Generic, способный принимать любой указанный в вызове тип, но явно указывающий на то что функция должна вернуть именно его. Как видите нет необходимости в дополнительных проверках типов, достаточно указать ожидаемый тип при вызове функции.
Я тоже так считал, но на деле оказалось что сеошники требуют часть ссылок прятать из href="" в data-href="", притом что это все внутренние ссылки. Если меню в дизайне чуть ниже чем в начале страницы, то в коде размещать его в самом верху и на JS, к примеру, перемещать на место, да и вообще в идеале чтоб пол сайта на JS подгружалось аяксом, особенно контент взятый с других сайтов. К сожалению, в итоге сайт гораздо сложнее поддерживать, но что самое печальное, он тормознее, глючнее и теперь о сеошниках я думаю еще хуже чем раньше :(
Да, конечно, мы не говорим о полноценном приложении, хотя и в данном случае все окей, мы ожидаем в результате Promise<ResultType>, где ResultType это User[], то есть дыры в типизации конечно нет. Там еще много условностей вроде ошибок и некорректных ответов api. Но это упрощение для примера
Хотя и это не совсем правда, TS может много, но это уже совсем другая история https://github.com/type-challenges/type-challenges
Все проще! Для себя я это объясняю так: в угловых скобках ПРИ ВЫЗОВЕ указывается тип данных с которым функция будет работать. А в ОБЪЯВЛЕНИИ функции в угловых скобках стоит Generic, обобщенный тип, который принимает тип из ВЫЗОВА. Более сложные конструкции a<b<c>>() – просто описывают "как бы вложенные объекты". a – вернет объект типа b<c>, который вернет объект типа c.
Еще раз, как верно подмечено в статье, TypeScript не делает работу, он служит описанием взаимодейстия типов в вашем коде.
Другая большая штука, справедливо не описанная в статье из-за сравнительной сложности, это Generics. Для тех кто пришел из PHP или JS, это может быть немного непонятно с первого взгляда, но вещь очень мощная. Простой пример: функция враппер для обобщенных ajax вызовов:
Функция выше может возвращать разные типы данных, в зависимости от path. Как раз для таких случаев можно смело переходить на Generic:
В данном случае ResultType это Generic, способный принимать любой указанный в вызове тип, но явно указывающий на то что функция должна вернуть именно его. Как видите нет необходимости в дополнительных проверках типов, достаточно указать ожидаемый тип при вызове функции.