Хотел бы узнать мнение по поводу использования отдельного стора внутри каждого модуля. Zustand это позволяет реализовать. Сверху можем прикрутить TanStack Query для работы с бэком и кеширования. Только нужно не забыть про версионирование внутри стора. В совокупности с FSD на ура подход залетает.
Что значит неправильно пишут? На любом языке можно неправильно писать. Да, коннект имеет свои плюсы. Но селекторы так же. Их легче типизировать, легче тестировать, дебажить, читать, и писать на них. Меньше кода для этого требуется. Я тоже раньше топил за коннект. Но уже давно пришел к выводу,- что и там и там свои плюсы и минусы. И что значит свернул не туда? Никто не мешает использовать коннект. + касательно хейта в сторону редакса: да, старый редакс - это ппц. Я на нем годы писал. Но есть РТК, который сделал огромную работу. Да, под капотом тот же редакс со своими минусами по оптимизации по типу "каждый отправленный екшен проходиться по всем редюсерам чтобы определить какой из подписанных к стору компонентов перерисовать". Но опять же, за всю мою карьеру не было ни одного случая чтобы из-за редакса весь проект лагал. Это что же надо сделать: всю логику со стейтом туда занести? Потом мне хвалили мобХ, который убийца редакса. Выяснилось что у него так же много минусов. Потом эффектор - так же... Теперь все хвалят зустанд. Его не знаю. Мб он в разы лучше РТК. Будет время - поизучаю. А так - редакс (новый) - не идеальный, со своими минусами. Но говном его точно не назвать. За видео спасибо. Посмотрю позже чтобы освежить память =)
У меня был видос где я прям хейсу редакс, но тут идет рассуждение только с архитектурной стороны. И сравнение подходов. В любом случае не отменить тот факт, что использование useSelector прямо в компонентах это нарушение всех принципов SOLID Но да это проще, и это работает так как ничего сложного на Redux мы не пишем. Так если ничего сложного можно взять и zustand/react-query А если уж что то сложное можно и задуматься об инверсии и тестируемости
@@paromovevg а сам по себе синтаксис JSX - не нарушение принципов СОЛИД? Мы ведь мешаем в нем и ДЖс, и разметку и стили? Хук useEffect - не нарушение СОЛИД? Ведь он тоже юзается в компоненте, и мы в одном компоненте и разметку пишем, и обрабатываем запросы и прочее. Зашел в доку zustand, там так же селекторы. В доке пример: useBearStore(selector). + касательно реакт-квери. Почему говорят что он -альтернатива редакс? Он ведь для других целей предназначен. Первый - для работы с серверным состоянием. Редакс - для глобального стора (тут я не об РТК-квери). Или имеется ввиду что можно юзать реакт-квери как глобальный стор из-за кеширования? Мол если использовать один и тот же запрос в разных компонентах,- то в одном из них мы лишний запрос делать не будем т.к. ответ возьмется из кэша? Поправь плз, я могу ошибаться. Спасибо
@@paromovevg useSelector без использования селекторов - ужас, с использованием селекторов, которые отвязывают компонент от структуры стора - ничем не хуже коннекта на мой взгляд, который делает то же самое.
Что мешает вынести логику с хуками в отдельный компонет контейнер, оставив только UI? Тогда у нес также появятся "свободные" UI контролы и "адаптеры" с бизнес логикой. К тому же, можно бизнес логику также вынести в кастомный хук, который также как и селекторы и диспетчеры очень легко оборачиваются в юниты
Да, в конце видео я говорил, что так тоже можно, но у этого есть свои ограничения. Например подключение к стору элементов списка делается не тривиально (если нужно сохранить мемоизацию)
Более того я наверное сам так бы и делал сейчас. Все же connect не официально уже deprecated. Но сам подход коннекта понять и эмулировать никто нам не запрещает
Это хорошо работаета исключительно в проектах уровна todo list, в реальности это реализация паттерна God Object - все (!) дочерние зависимости переходят в один объект. Хотя сам факт использования Redux превращает весь проект в говнокод.
Возможно я зря не показал, как это развивается в более сложных кейсах. Но нет это работает в сложных приложениях и очень хорошо Это не god object так как там нет логики. God object это про нарушение SRP. Это декларативная конфигурация с единой ответственностью. Вся логика должна быть делегирована либо селекторам санкам либо компонентам и инфраструктурным модулям
@@paromovevg Тогда появляется антипаттерн завистливый объект. Redux требует наличие boilerplate - что является говнокодом. Это даже не говоря об использование голобального Redux стора - антипаттерн глобальных данных. Таже нет смысла тестировать компоненты в которых основная логика в зависимостях (пропсах).
Хотел бы узнать мнение по поводу использования отдельного стора внутри каждого модуля. Zustand это позволяет реализовать.
Сверху можем прикрутить TanStack Query для работы с бэком и кеширования. Только нужно не забыть про версионирование внутри стора.
В совокупности с FSD на ура подход залетает.
Сам использую этот подход для большинства проектов. Но в сложных с точки зрения бизнес логики проектах redux бывает оправдан
Что значит неправильно пишут? На любом языке можно неправильно писать.
Да, коннект имеет свои плюсы. Но селекторы так же. Их легче типизировать, легче тестировать, дебажить, читать, и писать на них. Меньше кода для этого требуется.
Я тоже раньше топил за коннект. Но уже давно пришел к выводу,- что и там и там свои плюсы и минусы.
И что значит свернул не туда? Никто не мешает использовать коннект.
+ касательно хейта в сторону редакса: да, старый редакс - это ппц. Я на нем годы писал.
Но есть РТК, который сделал огромную работу. Да, под капотом тот же редакс со своими минусами по оптимизации по типу "каждый отправленный екшен проходиться по всем редюсерам чтобы определить какой из подписанных к стору компонентов перерисовать".
Но опять же, за всю мою карьеру не было ни одного случая чтобы из-за редакса весь проект лагал. Это что же надо сделать: всю логику со стейтом туда занести?
Потом мне хвалили мобХ, который убийца редакса. Выяснилось что у него так же много минусов.
Потом эффектор - так же...
Теперь все хвалят зустанд. Его не знаю. Мб он в разы лучше РТК.
Будет время - поизучаю.
А так - редакс (новый) - не идеальный, со своими минусами. Но говном его точно не назвать.
За видео спасибо. Посмотрю позже чтобы освежить память =)
У меня был видос где я прям хейсу редакс, но тут идет рассуждение только с архитектурной стороны. И сравнение подходов.
В любом случае не отменить тот факт, что использование useSelector прямо в компонентах это нарушение всех принципов SOLID
Но да это проще, и это работает так как ничего сложного на Redux мы не пишем.
Так если ничего сложного можно взять и zustand/react-query
А если уж что то сложное можно и задуматься об инверсии и тестируемости
@@paromovevg а сам по себе синтаксис JSX - не нарушение принципов СОЛИД? Мы ведь мешаем в нем и ДЖс, и разметку и стили?
Хук useEffect - не нарушение СОЛИД? Ведь он тоже юзается в компоненте, и мы в одном компоненте и разметку пишем, и обрабатываем запросы и прочее.
Зашел в доку zustand, там так же селекторы. В доке пример: useBearStore(selector).
+ касательно реакт-квери. Почему говорят что он -альтернатива редакс? Он ведь для других целей предназначен. Первый - для работы с серверным состоянием. Редакс - для глобального стора (тут я не об РТК-квери).
Или имеется ввиду что можно юзать реакт-квери как глобальный стор из-за кеширования? Мол если использовать один и тот же запрос в разных компонентах,- то в одном из них мы лишний запрос делать не будем т.к. ответ возьмется из кэша?
Поправь плз, я могу ошибаться. Спасибо
@@paromovevg useSelector без использования селекторов - ужас, с использованием селекторов, которые отвязывают компонент от структуры стора - ничем не хуже коннекта на мой взгляд, который делает то же самое.
Что мешает вынести логику с хуками в отдельный компонет контейнер, оставив только UI? Тогда у нес также появятся "свободные" UI контролы и "адаптеры" с бизнес логикой. К тому же, можно бизнес логику также вынести в кастомный хук, который также как и селекторы и диспетчеры очень легко оборачиваются в юниты
Да, в конце видео я говорил, что так тоже можно, но у этого есть свои ограничения. Например подключение к стору элементов списка делается не тривиально (если нужно сохранить мемоизацию)
Более того я наверное сам так бы и делал сейчас. Все же connect не официально уже deprecated. Но сам подход коннекта понять и эмулировать никто нам не запрещает
А не чего не мешает. Это называться сам придумал проблему, сам ее решил. Посмотрите какой я молодец). Это проблема архетектуры, а не инструмента...
Это хорошо работаета исключительно в проектах уровна todo list, в реальности это реализация паттерна God Object - все (!) дочерние зависимости переходят в один объект. Хотя сам факт использования Redux превращает весь проект в говнокод.
Возможно я зря не показал, как это развивается в более сложных кейсах. Но нет это работает в сложных приложениях и очень хорошо
Это не god object так как там нет логики. God object это про нарушение SRP.
Это декларативная конфигурация с единой ответственностью. Вся логика должна быть делегирована либо селекторам санкам либо компонентам и инфраструктурным модулям
Сам факт использование инструмента не превращает проект а говнокод. Плохие программисты превращают проект в говнокод
@@paromovevg Тогда появляется антипаттерн завистливый объект.
Redux требует наличие boilerplate - что является говнокодом. Это даже не говоря об использование голобального Redux стора - антипаттерн глобальных данных. Таже нет смысла тестировать компоненты в которых основная логика в зависимостях (пропсах).