Так редакс вообще ни для чего не годится, и не годился никогда, с момента появления мертворожденная либа. Или вы не знаете что такое MobX и не пробовали его?

FLUX с Redux или React hooks вообще божественно заходят.

Ахахах, дичь) Но не переживайте, это лишь до тех пор, пока вы джун) Потом наберетесь опыта, прозреете и все станет по другому.

можно почитать взвешенное давнее обсуждение плюсов и минусов обоих стейт-менеджеров

и тут ссылки на обсуждения и статьи

А своя голова есть на плечах? У меня вот есть, в статьях может быть написано все что угодно, главное это то, что мы имеем в реальности, а это далеко не всегда соответствует тому, что пишут в статьях.
Я 2 года писал на react + redux и 5 лет на react + mobx. Так что если вы сами не можете совершенно точно и четко указать на недостатки MobX по сравнению с Redux, причем опять же не чьи-то выдумки прочитанные в какой-то очередной статье, а реальные.
А так вы типичный «я делаю так и считаю так, потому что Вася Пупкин так сказал или потому что я прочитал это в статье» не имеющий своего личного мнения, а зависите лишь от мнения «авторитетов», как вам скажут те, кого вы считаете «авторитетами», так и будете думать.

хотел бы сделать 2 возражения

— глупо обвинять javaScript в функциональщине — вообще-то это фукциональный язык и попытка имитировать на нем ООП приводит к оверхеду на инициализацию инстансов и property lookup через цепочки prototypes

Я констатирую факт, ФП + иммутабильность + чистые функции = полнейший трэш и Write-only код. По поводу оверхэда, он настолько ничтожный что им можно приберечь, он повышает удобство, читаемость и т.п. на порядки раз, поэтому оверхэд на этом фоне ничтожество.

— иммутабельность вас раздражает — ее требует от нас сам React!

Нет, от слова совсем, если мы используем MobX.

предложу вам статью на подумать без эмоций
www.robinwieruch.de/redux-mobx

И? Ничего нового. В чем ваш посыл от этой статью? Якобы что у redux'a есть хоть 1 плюс по сравнению с mobx чтоли? Redux как был ущербным инструментов так и остался, виной тому функциональщина и иммутабильность. Любой инструмент или подход следующий этим 2ум вещам ущербен и обречен.

обычно раздражение возникает у людей когда они не достаточно понимают что-то или не разобрались до конца в чем-то или из-за не большого опыта — не с чем сравнивать

Увы, не мой случай. У меня опыта полно и есть много с чем сравнивать, поэтому разумеется как и любой другой уважающий себя фронтендер который использует реакт, берет в связку только mobx, не ущербный mobx-state-tree, а именно просто mobx.

Таким образом вы никогда не упустите какой-то кейс

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

Например react-query. Скорее всего эта библиотека позволит вам заменить MobX в большенстве мест, где вы его используете

Вообще нет, даже не близко, он слишком примитивен, ограничен и ущербен.

Некоторые события могут быть вызваны в каком-то условном useEffect или autorun как реакции. Какую кнопку будете блокировать в этом случае?

И? В чем проблема? Я вам показал пример, у каждой кнопки которая должна блокироваться, есть зависимость условий в реактивном геттере.

Ну скажем так, говорить что выбор redux'a в 2021 году — осознанный выбор мягко говоря странно.
Отсюда и вопросы и насмешки.
В 2014-2015 годах я ещё могу понять из-за того что все было на зачаточной стадии и пока не успел народ освоиться в экосистеме реакта, с чем и как его лучше использовать, но сейчас это диковато.
Вся проблема в том, что вы после себя оставляете такое наследие из redux'овской лапши, которое не поддается дальнейшему развитию и поддержки, а остальным, которые приходят на проект после вас приходится с этим что-то делать, например переписывать с нуля.
Но за возможность переписать проекты с нуля искренние спасибо, это мой конек)

Я сознательно выбрал redux,

Сознательный выбрал страдать) ради чего?

для меня самым приоритетным условием есть хранение состояния в одном месте.

Смысл?

простой просмотр и анализ этого состояния

А в MobX'e это сложно что ли?)

import { toJS } from 'mobx';
console.log(toJS(userState));

