Как заставить TS работать на вас

TypeScript - безусловно необходимый инструмент, без которого уже нельзя представить современную разработку. Но автор явно перегибает палку, городя огороды там, где им не место. Начиная с первого примера: мы хотим убедиться, что в коде функции не кириллица? Ок, описываем тип. Как нам теперь убедиться что в описании типа нет ошибки? Там что, не может быть кириллицы?

Ваш метакод - это тоже код. Чем его больше и чем он сложнее - тем больше и вероятность ошибиться. В итоге, мы получили громоздкого монстра там, где могли бы обойтись одной строчкой легко читаемого кода и не сократили вероятность ошибки, а повысили. Также, мы повысили когнитивную нагрузку на работу с кодом, потратили лишнее время... И это там, где проблемы и не было изначально, так как подобные вещи легко тестируются и дебажатся и ловятся спелчекером.

Хороший признак профессионализма - умение упрощать а не усложнять.

Еще недостатки Typescript: 1) когда Вы пишите абсолютно новое то Вы не всегда четко знаете предметную область и соответственно Вы априори не можете определить типы изначально 2) Когда Вам надо внедрить в проект js код то Вы обязаны его приводить к системе Ваших типов но сторонняя библиотека об Вашей иерархии абсолютно ничего не знает. Встает вопрос - а чем тогда отличается подход обьектного проектирования(программирования) от подхода первоначального определения типов ? Явное требование первоначально все "затипизировать" часто просто мешает ходу проектной мысли И тут точно нужен некий баланс

Добавим поддержку значений в px и в %

Ширина ладно. В реальности там намного больше возможных единиц, но их нетрудно перечислить. Опустим сейчас всякие auto и max-content, хотя с ними есть вопросы.

А вот допустим в CSS есть несколько форматов цветов, у каждого по нескольку вариаций форматов параметров и корректно их все учесть - задачка нетривиальная.
Тоже предлагаете всё типизировать?

P.S. Лично я ограничился бы двумя базовыми случаями - число и строка. Достаточно ловить всякие ошибки с андефайнами и функциями вместо их вызова. А если кто-то передал некорректную CSS-строчку, то сам себе буратино. Проще ловить такие опечатки при тестировании, чем иметь и поддерживать горы запутанного (а он почти всегда такой) инфраструктурного TS-кода.

Что это за правильный код ТС, где вы используете кастинг, возвращаете в match пустой массив, и чтобы это пофиксить следующей строкой дефолтите его на 0px..

Лично для меня утиная типизация в TS, помимо её плюсов, заставляет быть бдительным в части её минусов. Объясню. Вот ждёт фронт с бэка данные аккаунта. Ник и имэйл. На бэке мы получаем ентити из БД, в которой имеется и пароль тоже. И TS с удовольствием пропустит данное поле вместе с ожидаемыми. Каждый раз приходится обрабатывать, исключая ненужные. P.S., может быть я просто не знаю как это готовить.

Читая статью, а потом комментарии, вижу, что корень проблем в большинстве случаев общий. Причем даже в статье ровность повествования в один момент выбивается из колеи, так как не учитывается данное положение. Поэтому могу предложить информацию к размышлению.

Постановка задачи.

Допустим, мы разрабатываем компонент, который должен корректно обрабатывать ширину элемента так же, как это сделано, например, в компоненте VCard из Vuetify:

Я перешел по ссылке VCard, и там нет никаких % и px. Поэтому неплохо было бы задавать задачу не через пример, а явно указывая, что хотите сделать.

Начнем с привычного подхода — просто напишем код без явного указания типов:

Один тип вы всё-таки задали. И если так со стороны посмотреть, проблема тут не в инферинге, так как инферится всё корректно. А в том, что вы реализуете несколько другую задачу, которая отличается от неназванной вами задачи.

TypeScript не подсвечивает ошибку, потому что он не понимает, какие данные мы ожидаем. В результате неправильное значение спокойно проходит, и даже опечатка остается незамеченной.

ТС не подсвечивает ошибку, потому что её нет. Так как вы не дали постановку задачи, мы не знаем, как и ТС, что будет ошибкой.

