Здравствуйте, Shmj, Вы писали:


S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?

Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.

Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.

Здравствуйте, Shmj, Вы писали:


S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?

Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.

Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.
И про это тоже Sinclair в начале ветки писал.
В целом ваша дискуссия похожа на разговор опытного архитектора с начинающим программистом. Лучше сосредоточиться на том, чтобы подумать, как реализовать то, о чем говорит опытный архитектор, вместо того, чтобы загружать его вопросами кодирования, как написать асинхронный обработчик.