Мне кажется это все-таки решение ближе к redux. Я за простой mobx - потому что он 1) реактивный 2) нет никаких контейнеров 3) намного меньше кода.
как раз в этом и была проблема - начинали с простого mobx, но реактивность приводила к забавным состояниям гонки между "сторами" (когда в результате синхронизации накатывается пачка апдейтов, но они приходят "тиками") и это было очень больно
когда прилетает апдейт на Х-надцать тысяч записей (мелких, но много), их надо локально обсчитать с тем что лежит в indexeddb тут очень неприятно когда стора оказывается в "неконсистентном" состоянии
как раз в этом и была проблема - начинали с простого mobx, но реактивность приводила к забавным состояниям гонки между "сторами" (когда в результате синхронизации накатывается пачка апдейтов, но они приходят "тиками") и это было очень больно
Ну ведь она приходила в нужном порядке? Один за другим просто часто?
не выйдет, потому что мне нужно уметь отображать неконсистентное состояние и логика "доведения" до консистентности плотно завязана на взаимодействие с пользователем
Кейс интересный, но мне кажется сильно специфичный, возможно в этом случае инструмент не оптимален, но даже вот этот случай не дает мне повода думать делать что-то на redux.
Кейс интересный, но мне кажется сильно специфичный, возможно в этом случае инструмент не оптимален, но даже вот этот случай не дает мне повода думать делать что-то на redux.
Согласны ли вы с этим? Что кроме таких вот случаев редких, когда "автоматическая коробка" не подходит, нужно все таки избегать rdux и не пропагандировать его как типичное решение даже простых задач.