Для большинства компаний это очень утопичное допущение. Найти просто хорошего senior фронтенд разработчика — очень сложная задача. А найти ещё и эксперта в области TypeScript — прямо большая удача.
Я не предлагал искать отдельного эксперта по TS. Под «адвокатом ts» имею ввиду неформальную роль — человека, которому тема интересна и который готов повышать свой уровень, делиться знаниями с окружающими.
Хорошо работает подход — типизировать по верхам при помощи ts-комментариев.
Swagger построен на спецификации OpenApi, которая в свою очередь предоставляет множество вариантов по генерации данных. Вот, например, один из них. Можно поискать и другие, тут у меня нет рекомендации.
Вы можете настроить генерацию так, чтобы типы для контрактов собирались автоматически и размещались в какой-нибудь специальной директории вашего проекта.
Тогда схема работы может быть такой: изменился контракт на бэкенде -> запустили генератор и обновили ts-типы -> попробовали собрать проект -> обнаружили и поправили ошибки ts.
Если контракты на бекенде меняются нечасто, то же самое можно делать и вручную. Главная идея в том, что отдельный слой типов и интерфейсов отвечает за контракты с бэкендом и меняется только при изменении этих контрактов.
Вы подчеркнули важную проблему — иногда очень много времени тратится на типизацию.
Вот пара идей, как с этим можно справляться:
В команде/компании есть адвокат ts — хорошо разбирается в теме и приходит на помощь. Также есть отдельный канал по ts, в который можно написать с вопросом.
Оцениваем, насколько стоит вкладываться в типизацию конкретного блока.
Например, есть блок легаси кода на js, который написали год назад и с тех пор не меняли. Фича готова, протестирована, заехала в продакшен. Если она и будет меняться, то вероятно с каким-то глобальным рефакторингом. Врядли стоит тратить много сил на разборки с типами, покрыть основные входы-выходы может быть вполне достаточно.
Учет статистики вели грубо, просто по количеству файлов (несправедливый подход, но для визуализации достаточно). Сама диаграмма по данным легко строится в программах типа excel (мы же использовали встроенный макрос из Atlassian Wiki).
В статье я привел простой пример, чтобы показать идею.
Это нормально, что решить задачку можно множеством вариантов, unknown подойдет даже лучше :)
any хорош и удобен в распаковках типов. Посмотрим на встроенные утилиты, извлекающие аргументы или возвращаемое значение из функций:
type ReturnType<T extends (...args: any) => any> = T extends (...args: any) => infer R ? R : any;
type Parameters<T extends (...args: any) => any> = T extends (...args: infer P) => any ? P : never;
Еще классные примеры — в статье, которую я уже приводил выше.
Можно ли тут использовать unknown?
Да (с поправкой на …args)
Нужно ли тут использовать unknown?
¯\_(ツ)_/¯
ControlValueAccessor содердит функцию setDisabledState, которая вызывается при изменении disabled статуса.
В реактивных формах разумно вызывать disable() и enable() из модели, а не передавать это атрибутами в шаблон.
export interface ControlValueAccessor {
/**
* This function is called when the control status changes to or from "DISABLED".
* Depending on the value, it will enable or disable the appropriate DOM element.
*
* @param isDisabled
*/
setDisabledState?(isDisabled: boolean): void;
}
Спасибо за развернутый и полезный комментарий.
Надеюсь, вы понимаете, что статья рассчитана на нулевой уровень знаний, и её цель — дать минимальные зачатки предмета. Здорово, что вы акцентировали внимание на неточностях и задали направление, в котором следует разбираться дальше.
Я не предлагал искать отдельного эксперта по TS. Под «адвокатом ts» имею ввиду неформальную роль — человека, которому тема интересна и который готов повышать свой уровень, делиться знаниями с окружающими.
Точно!
Вы можете настроить генерацию так, чтобы типы для контрактов собирались автоматически и размещались в какой-нибудь специальной директории вашего проекта.
Тогда схема работы может быть такой: изменился контракт на бэкенде -> запустили генератор и обновили ts-типы -> попробовали собрать проект -> обнаружили и поправили ошибки ts.
Если контракты на бекенде меняются нечасто, то же самое можно делать и вручную. Главная идея в том, что отдельный слой типов и интерфейсов отвечает за контракты с бэкендом и меняется только при изменении этих контрактов.
Вот пара идей, как с этим можно справляться:
В команде/компании есть адвокат ts — хорошо разбирается в теме и приходит на помощь. Также есть отдельный канал по ts, в который можно написать с вопросом.
Оцениваем, насколько стоит вкладываться в типизацию конкретного блока.
Например, есть блок легаси кода на js, который написали год назад и с тех пор не меняли. Фича готова, протестирована, заехала в продакшен. Если она и будет меняться, то вероятно с каким-то глобальным рефакторингом. Врядли стоит тратить много сил на разборки с типами, покрыть основные входы-выходы может быть вполне достаточно.
Это нормально, что решить задачку можно множеством вариантов, unknown подойдет даже лучше :)
any хорош и удобен в распаковках типов. Посмотрим на встроенные утилиты, извлекающие аргументы или возвращаемое значение из функций:
Еще классные примеры — в статье, которую я уже приводил выше.
Можно ли тут использовать unknown?
Да (с поправкой на …args)
Нужно ли тут использовать unknown?
¯\_(ツ)_/¯
В реактивных формах разумно вызывать disable() и enable() из модели, а не передавать это атрибутами в шаблон.
Сравните 231321421 и 42321312 слева направо? Не уверен :)
https://github.com/thejameskyle/itsy-bitsy-data-structures
К сожалению, мне не хватает знаний, чтобы аргументированно спорить. Вероятно, автор ошибся. Вы можете написать ему об этом в оригинальный репозиторий.
Что касается хеш-таблиц, автор оговаривает, что коллизий не предполагается.
Спасибо за развернутый и полезный комментарий.
Надеюсь, вы понимаете, что статья рассчитана на нулевой уровень знаний, и её цель — дать минимальные зачатки предмета. Здорово, что вы акцентировали внимание на неточностях и задали направление, в котором следует разбираться дальше.
Вы правы. Внёс изменение.
Спасибо!
Приведите, пожалуйста, пример.
Спасибо, конечно!
Спасибо за статью!
И ещё один перевод — Улучшение загрузки шрифтов c помощью localStorage и WOFF2.
Если вы новичок и хотите узнать побольше, посмотрите:
1. Доклад http-протокол Алексея Бережного.
2. Курс «Компьютерные сети».