Мне нужно сохранить порядок карточек после обновления страницы. На текущий момент бэк отдает мне карточки сортируя по важности, т.е. сначала сверху красные, потом зеленые. При изменении порядка элемента в массиве я знаю его старый и новый индекс. Теоретически, мне бы следовало завести новое значение index в БД для модели задачи и сортировать по нему. Однако возникает следующая проблема : я сделаю patch запрос и изменю Index карточки на новый, например 10. Однако в БД уже будет карточка с индексом 10, хотя по факту она или 9 или 11 ( в зависимости от того, с какой стороны дропнул). Делать patch на каждый из элементов массива выглядит тупой идеей. Что тут можно изящного изобрести?
Индекс записи в БД и индекс как порядковый номер записи в массиве js - это разные индексы в принципе и они не должны пересекаться
я ничего и не говорю про пересечение id записи в бд и некого абстрактного индекса в массиве на фронтенде
Тогда я немного не понял суть. Уточни
так круто
Сейчас бекэнд отдает мне задачи в следующем порядке '-priority'. Затем большой массив из api сортируется на 4 массива на фронте, и каждая карточка встает на свою колонку. При изменении порядка внутри колонки до обновления страницы все ок. После обновления бэк, естественно, отдает все в изначальном виде. Мне надо что-то выдумать, чтобы при обновлении страницы порядок карточек оставался.
Если у модели Task завести еще одно поле, допустим columnIndex и патчить его исходя из нового индекса внутри массива фронта, то спустя какое-то время все элементы в бд могут быть с одним columnIndex и бэк, сортируя по этому полю снова выдаст какую-нибудь ерунду
Бек не выдаёт ерунду. Бек выдаёт правильно. Это тебе в принципе надо ещё одну подсортировку по доп полю делать, которое будет учитывать твои изменения. На каком основании ты передвинул элемент в колонке выше или ниже? Как ты это событие зафиксировал для бека?
Передвинул карточку внутри столбца, поймал старый-новый индекс. Может к индексу добавлять таймштамп, и сотрировать по двум полям, сначала по Index по убыванию, потом таймштамп по возрастанию? Тогда новый элемент с Index 10 будет иметь более "свежий" таймштамп, чем старый элемент с фактически таким же index ? Хорошая мысля, кстати
Я подумал о времени, но тогда самое позднее время будет либо всегда первым, либо всегда последним
сотрировку внутри одной колонки пока для бэка никак не обозначаю. Только при перемещении между колонками патчу конкретную задачу, присваивая ей state новой колонки
Так сначала отсортирует по index, в случае совпадения наверх поставит самый новый
Уоттакуот, например. Должно ж работать по идее?
Ну такое... Тебе придётся сделать отдельно механизм консистентности, иначе будут разрывы в индексах по полю column_index при перемещениях элементов между колонками.
Обсуждают сегодня