Почему иногда React/Redux в текущем состоянии give me creeps

Здравый смысл — это пракрасный подход, однако ваш код на здравый смысл ни разу не похож. И причина этого в том, что вы не хотите знать даже базовые вещи

Например:

Это называется композиция

Вы ничего не понимете в композиции. Вы пишите код неосознанно, совершенно не понимая, что делаете. Композиция объектов бывает 3-х видов:

• агрегация
• конкатенация
• делегирование

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

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

Боже, что за бред, с чего это вдруг он должен остаться таким же?? С того что вы в вашем выдуманном мире так захотели что ли?

Я ставил задачу так:

напишите какой-то здоровенный класс, а потом попробуйте попробуйте его разбить на несколько классов и объединить их между собой да ещё так чтобы вся логика была в дочерних классах

Объясняю подробно. Изначально, когда мы только начинаем писать код он всегда простой и понятный, классы маленькие. Но требования меняются, дополняются, баги исправляются, логика усложняется и если мы не будем предпринимать меры, то класс начинает разростаться. Что вам подсказывает ваш здравый смысл? Мне он подсказывает, что нужно провести декомпозицию нашего класса. Однако для того, чтобы внешний код который уже работает с этим классом не сломался, очевидно нам нужно оставить интерфейс таким, каким он был до этого. Таким образом декомпозиция может быть приемом для рефакторнига. Вы можете прийти в новый проект, увидеть там класс на 1000 строк и провести рефакторинг этого класса с помощью декомпозиции не трогая код, который этот класс использует. Однако с классами декомпозиция это тот еще геморой. Так как их часто пишут такие ребята как вы, которые смешивыат логику с сайд эффектами, мутации с паралельными вычислениями в один метод. В итоге получается что логику сложно протестировать потому что там какой-то Math.random и обращение к API внутри + еще один метод другого класса который тоже это все может содержать в себе. С чистыми же функциями декомпозиция и тестирование это всегда очень просто и предсказуемо. Чистые функции очень просто писать в TDD.

Боже, вот это убожество, аж кровь из глаз идет.Разумеется такое говно после вас никто поддерживать не будет. Любитель write-only кода.

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

const c = (x) => b(a(x));
const c = compose(b, a);
const c = pipe(a, b);
const c = (x) => { // процедурный стиль полезен для сложных случаев, но можно легко навкладывать функции друг в друга больше чем надо и усложнить код за счет ненужных переменных
   const aResult = a(x);
   const bResult = b(aResult);
   return bResult ;
}

Если же вы считаете, что это

class WithSomeLogic {
    num = 4;
    num2 = 8;
    flag = true;

    constructor(num, num2, flag) {
        this.num = num;
        this.num2 = num2;
        this.flag = flag;
    }

    logic = () => {
        this.num *= 2;
        this.num2 /= 2;
        this.flag = !this.flag;
    }
}

Читабельней чем это:

const initialData = {
  num: 4,
  num2: 8,
  flag: true,
};

const logic = (data) => ({
  num: data.num * 2,
  num2: data.num2 / 2,
  flag: !data.flag
});

И считаете, что так вы используете "все возможности языка", что ж, флаг вам в руки. Мощь JS совсем не в ООП на классах, но в прототипном ООП и функциональном программировани. И да прототипне ООП это не только о __proto__ и prototype, а о создании объектов с помощью {} и каскадировании с помощью { ...obj, ...obj2 }. Создание объектов с помощью new досталась JS-у от Java, так как Брендану Эйху задачу поставили сделать язык похожим на Java. Некоторые даже считают добавление классов в JS ошибкой и я согласен. Они не дают никакой пользы, кроме того, что синтаксис знаком тем, кто раньше писал на C# или Java. Все то, что написано с class и new в JS можно написать без них и получится понятнее. Используя классы вы пишите на части JS которая была создана только для того, чтобы сделать JS более похожим на Java по синтаксису.

Более того вы корявое решение предлагаете, т.к. пример банальный, а если у классов test1 и test2 есть ещё по 6-7 методов и всех их разная логика.

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

const updatedDomainState = domainLogic.pureFn(arg, domainState)

А для setState в реакт так совсем просто, если pureFn каррирована

setDomainState(domainLogic.pureFn(arg))