Учитывая, что ViewModel знает все о пропсах компонента, кажется, на деле означает, что в итоге связка ViewModel + реактовский компонент чисто для рендера это с технической точки зрения практически то же самое, что компоненты на классах (ViewModel это как классовый компонент без функции render()) :)
Я тоже топлю за MobX, но мне стало интересно, как бы вы предложили решать обозначенную в статье проблему с тем, что классы с логикой подписаны на изменение полей друг друга, из-за чего возникают неочевидные связи в приложении? Я так понял, что решение автора через Flux/Redux состоит в том, что все подписано на сообщения (actions) в глобальной шине сообщений (flux/redux) и это, предположительно, уменьшает ментальную нагрузку на разработчика, который пытается понять логику в предложении.
Как ни странно, со всем соглашусь. Правда, для ререндеринга конкретного компонента есть detectChanges(), который может периодически спасать, когда на ровном месте начинаются тормоза, но все равно все эти ручные вызовы change detection'а напрягают, конечно.
А если не затруднит, не могли бы привести примеров, какие у вас были проблемы с DI, когда было больно?
Не сильно относится к вашему ответу и вообще всей теме, но захотелось сказать, что практически все популярные библиотеки для работы с формами прибиты к реактовским компонентам и из-за этого с ними очень-очень сложно работать, как только начнет действительно сложная, но довольно типовая логика к ним добавляться. В Ангуляре вон из коробки предлагают примитивы для работы с контролами, которые в себе содержат всю эту isValid, isTouched, isWhatever, reset и т.д. функциональность, но они с вьюхой соединяются через прослойку без какой-либо логики, т.е. вьюха просто перерисовывается, когда value и всякие состояния меняются, а всю реальную логику работы с формой можно вынести в отдельный слой и писать вообще (практически) не думая о компонентах. Кажется, что было бы здорово во фронтовых сообществах продвигать идею того, что работа с формами очень удобна, когда это отдельный слой, никак не привязанный к рендерингу и жизненному циклу компонентов
А удобно ли на практике всю логику, описанную в статье, и логику по вебсокетам держать в хуках вообще? Я бы это все вынес в какой-нибудь не связанный с реактом слой сервисов и датасорсов, а через хуки просто инжектил бы себе эти сервисы и датасорсы, и в компонентах с инпутами просто забирал и отрисовывал бы нужные данные. Кажется, что вы примерно того же и добились, но логика осталась в хуках?
В последнем кейсе в MobX перерендера списка не будет, если массив вручную мутировать, но если у нас такая ситуация, когда на каждый экшн нужно перезапрашивать весь список с бэкенда и перерисовывать, то при присвоении этого нового массива в observable-свойство все перерисуется, верно ведь?
Все так. Поэтому кажется норм решением стараться максимально писать логику прилаги вне Реакта (классы с MobX) и максимально избегать useEffect'ов
А как быть, если нужно конкретно от этой кнопки задать margin? Указать его явно через style вместо пробрасывания "класса-костыля"?
Учитывая, что ViewModel знает все о пропсах компонента, кажется, на деле означает, что в итоге связка ViewModel + реактовский компонент чисто для рендера это с технической точки зрения практически то же самое, что компоненты на классах (ViewModel это как классовый компонент без функции render()) :)
Я тоже топлю за MobX, но мне стало интересно, как бы вы предложили решать обозначенную в статье проблему с тем, что классы с логикой подписаны на изменение полей друг друга, из-за чего возникают неочевидные связи в приложении? Я так понял, что решение автора через Flux/Redux состоит в том, что все подписано на сообщения (actions) в глобальной шине сообщений (flux/redux) и это, предположительно, уменьшает ментальную нагрузку на разработчика, который пытается понять логику в предложении.
Как ни странно, со всем соглашусь. Правда, для ререндеринга конкретного компонента есть detectChanges(), который может периодически спасать, когда на ровном месте начинаются тормоза, но все равно все эти ручные вызовы change detection'а напрягают, конечно.
А если не затруднит, не могли бы привести примеров, какие у вас были проблемы с DI, когда было больно?
А расскажете, что вам в ангуляре не нравится?
Не сильно относится к вашему ответу и вообще всей теме, но захотелось сказать, что практически все популярные библиотеки для работы с формами прибиты к реактовским компонентам и из-за этого с ними очень-очень сложно работать, как только начнет действительно сложная, но довольно типовая логика к ним добавляться. В Ангуляре вон из коробки предлагают примитивы для работы с контролами, которые в себе содержат всю эту isValid, isTouched, isWhatever, reset и т.д. функциональность, но они с вьюхой соединяются через прослойку без какой-либо логики, т.е. вьюха просто перерисовывается, когда value и всякие состояния меняются, а всю реальную логику работы с формой можно вынести в отдельный слой и писать вообще (практически) не думая о компонентах. Кажется, что было бы здорово во фронтовых сообществах продвигать идею того, что работа с формами очень удобна, когда это отдельный слой, никак не привязанный к рендерингу и жизненному циклу компонентов
А удобно ли на практике всю логику, описанную в статье, и логику по вебсокетам держать в хуках вообще? Я бы это все вынес в какой-нибудь не связанный с реактом слой сервисов и датасорсов, а через хуки просто инжектил бы себе эти сервисы и датасорсы, и в компонентах с инпутами просто забирал и отрисовывал бы нужные данные. Кажется, что вы примерно того же и добились, но логика осталась в хуках?
А вы же тут с самого начала обсуждаете пересоздание объектов? Не доступ по ключу? Доступ по ключу и у
{}, и уMapвсегда же будетO(1)?В последнем кейсе в MobX перерендера списка не будет, если массив вручную мутировать, но если у нас такая ситуация, когда на каждый экшн нужно перезапрашивать весь список с бэкенда и перерисовывать, то при присвоении этого нового массива в observable-свойство все перерисуется, верно ведь?