Сообщение Re[17]: Про обработку ошибок - типовые решения от 28.04.2025 6:12
Изменено 28.04.2025 6:31 Быдлокодер
Re[17]: Про обработку ошибок - типовые решения
Здравствуйте, Shmj, Вы писали:
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте.
Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронное функции что-то обновится старыми данными.
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте.
Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронное функции что-то обновится старыми данными.
Re[17]: Про обработку ошибок - типовые решения
Здравствуйте, Shmj, Вы писали:
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте.
Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте.
Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.