вчерашнего вопроса об optimistic update. Основная проблема, на которой можно рассмотреть остальные случаи - ситуация, когда я создаю объект и начинаю редактировать на фронте, но на бэке его ещё не существует. Я правильно понимаю, что разумно при создании объекта присваивать uuid/nanoid. После чего я жду появления реального id и как только он появился - отправляю текущее состояние объекта. На практике у меня два разных action, которые я дёргаю в компоненте. Один вызывается если id ещё нет, другой, если id получен. Верно?
Как вариант, вы можете использовать сгенерированный uuid как id объекта и на бэкенде тоже.
А нельзя дождаться, пока объект создастся, а потом уже отправлять запрос на редактирование? Типа если объект ещё не создался, то ставить в очередь на ожидание
Будет слишком грустно для пользователя
Разумно. Спасибо. Ход мыслей в целом верный? Подобное поведение делается таким образом?
Почему? Вы не рассматриваете вариант, когда на бэке случится ошибка в процессе создания и пользователь узнает об этом после создания и редактирования и потеряет наработки?
Рассматриваю, конечно. И каждый случай обрабатываю. Таблица, которую нужно редактировать. Если ждать создания каждой строки (как обьекта), то выходит слишком неудобно
Это сложная тема. По возможности стоит избегать состояния eventual consistency между клиентами и сервером. Но если это невозможно, то гуглите на тему CRDT. Такие решения используют в collaborative editing и подобных задачах. Возможно, для ваших задач это излишне, но это вам виднее.
У меня к счастью вопрос в collaborative editing пока не стоит. Слабая согласованность возникать может, но не очень часто. За CRDT отдельное спасибо!
Она у вас возникает в тот момент, когда вы на клиенте создаете объект, а на сервере он еще не создан. Если вы даете возможность редактировать этот объект, не получив ответ от сервера - то число возможных конфликтов возрастает. И чем дальше - тем больше их будет и тем сложнее ими будет управлять. Я бы провел где-то границу допустимого.
Обсуждают сегодня