Comments 14
Использовать redux это самая великая глупость. Можно было ещё скидку сделать в 2015 и 2016 году, но после это уже просто нелепо.
что вы можете предложить в качестве альтернативы?
что вы можете предложить в качестве альтернативы?
MobX, использую ещё с 2016 года и бед не знаю, одно удовольствие.
Сходу две проблемы:
- с mobx вы адаптируете код под mobx. В отличии от redux'а, где компоненты продолжают использовать пропсы и им начхать откуда они пришли и куда ведут колбеки. При желании можно заменить стор.
- из-за использования observable, стор mobx не может хранить большую коллекцию сложных объектов (это касается любых подобных решений, в т.ч., например, redux toolkit). Несколько лет назад я проводил тестирование: mobx со скрипом позволял обрабатывать 50к таких объектов, redux с легкостью 200к.
Но это не значит, что mobx надо хоронить, как вы спешите хоронить redux. Полагаю, mobx прекрасно себя показывает в небольших приложениях.
Redux надо уметь готовить, тогда не будет никакого особого бойлерплейта, ведь, полагаю, именно это является объектом критики.
- с mobx вы адаптируете код под mobx. В отличии от redux'а, где компоненты продолжают использовать пропсы и им начхать откуда они пришли и куда ведут колбеки. При желании можно заменить стор.
Всё тоже самое можно делать с MobX. Только вот props hell это дичь и от этого много лет назад ушли.
- из-за использования observable, стор mobx не может хранить большую коллекцию сложных объектов (это касается любых подобных решений, в т.ч., например, redux toolkit). Несколько лет назад я проводил тестирование: mobx со скрипом позволял обрабатывать 50к таких объектов, redux с легкостью 200к.
// В глубину ничего не будет реактивным, реактивная только эта ссылка
@observable.ref items = []; // Хоть миллион объектовПолагаю, mobx прекрасно себя показывает в небольших приложениях.
Не, он себя идеально показывает вообще в любых приложениях, в огромных, в средних и в мелких.
Redux надо уметь готовить, тогда не будет никакого особого бойлерплейта, ведь, полагаю, именно это является объектом критики.
Как ни крути, он всё равно не дотянет до MobX. Как минимум из-за:
1) Ручной pub/sub в явном виде. (В MobX это автоматически)
2) Обязательная иммутабильность.
3) Неудобство работы с асинхронщиой, и костыли в виде RTK и т.п. особно погоды не делают, всё равно мягко говоря всё это так себе.
Про вынужденный говнокод (и как бы ты не старался он 10000% будет говнокодом) из-за этого подхода я вообще молчу.
Всё тоже самое можно делать с MobX. Только вот props hell это дичь и от этого много лет назад ушли.
С какого количества пропсов начинается hell? Почему вообще использование props считается чем-то плохим, ведь в этом вся фишка реакта - черная коробочка pure function, в которую на вход даешь одно и всегда получаешь одно и то же.
Про вынужденный говнокод (и как бы ты не старался он 10000% будет говнокодом) из-за этого подхода я вообще молчу.
Есть какой-нибудь пример кода с mobx, который вам не кажется говнокодом? Может быть некий open source проект.
Redux, использую ещё с 2016 года и бед не знаю, одно удовольствие.
Мы в команде используем редакс и он помогает решать текущие задачи. Какой смысл засерать инструмент, если вы им не пользуйтесь(или не умеете)??
Использовать стейт менеджер в Next для небольших объёмов данных не то чтобы профитно. Часто для таких задач хватает контекстного менеджера с каким-нибудь браузерным хранилищем. Так же часто используются query параметры.
ИМХО использовать стейт менджер можно в случаях когда на странице много динамичных данных либо данные используется по всему приложению и их так же много и они динамичны
Мне пока не довелось встретить кейс, в котором для решения задачи нужно было бы тащить стейт менеджер. С грамотной декомпозицией и архитектурой можно обходиться и без него.
Так же рекомендую ознакомится с новой документацией Next, которая включает в себя использование папки app. Код выглядит немного красивее и очевиднее. Это теперь не бета функционал. В качестве легковестной современной альтернативы Redux сущевствует Zustand.
Пробовал работать с redux в next js проектах, показалось, что они плохо дружат.
Если вы хотите результаты всех запросов за данными на разных страницах складывать в релакс стор, то это плохой путь. Next сам из коробки делает код сплиттинг, но весь редаксовый код, со всеми сагами и редьюсерами будет одним чанком. По мере роста приложения будет расти количество загруженного и неиспользуемого кода на каждой странице. Для кэширования запросов лучше использовать реакт query, SWR и т.п. и не тащить все эти данные в стор.
Если вы редакс используете только для каких-то общих данных, как в примерах, выбранный язык и т.п., то редакс вообще не нужен с его многослойностью и сложностью. Можно посмотреть на effector, zustand или вообще контекст
Next.js и Redux — для чего и как использовать вместе