Также вам бы не мешало научиться пользоваться операторами && и || в место того чтобы городить условные операторы только для того, чтобы вернуть Boolean:

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

К тому же далеко не все события можно предотвратить таким способом.

Абсолютно все.

К тому же если событие вызывается в 3-х местах, вам нужно проследить за тем, чтобы во всех трех местах было:

disabled={!state.continueBtnActive}

И что с того? Это props кнопки, он магическим образом не знает сам надо ему быть задисейбленым или нет. Ваш XState ему в этом не поможет, т.к. этому компоненту нужно сообщить об этом.

А какой механизм в MobX ударит вас по рукам если вы этого не сделаете? Что поможем вам отследить все ли переходы описаны правильно? Гуляние по коду в компонент и в Store обратно?

Что вы курите?) Берешь и пишешь, все элементарно, наглядно и прозрачно.

XState заставляет сразу обрабатывать события только тогда когда в этом есть смысл, в место того, чтобы сначала написать, обработки а потом думать когда их вызов должен быть запрещен и ходить блокировать кнопки по UI.

И что это за набор слов не несущий смысла?)

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

Вы как, нормально себя чувствуете?) Голова не болит? :D
Все сверх просто, легко читаемо, очевидно и понятно.

get continueBtnActive() {
    if (this.title.value.trim() === '') {
        return false;
    }
    if (this.addedItems.length === 0) {
        return false;
    }

    return true;
}

// ...
<Button 
    onClick={state.nextStep} 
    disabled={state.continueBtnActive === false}>
        Продолжить
</Button>

А стейт машины позволяют полностью избавиться от этого и еще несколькиз других видов ошибок на уровне правил для описания логики. В место того, чтобы каждый раз вручную блокировать кнопки в UI как наверняка делаете вы (когда не забываете конечно)

Разве что в ваших нездоровых мечтах и снах :D Как обычно к реальности нулевое отношение имеют ваши слова.

Мне тоже страшно смотреть на XState если честно, но я очень проникся подходом так как это дейстительно позволяет сделать некоторые неявные вещи более явными.

Учитывая вашу нездоровую желание страдать как можно сильнее, не удивлен, советую переключиться на другой ЯП, например Barinfuck, с ним вы обретете небывалое счастье, чего уж тут мелочиться.

Да, и я писал, что XState — это для сложного

Вот когда задача действительно сложная, там XState проявит себя на полную

Ну что за смехотворные утверждения, нет ни одного кейса, вообще ни одного даже близко, где XState будет лучше MobX'a или даже того же ущербного redux'a.

Вот эти ваши рассуждения в стиле вот это «для сложного», вот это для «простого» нелепы.

Особенно когда вся сложная логика написана в TDD

Удачи в переписывании всех тестов на каждый чих, когда в процессе разработке меняются бизнес требования, добавляются фичи и т.п.

Ну да, конечно, чистые функции ведь так сложно поддерживать.

Да, ведь это реальный говнокод и лапша, без иронии и без шуток.

нужно намешать сайд эффекты c мутациями в одном методе

Все что угодно, лишь было удобно разрабатывать без боли и страданий.

при декомпозиции забыть сохранить прежнее поведение класса

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

Цель XState не ставит перед собой задачу бла бла бла как и redux

Цель XState и redux заставить разработчиков разочароваться в профессии, ощутить сильное кровотечении из глаз и перегрев стула.

Это конечно можно все и в MobX но там, скорее всего никто просто не будет об этом думать. Точно так же как не будут думать о разделении сайд эффектов и изменения состояния, детерминизме, декомпозиции и многом ещё

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

А время это такой ресурс, который нельзя купить за деньги, поэтому тратить его на то, что делаете вы, мягко говоря плохая идея, мало того что всем остальным адскую подлянку подкладываете в виде вашего «наследия», так ещё и бизнесу дополнительные расходы на переписывание вашей поделки с нуля т.к. других вариантов нет и быть не может, никакой поддержки и развития у проектов написанных вот так, не бывает.

Я считаю, что с задачами по описыванию логики переходов из состояния A в состояние B чистые функции справляются лучше классов с мутациями внутри. И у меня есть очень много аргументов :)

