Комментарии 10
Статья про то как в прошлом веке писали фронтенд, и при этом вы не поставили пометку "средневековье". Ай ай ай, зачем вводить людей в заблуждение.
Ведь все мы знаем, что все адекватные люди не живущие в далеком прошлом уже много лет используют для реакта MobX или же если не нравится реакт, то Vue. И там и там настоящая реактивность и разумеется мутабильность с автоматической подпиской/отпиской на изменения, ибо getters/setters в Javascript пришли ещё в 2010 году.
Суть статьи не заключается в том, чтобы побудить вас перейти с MVC на Redux, а в том, чтобы взглянуть на MVC-Flux-Redux спустя время и подвести итоги не только с теоретической стороны, но и с практической, так как в основном по этому вопросу предоставляют только теорию.
А зачем глядеть на Flux/Redux и прочую шушеру спустя время?
Уже все глядели 100500 раз и всем понятно что это не состоявшийся подход во фронтенде, от слова совсем.
Я понимаю если бы вы сразу написали в первом предложении что речь идет про богом забытые вещи, которые в настоящее время ни в ком случае нельзя применять в разработке, вместо этого нужно применять React + MobX + Typescript. Чтобы не стрелять в ноги себе, другим, а так же не обрекать бизнес на изначально мертворожденный неподдерживаемый проект который будет все равно переписываться с нуля, но уже с использованием человеческого подхода.
А так вы можете ввести людей в заблуждение которые начинают свой путь и они подумают что использовать Redux это нормально и потратят уйми времени и нервов просто в пустую. Вместо того, чтобы сразу начать с актуальных и нужных вещей.
Почему вы не взглянули на паровой двигатель и на дрова в качестве топлива? Наверное потому что и так всем понятно что эта технология изжила себя давным давно и никто в здравом уме к ней никогда возвращаться не будет. Тоже самое и с Flux/Redux и прочей шушеры.
Почему Вы считаете, что подход с redux устарел? И почему пишете, что фронтенд перешёл от redux к mobx?
Почему Вы считаете, что подход с redux устарел? И почему пишете, что фронтенд перешёл от redux к mobx?
А вы писали проекты используя Redux и используя MobX? Там как бы разница вообще небо и земля. Вопрос "почему mobx, а не redux" сразу отпадает так то)
Вот честно в тысячный раз очевидные вещи перечислять, почему Redux и все его производные и ему подобные это полнейшее дно уже нет желания. Если для вас это не очевидно, то вам просто без разницы что и как делать, главное чтобы ЗП платили.
Разрабатывал только на redux. Про mobx читал и смотрел теорию. Поэтому и хотел узнать о Вашем опыте :) Понимаю, что Вам не хочется писать сравнение в комментариях, поэтому буду благодарен, если скинете статьи/видео/рассказы (англоязычные), где описаны трудности связанные с разработкой на redux и его производных, и как mobx покрывает эти кейсы. Хотелось бы отметить, что интересуют кейсы с крупными проектами.
Размер проекта вообще не важен, тут играет роль не mobx/redux и т.п., а играет роль разум и понимание как строить архитектуру проекта.
Самое простое и быстрое это посмотреть сразу как все это работает, тут представлен ряд примеров связки react + mobx - https://codesandbox.io/s/solitary-currying-8g58ms?file=/src/index.js
Можете посмотреть, поиграться и сразу прощупаете принципиальную разницу. Так же смотрите в консоль, чтобы увидеть оптимизацию рендеров из коробки, лишних рендеров нет, только те компоненты, данные которые они используют изменяются
Я тоже топлю за MobX, но мне стало интересно, как бы вы предложили решать обозначенную в статье проблему с тем, что классы с логикой подписаны на изменение полей друг друга, из-за чего возникают неочевидные связи в приложении? Я так понял, что решение автора через Flux/Redux состоит в том, что все подписано на сообщения (actions) в глобальной шине сообщений (flux/redux) и это, предположительно, уменьшает ментальную нагрузку на разработчика, который пытается понять логику в предложении.
Да, вы верно поняли.
классы с логикой подписаны на изменение полей друг друга, из-за чего возникают неочевидные связи в приложении?
А с чего вы взяли что возникают неочевидные связи в приложении при использовании MobX'a?
Вы всё видите сверху вниз, слева направо, что класс X читает и изменяет такие-то переменные, а класс Y читает и изменяет в том числе те, которые читает и изменяет класс X. И где тут неразбериха я честно не понимаю? Все ведь лежит на ладони.
Красная нить MVC-Flux-Redux