В этом случае ещё может помочь as const, которое отключает авторасширение типа: const x = 'value'; // x: 'value'. Работает с любыми значениями, а свойства в объектах ещё и помечает как readonly
А для чего отдельная папка под интерфейсы и енамы? Кажется, они должны лежать рядом с тем местом, где они подходят по смыслу (рядом с функциями, например, которые их принимают/возвращают), а не в отдельной папке чисто для них.
Да, но при хорошем знании тайпскрипта код действительно легче и изучать, и рефакторить. Проптайпы есть только для реактовых компонент, всё остальное приходится читать по-старинке, держа в уме возможные значения всех переменных. Когда я перешёл на тайпскрипт, внезапно оказалось, что в фокусе внимания надо держать гораздо меньше вещей, потому что всю эту информацию за тебя обрабатывает компилятор. Можно не проверять каждый раз, что в переменной лежит правильное значение – если это не так, то машина подскажет об этом сама.
А время, которое уходит на написание типов, я считаю, окупается с лихвой – хотя бы потому, что написание типов – это то же проектирование частей приложения, только результаты проектирования мы записываем формальным и частично проверяемым автоматическими средствами способом.
А зачем нужен дополнительный тип-параметр, который фактически не используется нигде в функции? Мне тоже кажется, что лучше честно указать top-тип и не привлекать дополнительных сущностей.
По поводу второго вопроса – это может быть просто полезная привычка писать возвращаемый тип для самопроверки, или же привычка начинать написание функции с описания её типа
Это уже статический анализ получается. Но в мире js с ним будет сложно, потому что всё может зависеть от контекста исполнения множеством самых разных способов
Кажется, можно ещё проще – с единственным аргументом:
onClick: (_: void) => voidВ этом случае ещё может помочь
as const, которое отключает авторасширение типа:const x = 'value'; // x: 'value'. Работает с любыми значениями, а свойства в объектах ещё и помечает как readonlyА для чего отдельная папка под интерфейсы и енамы? Кажется, они должны лежать рядом с тем местом, где они подходят по смыслу (рядом с функциями, например, которые их принимают/возвращают), а не в отдельной папке чисто для них.
Ну, если из спортсменов получаются хорошие депутаты, то и из киберспортсменов получатся программисты!
Да, но при хорошем знании тайпскрипта код действительно легче и изучать, и рефакторить. Проптайпы есть только для реактовых компонент, всё остальное приходится читать по-старинке, держа в уме возможные значения всех переменных. Когда я перешёл на тайпскрипт, внезапно оказалось, что в фокусе внимания надо держать гораздо меньше вещей, потому что всю эту информацию за тебя обрабатывает компилятор. Можно не проверять каждый раз, что в переменной лежит правильное значение – если это не так, то машина подскажет об этом сама.
А время, которое уходит на написание типов, я считаю, окупается с лихвой – хотя бы потому, что написание типов – это то же проектирование частей приложения, только результаты проектирования мы записываем формальным и частично проверяемым автоматическими средствами способом.
А зачем нужен дополнительный тип-параметр, который фактически не используется нигде в функции? Мне тоже кажется, что лучше честно указать top-тип и не привлекать дополнительных сущностей.
По поводу второго вопроса – это может быть просто полезная привычка писать возвращаемый тип для самопроверки, или же привычка начинать написание функции с описания её типа
Это уже статический анализ получается. Но в мире js с ним будет сложно, потому что всё может зависеть от контекста исполнения множеством самых разных способов