Comments 7
// Yeah, I don't understand this either. But it gives us nice typing
// for our reducer actions.
На месте автора оригинального текста я бы постеснялся публиковать такой Voodoo код. А совет с использованием any вообще сводит на нет смысл использования TypeScript.
В качестве примера проекта можно добавить Formik
Совет использовать ANY в сложных ситуациях на порядки ускоряет переход на TS. А может и вообще позволяет его провести.
Ну вы скажете. В команде я один могу писать на TS, и пишу на нем какие-то ключевые части приложения, где без строгой типизации я вообще не представляю как обойтись. И я никогда не против, если JS-онли разработчик немного подправит ядро через any, а позже я сделаю рефакторинг и прочее, а затем чуваку ещё и дифф скину, типа, смотри как оно на тайпе выглядит, чтобы учился.
Когда выразительности JS уже недостаточно для работы, тогда ты с лёгкостью учишь TS, благо для любого среднего программиста это неделя. А начинающему разработчику никогда не объяснить, почему строгие типы — это классно, сам же был таким, и пальцем у виска крутил, когда первые версии TS видел, однако с тех пор и TS серьезно развился.
Сначала они городят эти костыли и тонну костыльного кода чтобы поддерживать это дерьмо.
А потом, когда даже самый гуру тайпскрипта в команде не может подсказать как решить ту или иную проблему типизации, советуют просто заткнуть эту дырку с помощью any.
type Action<K, V = void> = V extends void ? { type: K } : { type: K } & VКогда в руках молоток, то все кажется гвоздями… Зачем тут вообще нужен условный тип? Вот так не проще ли сделать?
type Action<K, V = {}> = { type: K } & VНо еще лучше взять решение вот отсюда: https://habr.com/ru/company/alfa/blog/452620/
import * as React from 'react'
А потом у нас лендинги по 3 секунды загружаются.
Использование Typescript с React – руководство для новичков