Comments 12
Больше та и сказать нечего.
Hidden text
Выкладывать примеры которые не тайпчекаются в статье про "Реализацию на TypeScript" это такое себе конечно. Что за тип FNхотя бы? Было бы неплохо рассмотреть как в таких функциях нормальный вывод типов сделать ещё (спойлер: в общем случае никак, но с некоторыми ограничениями можно).
Спасибо за ваши замечания!
Действительно, FN в статье используется без явного определения. Внесу правку в статью.
Что касается нормального вывода типов, тут вы так же абсолютно правы. В ближайшие пару дней внесу дополнения в статью.
В общем случае сделать, наверно, можно (почти допиленный вариант, без поддержки некоторых кейсов, например без необязательных элементов кортежа), но без нормального автокомплита/саджеста, только тайпчекинг. Использован прием с проверкой аргумента генерика, не помню как называется, там какая-то аббревиатура.
К сожалению такие манипуляции как минимум не прокатывают на женериках, что является существенным ограничением в плане тайпчекинга.
const square = (x: number) => x * x
const double = (x: number) => x * 2
const id = <T,>(x: T) => x
const r = pipeline(square, id, double) // ErrorЩас все в основном реализуют подобный функционал через хардкод N-ого числа аргументов (effect, fp-ts, ramda, remeda), потому что это накладывает наименьше ограничения. Обычно делают штук 30 и в итоге мало кому надо столько в принципе, а если и надо можно просто сделать `pipeline(..., pipeline(,,,))`.
через хардкод N-ого числа аргументов
Это позволяет решить проблему с генериками?
И, кстати, в этих вариантах нельзя воткнуть произвольный массив функций (константа arr в моем наброске). Хотя это наверно редкий кейс.
Это позволяет решить проблему с генериками?
Да, ту которую я выше привёл позволяет. + Вывод типов аргументов работает и их не надо хардкодить.
Можно ещё кстати такие штуки городить например.
Такой код сложнее поддерживать и дебажить
Будет ошибка допустим во 2 функции, и вам нужно ее результат вывести, с таким подходом это не получится
Спасибо за ваш комментарий!
Ваше замечание о поддержке и отладке важно. В случае ошибки, например, во 2ой функции, может быть сложно получить промежуточный результат и определить, на каком этапе произошла ошибка. Хотя в традиционном подходе с последовательными и вложенными вызовами функций может показаться, что отладка проще, на практике это может быть сложно при глубокой вложенности, так как требует ручного вмешательства на каждом уровне.
Для улучшения отладки при использовании пайплайнинга и композиции можно применять такие техники, как логирование промежуточных результатов (например, с помощью функции tap ) и создание модульных тестов для проверки отдельных шагов процесса.
Тем не менее, эти темы выходят за рамки данной статьи. Основная цель статьи — продемонстрировать подходы, которые улучшают читаемость кода.
а pipline - это как в angular?
Честно, говоря ни разу не видела, чтол бы такое в проектах писали.
Из моей практики могу сказать, что все по большей части пишут императивно.
Может в каком-нить условном гиганте вроде мтс или вымпелтелеком такое и зайдет, а вот в маленьких стартапах или конторах , где надо бизнесу быстро все получать , так как бабки горят - там об этом даже не задумаются. Скорее просто проект перепишут, когда код будет тяжело поддерживать. А потом все по кругу
Pipelining & Composing: улучшаем читаемость кода. Реализация на TypeScript