массив объектов, с дальнейшим их рендером. В спа подразумевается создание, изменение, удаление этих объектов. Какой подход наиболее корректный?
1. При загрузке объектов с сервера сохранять их в redux.
При взаимодействии с данными этих объектов/создании/удалении отправлять соответствующие запросы на сервера > успех > загружать с сервера обновленные данные
2. При загрузке объектов с сервера сохранять их в redux.
При взаимодействии с данными этих объектов/создании/удалении отправлять соответствующие запросы на сервер > успех > создать массив этих объектов с обновленными данными и диспатчить его в redux, избегая лишнего запроса на сервер (как мне кажется, на каждое изменение данных делать запрос с сервера с обновленными данными - лишнее действие).
Конечно, если есть еще более корректные варианты, с радостью приму к сведению
Получать обновлённые данные в респонсе к реквесту(возможно, я не уверен, не баньте меня)
От организации зависит. Если id генерирует фронт, то можно сразу складывать в коллекцию и если ошибка откатывать назад. Если id генерирует бэк, то безусловно забирать объект из респонса и складывать в коллекцию. Если бэк не возвращает объект, то делать перезапрос данных
Просто прикинь, что произойдёт, если один пользователь удалит сущность, а второй обновит её через пару минут?
произойдет ошибка же
а когда пользователь об этом узнает, если ты не запрашивашь данные с сервера на каждое обновление?
узнает в тот момент, когда он попытается это сделать. У меня на каждое действие идет запрос на сервер. Сохраняет изменение в объекте? put запрос, от статуса респонса уже происходит то или иное действие и тд
в первую очередь у меня идет запрос на сервер, а потом уже либо then либо catch
окей а теперь представь себе ситуацию, когда ты сидишь на работе, работаешь работу. обновляешь какую-то запись в CRMке, пыхтишь и тратишь внимание. нажимаешь “сохранить”, а тебе приложение отвечает — “не смогла, эта запись уже не существует”. после какого раза подряд ты схлопочешь нервный срыв и перестрелляешь коллег из кофемашины?
у него там как будто серверная валидация же
ну да. как только пользователь закончит работать над несуществующей записью, он сразу об этом узнает
картина смешная, ситуация страшная, как говорится) не знаю, влияет ли это, но у меня спа подразумевает работу в личном кабинете, где данные изменяет в текущий момент только один человек и на данные на сервере другой повлиять не может, для текущего пользователя
второй твой вариант называется optimistic updates (часть его — так точно), погугли в общем и целом — оба варианта верные, выбор зависит от специфики системы
спасибо большое, Дед)
Обсуждают сегодня