Теперь функция защищена от ошибок, разработчик может быть абсолютно уверен, что реализация соответствует его ожиданиям.

defineElementWidth('Не число');
defineElementWidth(100); // ✅

Тут такая же фигня. О каких ошибках идёт речь? Вы поменяли один тип на другой. Зачем? У вас задача поменялась? Вроде ничего не менялось. Тогда как у вас строка превратилась в число? Вы сами ниже покажете, что это не обязательно. И по логике вам нужно было задавать не number, а `${number}`.

Единственное, что поменялось, вы стали явно контролировать тип возвращаемого значения и тип строки.

Так какая же изначально была задача?

Добавим поддержку значений в px и в %, как во Vuetify:

Я щёлкнул по ссылке выше, и там просто string | number. На самом деле это неважно, просто не очень выразительно. Вы уже второй раз ссылаетесь, а по ссылке этого нет. Если я не нашёл, тогда прошу прощения.

И вот мы подошли к выводу:

Вывод

TypeScript работает эффективнее, если мы сначала определяем типы, а затем реализуем логику. Это позволяет получать подсказки от IDE прямо во время написания функции.

Если посмотреть на всё выше, то возникает вопрос: "О чём это всё"? О написании типов? О том, какой тип куда и зачем нужно вставлять? Почему решили отказаться от инферинга возвращаемого значения? Тупо из-за ошибки?

Вот это вот всё было зачем:

type Unit = px | '%';
type Width = number | ${number} | ${number}${Unit};
type Style = { width: ${number}${Unit} };

function defineElementWidth(value: Width): Style {
  if (typeof value === 'string') {
    const match = value.match(/^(\d+)([a-zA-Z%]*)$/)?.slice(1).filter(Boolean) ?? [];
    const [width = '0', unit = 'px'] = match;

    return {
      width: ${parseFloat(width)}${unit as Unit},
    };
  }

  return {
    width: ${value}px,
  };
}

Используя утверждение типа, снова вернулись к тому, с чего начали, и снова можете использовать кириллицу, и TS вам не подсветит ошибку. Так значит, дело было не в той ошибке?

Я про вот эту строку, если что: const [width = '0', unit = 'px'] = match;

В принципе, можно и от вероятности ошибки избавиться, и даже тип полностью инферить, это при желании, конечно:

function isStringNumber(value: Width): value is ${number} {
  return typeof value === 'string' && /^\d+$/.test(value);
}

function defineElementWidth(width: Width) {
  if (typeof width === 'number' || isStringNumber(width)) {
    const unit: Unit = 'px';
    return { width: ${width}${unit} };
  }

  return {
    width,
  };
}

Так имеет ли всё-таки смысл данный вывод:

TypeScript работает эффективнее, если мы сначала определяем типы, а затем реализуем логику.

В чём корень проблемы? Когда мы говорим: "Здесь должен быть такой тип" (это отсылка на книгу "Здесь должен быть текст"), что мы имеем в виду?

А имеем мы в виду именно дизайн, то есть проектирование нашего ПО. По-хорошему, мы определяем не типы, а разбираемся с дизайном нашей программы. Все эти ошибки — это ситуации, которые мы хотим учесть и которые изначально заданы в условиях задачи. Или мы пренебрегаем этим, чтобы сэкономить время или ещё что-то, то есть упрощаем дизайн и делаем программу менее устойчивой к изменениям.

В данной статье изначально очень мало внимания уделялось дизайну, то есть правильной постановке задачи, обозначению важных для бизнеса или системы ситуаций, и поэтому типы скакали туда-сюда, потерялась первоначальная идея избежать ситуации, когда разработчик мог неверно написать значение юнита и т.п.

Действительно, когда создаём программы на js и ts, по-разному относимся к проектированию. TS требует, чтобы проектированию изначально уделялось больше внимания. Типы — это именно про то, чтобы в коде дизайн был ярко выраженным. Когда вы выбираете тип, вы в первую очередь думаете о дизайне программы, а не просто о том, чтобы это всё завелось, когда банально партируете js на ts. И вот когда вы изначально ставите себе ясную задачу и объясняете себе её детали, типы начинают работать.

... duble