Почему контекст не является «инструментом для управления состоянием»

А всё потому что код писался ровно по заветам Дана Абрамова.

Да уж, он тот ещё говнокодер. И увы почему-то люди думают что он пишет хорошо и правильно и пытаются ему подрожать.

Просто идеальный комплект для быдлокодерства.

Набыдлокодить можно с чем угодно. И MobX/Redux Saga etc тут не спасут никак.

Там не "сильно много". Там "тьма" бойлерплейта.

Если по примеру рекомендаций в документации класть константы в один файл, редьюсеры в другой, а action creator-ы в третий — тогда да, чёрт ногу сломит, и довольно быстро. Не понимаю этого функционального деления. А если делить логически, то получаются небольшие аккуратные файлы, которые вряд ли будут больше классов MobX. Я ж говорю, всё зависит от прямоты рук.

Вы так говорите, как будто я его никогда не использовал ) Конечно, в курсе. Вот только нужен ли он? Зависит от задачи. Иногда проще считать данные прямо на месте, через useMemo.

К слову, реселект весит всего 800 байт, так что в плане размера всё довольно неплохо.

Что делают? Лежат.

Есть виджеты с разными типизированными полями, логикой и т.п. Для работы с этими виджетами есть класс обёрнутый в mobx. У каждого виджета есть поле data в котором хранится некая структура данных, специфичных для этого виджета. С точки зрения класса без разницы, что именно там лежит, он должен уметь эти данные отдавать, получать, и уметь реагировать на обновления.

про @observable.ref почитаю, спасибо

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

Какие ещё проблемы вы о чем? Тем более вы говорите большие проблемы, интересно. На практике хоть раз в жизни реализуйте проект с MobX'ом и увидите что проблем то и нет никаких вовсе, одно лишь удовольствие.

А то прочитали где-то про какие-то там потенциальные проблемы, которых нет. Все проблемы — кривые ручки которые не умеет строить архитектуру приложения.
Если бы были проблемы, то никто бы и никогда не использовал MobX, я в том числе. Но вот незадача, проблем то нет, от слова совсем.

которы кроме как чтения всего кода нигде не декларируется

Что простите??? Что значит нигде не декларируется?? Вы вообще о чем??

ну и как я писал выше, использование классов и декораторов для меня на сегодняшний день при наличии замечательного паттерна для переиспользования кода hooks, скорее минус

Во первых использование классов и декораторов в MobX'e опционально, всё тоже самое там есть с обычными функциями.

Никто не мешает совмещать hooks с MobX'ом. Ну сразу же видно что вы даже ни присосались к MobX'у, вы считаете что эти вещи несовместимы.

redux чуть более многословен но все его декларации чисты, всегда известен и понятен однонаправленный поток изменений данных в сторе и он прост как молоток

Чуть чуть более многословен?? Жесть.

Это однонаправленный поток данных?

function handleChange(e) {
    store.dispatch({
        type: 'SET_INPUT_VALUE',
        payload: e.target.value,
    });
}
<input onChange={handleChange} />

setInterval(() => {
    store.dispatch({
        type: 'SET_INPUT_VALUE',
        payload: 'value from interval',
    });
}, 1000);

А это однонаправленный поток данных?

class Store {
    @observable text = '';
    handleInputChange = (e) => {
        this.text = e.target.value;
    }
}
const store = new Store();

<input onChange={store.handleInputChange} />

setInterval(() => {
    store.text = 'value from interval';
}, 1000);

И ещё на всякий случай, вдруг не знали:
Подсказка, WebStorm и VS Code умеют сто лет в обед — «Find References / Find Usages» где сразу вино в каких местах переменная читается, а в каких местах переменная изменяется. Теперь когда вы узнали эту древнюю фичу, ещё раз подумайте какие там у вас «потенциальные» проблемы с observables есть? Вот просто интересно, какие же??

Я воспроизвёл зомби с use-context-selector-ом версии 1.4.2 (код прямо из репы). Всё работает именно так, как и я ожидал. Приложение просто падает:

Тестовый код. Код написан ногами, sorry. Просто сделайте git clone && npm ci && npx webpack-dev-server. Это чисто proof-of-concept. По сути я просто видоизменил код из статьи чтобы было удобнее разбор полётов проводить.

Собственно я ничего особенного и не сделал там. Обратите внимание на вывод в консоль на скриншоте выше.

• По-умолчанию у нас в state лежит { a, b, c }.
• По нажатию на кнопку deleteB мы убираем из {a,b,c} наш b и получаем {a,c}. Примерно как в той статье.
• Это приводит к смене context.Provider value=%o значения.
• Это в свою очередь запускает тот самый цикл с проверками на изменённость состояния.
• А в них сравнивается новый результат селектора со старым. Если они равны — forceRender не вызывается.
• В нашем случае для ItemB всё тупо падает т.к. <ItemB/> вообще должен быть к этому времени уже удалён. Но он не успевает удалиться. Ибо его селектор вызывается раньше. С уже новым state-ом при котором его (ItemB) в живых быть уже не должно.

В общем те самые stale props и zombee children. И ровно тоже самое что я вижу в ваших статьях. Можно легко видоизменить код под useSelector в react-redux и возможно он точно так же упадёт. А может те костыли с try-catch нас спасут :) Но на любую хитрую гайку найдётся болт с резьбой.

Было ещё интересно почему render ItemA вызывается повторно. Оказалось React ловит эту ошибку и считает — а попробую ка я ещё раз отрендерить <App/>, вдруг на этот раз прокатит. И вот когда он падает 2-й раз — он падает уже по-настоящему. Любопытно.

Ещё одна любопытная деталь про useContextSelection (версии 1.4.2). Оно пролюбливает любые обновления своего селектора. Там тупо он нигде не обновляется и никак не фигурирует в deps. В итоге мои тесты показывают что селектор для компонента задаётся ТОЛЬКО во время изначального рендера.

Это в какой-то степени решение проблемы stale-props. С таким подходом они stale по-умолчанию :-) Вы правда используете это в продакшне? Или это свежие версии либы такие?