Почему redux лежит на плечах фронтендера, когда это работа бэкэндера?

Question

[Вика Мармеладка]

Я знаю что такое redux, и зачем он нужен и даже как он работает. Но ей богу я не могу понять, почему то что хранит данные находиться на стороне фонта, когда все что хранит данные это дело бэка? Я использую React

Comments

[Владислав Лысков]

ты не прав

[0xD34F]

Я знаю что такое redux

Не знаете. Знали бы - не стали бы задавать такой вопрос.

[Вика Мармеладка]

0xD34F, Согласен, тогда не могли бы пояснить не знающему?

[Василий Банников]

Рич Пиана, просто загугли, чтот такое "менеджер состояния" и сравни как будет выглядеть приложение с ним и без

[Sun_Day]

Рич Пиана, когда юзер находится в вашем веб приложении, он создает определенные действия. Действия связаны с состоянием. А redux это набор утилит для глобального хранения состояния(state) в приложении.
Таким образом, вы создаете какие-то объекты и они меняются в зависимости от состояния. Пользователь это видит как некие различные реакции на его действия.

[Вика Мармеладка]

Sun_Day, А почему эти данные просто сразу не отправлять на бэк?

[Sun_Day]

Рич Пиана, потому что они там не нужны

[Вика Мармеладка]

Sun_Day, Че то вроде начинаю догонять.... А какие данные можно хранить в состоянии? Можете привести примеры пожалуйста?

[Вика Мармеладка]

Sun_Day, Если отправка сообщения или подписаться на рассылку например. Это те данные которые точно должны отправляться на сервер, тогда что можно закинуть в состояние?

[Sun_Day]

Рич Пиана, любые жаваскриптовые. В redux - в особенности если они могут понадобиться в других компонентах приложения, иначе можно локальным состоянием компонента воспользоваться, используя state хуки, к примеру.
Массив картинок, размер страниц, статус получения данных, размер шрифта и т.д.

[Вика Мармеладка]

Sun_Day, Тогда получается все данные с бэка будут находиться в состоянии (редакс) а после, компоненты будут брать из состояния данные так?

[Sun_Day]

Рич Пиана, ну да, но в стор их еще нужно положить(задиспатчить). Под эту цель, для redux'а есть middleware: thunk или saga - для асинхронного получения данных с сервера и складывания в стор.

[Вика Мармеладка]

Sun_Day, Поняяял наконец, спасибо! Не могли бы тогда в ответы кинуть первый ваш коммент я его отмечу

[Sun_Day]

Рич Пиана, кинул

Answer 1

[Sun_Day]

Когда юзер находится в вашем веб приложении, он создает определенные действия. Действия связаны с состоянием. А redux это набор утилит для глобального хранения состояния(state) в приложении.
Таким образом, вы создаете какие-то объекты и они меняются в зависимости от состояния. Пользователь это видит как некие различные реакции на его действия.

Answer 2

[Василий Банников]

Redux хранит не данные. Redux хранит состояние приложения, причём именно его фронтовой части. Вот по этому redux и подпадает под ответственность фронтендера

Comments

[Вика Мармеладка]

А зачем тогда вообще хранить там данные, если они уже прилетели с бэка? Зачем этот посредник?

[Василий Банников]

Рич Пиана, если вы задаёте такой вопрос - значит вам пока редукс не нужен (Если вы действительно его знаете).

Предлагаю вам попробовать реализовать большое приложение на реакте с глобальным состоянием без редукса или другого менеджера состояния.

Если у вас получится - скорее всего вы изобретете свой редукс

[WbICHA]

Рич Пиана, эммм... А зачем ты хранишь в редаксе данные, прилетевшие с бека?

[Василий Банников]

Рич Пиана, кек. Я уже нашёл ответ на такой вопрос тут.
Насколько вообще нужны менеджеры состояний?

[Василий Банников]

WbICHA, а куда их ещё девать по твоему?

[WbICHA]

Василий Банников, я так понял автор тупо берёт и все данные, пришедшие с сервера, сначала пихает в редакс, а потом из него же берёт и обрабатывает.

[Владимир Коротенко]

