LI
Проектирование бд всегда основывается на бизнес требованиях
Size: a a a
2021 June 16
AA
а их надо тоже хранить с нормальной структурой, как и всю логику приложения. Нет силвер буллета на все, невозможно большое приложение сделать простым
AF
Потому что есть идея, что пользовательское состояние терять нехорошо
LI
Смотря что за состояние
AA
его еще бывает и в локальный сторэдж надо записывать и в апи отправлять на сохранение
AF
Например, если он что-то там заполнял, потом ушёл, потом передумал и вернулся, вот тут и было бы неплохо дать ему возможность продолжать с того же места. Но да, это в конкретных случаях надо решать, что нужно, а не вообще.
LI
Кидаем в некий буффер. Потом достаём
AA
буффер - стейт менеджер например =)
LI
Тянуть такое в глобалку....
LI
Да и тем более переиспользуемость падает
AF
вот этого не надо. Это уже воркараундить вокруг конкретной задачи. А воркараунды не нужны. Если по приложению выходит, что форма в нём существует логически, даже когда не существует визуально — то эту задачу и нужно решать, а не симптомы лечить.
AA
ну оно вообще то так и должно быть. Контроллер ничего не должен знать о том, откуда данные приходят и куда сохраняются. Бизнес логика тоже. Она только отправляет данные в некую структуру и берет из нее. Отдельный слой
LI
Так я про состояние формы
LI
LI
Есть даже отдельный паттерн. Снимок вроде называется
AF
Видел я людей, которые героически решали задачу "сохранять некоторые данные между сессиями" через Джсон.стрингифай локалСторадж.сетИтем/локалСторадж.гетИтем Джсон.парс на каждых записи/чтении этих данных в реакте
LI
Мдэ
LI
Жоска
AA
о, я как то base64 картинку засунул в редукс 👬
LI
ЕВГЕНИАЛЬНО