Next.js, optimistic UI и autosave

[Ukubona_Konke]

Хорошо, что requestId сравнивается на клиенте, а не завязано на порядок ответов - это стандартная ловушка debounce+async. Но раз уже есть activeRequestIdRef, но почему бы не пойти на шаг дальше и не отменять устаревший запрос через AbortController, а не просто игнорировать его ответ? Для мобильных сетей и не совсем маленького payload это реальная экономия трафика и меньше шансов забить соединение параллельными XHR. Технически это ложится ровно на тот же паттерн: signal в saveAutosaveLabAction, abort() в том месте, где сейчас создаётся новый requestId.

[lemon_m]

Да, для обычного fetch это хороший вариант. AbortController сократил бы лишний трафик, а requestId остался бы страховкой от ответа, который успел завершиться до abort.

Но в проекте saveAutosaveLabAction вызывается как Server Action. AbortSignal в неё напрямую не передать, аргументы action сериализуются. Отмена сетевого запроса также не гарантирует, что сервер не успел выполнить запись. Поэтому requestId решает отдельную задачу, старый ответ не меняет текущий UI. Для полноценной отмены пришлось бы вынести сохранение в Route Handler и вызывать его через fetch. В Workbench payload небольшой, поэтому работает этот компактный вариант. Для большого редактора лучше использовать оба механизма, плюс проверку версии документа на сервере