Перезапрос моделей в ns.Update

[doochik]

Есть такой кейс.

Дано:

1. запустили апдейт
2. ушел запрос моделей на сервер
3. модели получены, все валидны

Т.к. апдейт у нас работает асинхронно, то может произойти какое-то событие между "получили модели" и "начали рисовать", которое инвалидирует часть нужных моделей. Банально, пользователь может куда-то кликнуть и привести к такой реакции. В итоге, получаем отрисовку по error-content.

У нас для этого случая была обработка: если перед отрисовкой не все данные валидны, но запрос за моделями завершился без ошибок (т.е. у моделей статус не error, а invalid), то делаем перезапрос моделей. Такое может повторяться N раз.

Кому-то это интересно?

[doochik]

Даже вот более понятный кейс.
Запрашиваем модель m1 и m2. m1 была валидна и запрашивается только m2. В момент запроса m1 была инвалидирована.
ns.request завершился удачно, но к отрисовке мы приходим с невалидной моделью

[edoroshenko]

А мы не хотим сделать, чтобы начиная с момента получения моделей, update у нас был синхронным?

[doochik]

получение моделей не может быть синхронной операцией

[edoroshenko]

а ns.request.models разве не проверит после запросов все модели? Может подумать о том, чтобы ns.request.models гарантировал валидность моделей после завершения и сам перезапрашивал, если настал второй кейс? А дальше сделать синхронный update

[doochik]

Да, тоже вариант

[doochik]

Блин, тогда стадии апдейта переедут куда-то в _requestModels, не красиво (

[chestozo]

У нас есть update._expired() и он уже где-то используется.
Может нам стоит этот флаг везде (на всех стадиях) проверять и перезапускать update?

[doochik]

Кажется, что правильно проверять валидность в районе _updateDOM, т.е. непосредственно перед началом синхронной отрисовки

[chestozo]

Согласен, перед рендерингом можно проверить, а как отрендерили - уже всё равно.
Не разорвало бы только async update-ы :)

[edoroshenko]

Ну если между sync и async update'ом модельку сломают, то async отрисует errorContent

[doochik]

Пробный фикс #466