Ахахах ну да ну да, разве что выдуманные и принтянутые за уши в вашем мире.

Я ни разу не пожалел, что использовал redux, так как понимал зачем я это делаю :)

:D:D ага

Если нет понимая зачем нужен redux — он вам не нужен. Однако говорить, что все остальные идиоты потому, что используют его

Ну, что тут сказать, абсурд дело житейское)

Если в вашем случае все просто и главная проблема «обновлять компоненты в разных местах когда данные меняются», то MobX с ней прекрасно справляется до тех пор, пока изменения в данных простые.

Очередное заблуждение, он справляется прекрасно когда данные любые, абсолютно любые.

Мне нужно объяснять вам все недостатки процедурного подхода при масшатбировании?

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

Я не сектант и не фанатик как вы, у которого есть подходы ради подходов и выдуманные проблемы, которых не существует в реальной жизни.

А так, да, объясните, потому что пока все что я от вас слышу к реальности не имеет вообще никакого отношения.

Использует агрегацию, доделегирование. Но у вас делегирование недоделанное так как после рефакторига у test1 и test2 должен остаться такой же интерфейс как был до рефакторинга. то есть данные должны читаться как test1.num а не как test2.logic.num. Кажется вы забыли написать 3 геттера для полей чтобы избежать этой проблемы.

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

так как после рефакторига у test1 и test2 должен остаться такой же интерфейс как был до рефакторинга.

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

Кажется вы забыли написать 3 геттера для полей чтобы избежать этой проблемы.

Нет никакой проблемы, сколько раз говорить.

А теперь решение на ФП:

// some utils.js
const pipe = (...fns) => x => fns.reduce((y, f) => f(y), x);

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

const test1 = pipe(
  // some stuff here
  someLogic,
  // some stuff here
);

const test2 = pipe(
  // some stuff here
  someLogic,
  // some stuff here
);

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

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

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

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

И в чем проблема??? Разбиваются элементарно.

Допустим у вас есть логика которая дублируется в методах разных классов, и вы не можете использовать паттерн декоратор так как логика в средине

Да где проблемы то??? Ну все же элементарно, есть множество вариантов решения, вот например:

class Test1 {
    num = 2;
    num2 = 4;
    flag = false;

    someLogic = () => {
        // some stuff here
        someBasicClassesLogic(this);
        // some stuff here
    }
}

const test1 = new Test1();

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

    someLogic = () => {
        // some stuff here
        someBasicClassesLogic(this);
        // some stuff here
    }
}

const test2 = new Test2();

function someBasicClassesLogic(classEx) {
    classEx.num *= 2;
    classEx.num2 /= 2;
    classEx.flag = !classEx.flag;
}

test1.someLogic();
test2.someLogic();

console.log(`test1.num`, test1.num);
console.log(`test1.num2`, test1.num2);
console.log(`test1.flag`, String(test1.flag));
console.log('----');
console.log(`test2.num`, test2.num);
console.log(`test2.num2`, test2.num2);
console.log(`test2.flag`, String(test2.flag));

или вот

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;
    }
}


class Test1 {
    logic = new WithSomeLogic(2, 4, false);

    someLogic = () => {
        // some stuff here
        this.logic.logic();
        // some stuff here
    }
}

const test1 = new Test1();

class Test2 {
    logic = new WithSomeLogic(4, 8, true);

    someLogic = () => {
        // some stuff here
        this.logic.logic();
        // some stuff here
    }
}

const test2 = new Test2();

test1.someLogic();
test2.someLogic();

console.log(`test1.num`, test1.logic.num);
console.log(`test1.num2`, test1.logic.num2);
console.log(`test1.flag`, String(test1.logic.flag));
console.log('----');
console.log(`test2.num`, test2.logic.num);
console.log(`test2.num2`, test2.logic.num2);
console.log(`test2.flag`, String(test2.logic.flag));

и т.д. и т.п. как удобно, так и разбивай, вариантов масса, ну элементарно же.

В чем прикол говорить о проблемах, которые проблемой не являются от слова совсем? Вы пытаетесь оправдать свой убогий код, что якобы если писать по человечески то ты утонешь в «проблемах»? Смешно и абсурдно.

Вы называете проблемой элементарнейшие вещи.

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