Сразу оговорка для тех, кто хорошо разбирается в Haskell или Scala

SPL
Рассмотрим в качестве примера один из простейших классов типов — Show, — который определяет операцию приведения к строке. Он определен в модуле fp-ts/lib/Show:

Это определение читается так: тип A принадлежит классу Show, если для A определена функция show : (a: A) => string.
Реализуется класс типов следующим образом:

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

Использование классов типов позволяет использовать подход наименьшего знания (principle of least knowledge, principle of least power) — когда функция запрашивает от своих аргументов только тот набор функциональных возможностей, который будет ей использован. В TypeScript за счет структурной типизации этот подход воспринимается очень органично, и использование классов типов позволяет развить эту идею.
Давайте рассмотрим еще один синтетический пример — нам надо написать функцию, которая для произвольной структуры данных приводит ее содержимое к строкам. Благодаря трюку из предыдущей статьи, классы типов можно писать не только для конкретных типов, но и для типов высшего порядка. Тип Mappable, он же Functor — это как раз пример такого класса типов. Функтор позволяет выполнять преобразования с сохранением структуры — к примеру, если у нас есть список, то операция map изменит тип элементов, но сохранит порядок в этом списке; если у нас есть дерево — то map сохранит последовательность ветвей и узлов; если у нас есть хэш-таблица — map сохранит ключи нетронутыми. Функтор как раз и позволит нам решить поставленную задачу:

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

Когда вы поймете, что хорошо бы комментарии хранить в дереве, а не списке, вам придется переписать все места, где с коллекцией comments обращаются как со списком.
Но вы можете воспользоваться подходом с классами типов, и организовать код несколько иначе:

В целом, использование классов типов как паттерна проектирования в TypeScript можно описать так:

• Функциональность, которая может быть обобщена, выносится из базового типа данных в отдельный интерфейс, полиморфный по типу данных или типу контейнера.
  
• Каждая функция, которая хочет использовать эту функциональность, «запрашивает» нужный набор классов типов как первый каррированный аргумент. Это делается для того, чтобы не завязываться на конкретный экземпляр/instance класса типов — в результате получается более гибкое и тестируемое решение.
  
• Для различения экземплятор классов типов от обычных аргументов функции есть смысл давать им имена в UPPER_SNAKE_CASE, чтобы их использование бросалось в глаза на фоне camelCase в остальном коде. Понятно, что это хорошо работает в случае, если вы пишете идиоматично — если же ваш код $tyled_like_php, то вам стоит придумать свою нотацию.

Некоторые полезные классы типов
В библиотеке fp-ts представлено достаточно много классов типов, в которых есть смысл разбираться, если вы хотите понимать подходы «взрослого» ФП.
Functor (fp-ts/lib/Functor)
Функтор определен операцией map : <A, B>(f: (a: A) => B) => (fa: F<A>) => F<B>, которую можно рассматривать с двух точек зрения:

• Функтор для какого-либо вычислительного контекста F знает, как применить чистую функцию A => B к значению F<A>, чтобы получилось F<B>.
  
• Функтор умеет поднять чистую функцию A => B в вычислительный контекст F так, что получается функция F<A> => F<B>.

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

• Сохранение идентичности: map(id) ≡ id
  
• Сохранение композиции функций: map(compose(f, g)) ≡ compose(map(f), map(g))

С функторами мы уже сталкивались в предыдущей и этой статье, и их полезность в целом нельзя преуменьшить — функторы дают начало целой плеяде других классов типов, поэтому если вы знаете, что у вас есть, к примеру, экземпляр монады, то автоматически у вас есть операция из класса типов Functor map.
Monad (fp-ts/lib/Monad)
О, эта ужасная монада, она же буррито, она же railway, она же моноид в моноидальной категории эндофункторов. На самом деле, монада это предельно простая штука. Внимание, сейчас будет самый короткий монадический туториал!
Монада определяется правилом «1-2-3»: 1 тип, 2 операции и 3 закона:

• Монада может быть определена для типа высшего порядка — скажем, для конструкторов типов вроде Array, List, Tree, Option, Reader и т.д. — словом, всего, что мы привыкли видеть в дженериковой форме.
  
• Монада может определена двумя операциями, причем одним из двух равнозначных путей — операции chain и join выражаются друг через друга, поэтому для описания монады достаточно только of и одной из этих двух операций:
  
  • Первый способ:
    
    of : <A>(value: A) => F<A>
    chain : <A, B>(f: (a: A) => F<B>) => (fa: F<A>) => F<B>
  • Второй способ:
    
    of : <A>(value: A) => F<A>
    join : <A>(ffa: F<F<A>>) => F<A>
• Наконец, любая монада должна подчиняться трём законам:
  
  • Закон идентичности слева: chain(f)(of(a)) ≡ f(a)
    
  • Закон идентичности справа: chain(of)(m) ≡ m
    
  • Закон ассоциативности: chain(g)(chain(f)(m)) ≡ chain(x => chain(g)(f(x)))(m)