Рич Пиана, потому что это отдельное приложение. Например у вас есть компонент списка файлов, а есть бредкрамп, и панель команд. И все это связано. Список файлов отправляет выделенные элементы, бредкрамп показывает кнопку удавления, любой запрос к бэку показывает лоадер, и все это завязано на стор. И вам не нужно протаскивать зависимости только подписаться на стор

[Вика Мармеладка]

WbICHA, ну да, а куда мне еще их девать, сразу обрабатывать? Ну хорошо, тогда это классический ассинхрон и зачем тогда опять же нужен тут редакс

[Василий Банников]

Рич Пиана, ну смотри например:
Загрузил я данные от бэка, отобразил в табличке.
На строки этой таблицы можно нажимать - тогда открывается модальное окно, где я могу более подробно это всё отредактировать.
При этом у моего приложения есть несколько вкладок.
Данные меняются не очень часто.

Мне что на каждый клик получается надо запрос новый делать? Тогда половину времени пользователь будет видеть не данные (которые я блин уже загрузил), а спиннеры.

[Вика Мармеладка]

Владимир Коротенко, То есть получается я правильно делаю как написал выше. Я получаю данные с бека, кидаю и в редакс, и лишь потом с радекса мои компоненты работают с данными?

[Василий Банников]

Рич Пиана, сорян, промахнулся с ответом. Хотел ответить WbICHA

[Василий Банников]

Рич Пиана, ну я так делаю, да. Какое у вас приложение - я не знаю. В вашей ситуации может можно и без редакса.
У меня лог в редаксе выглядит как-то так:

REQUEST_DATA // Это вызывается компонентом.
DATA_LOADING // redux-saga сразу же запускает спиннер и делает запрос
DATA_LOADED // Когда запрос выполнился - результат кладётся тут. Спиннер убирается
CHANGE_DATA // Это посылает компонент для редактирования
CHANGE_DATA
CHANGE_DATA
SAVE_CHANGES // Это вызывает кнопка сохранения
CHANGES_SAVING // Снова redux-saga отправляет данные
CHANGES_SAVED // Данные успешно сохранились.

Но вообще мне больше нравится effector - у него логика работы похожа на redux, но он сильно удобнее, с ним меньше бойлерплейта получается.

[Вика Мармеладка]

Василий Банников, Тогда получается я правильно понимаю, вот так?

[Василий Банников]

Рич Пиана, нет.

Фронтенд просто не может сам взаимодействовать с базой данных.
А редукс тем более не может сам в себя данные положить и выложить.
Редукс - это коробка, в которую можно класть данные, а потом вытаскивать.

[Вика Мармеладка]

Василий Банников, Так а куда тогда данные прилетают из бэка, они же не будут прям сразу в компоненты влитатать, она сначала в состояние поступят

[Василий Банников]

Рич Пиана, данные тоже не сами прилетают. Их надо запросить сначала.
Запрос обычно делается из компонента или из saga, а там уже складываются в стор при помощи action-ов.
Или не складываются - тогда это будет внутреннее состояние компонента.

[Вика Мармеладка]

Василий Банников, погоди почему данные должны запрашиваться с компонента, в компоненте должен вызываться редюсер который находиться в сторе, а тот в свою очередь и меняет данные стейта

[Василий Банников]

Рич Пиана, ну я это и имел в виду.

[WbICHA]

Мне что на каждый клик получается надо запрос новый делать?

Василий Банников, зачем? В данном примере ты сначала получаешь данные, обрабатываешь их, нужное сохраняешь в редаксе.
Впрочем, в приведённом примере, имхо, ничего не мешает хранить все данные в родительском компоненте в стейте и передавать ссылку на объект / массив пропсами. Хотя тут, конечно, надо смотреть, если слишком далеко прокидывать пропсами, то да, редакс будет предпочтительнее.

[WbICHA]

Ну хорошо, тогда это классический ассинхрон и зачем тогда опять же нужен тут редакс

Рич Пиана, дык он нужен тогда, когда без него не обойтись или когда он сильно упрощает жизнь.
Всё зависит от конкретной задачи.

[Василий Банников]

WbICHA, это я и подразумеваю под обычным использованием редакса, да.