Последствия отсутствия «тогда» или «ожидания» асинхронных функций в React / ExpressJS

Question

В нашем коде React и ExpressJS есть асинхронные функции, которые мы вызываем, но не then -ing или await -ing. Это сделано намеренно, так как они не имеют решающего значения для потока кода, и мы оптимизируем задержки пользователей. Пример того, где мы это делаем, - это когда мы отправляем телеметрические или метрические данные.

Каковы потенциальные ошибки, о которых нам нужно знать при выполнении этого? Я могу думать о следующем из головы:

• Мы не будем знать, если этот вызов не удается, так как мы не обрабатываем или не знаем о его ошибке (это нормально, если это прерывистыйнисходящая проблема)
• В связи с вышеизложенным мы не узнаем, есть ли ошибка в нашем фактическом коде
• В этом я не уверен, но может ли асинхронная функция завершиться с ошибкойесли основной поток завершен (т. е. пользователь переходит на другую страницу или сервер ExpressJS завершен?)

Есть ли другие ошибки / последствия, о которых наша команда должна знать?

Есть ли лучшие модели в достижении того же результата?

Спасибо

Answer 1

Единственным недостатком является то, что вы не можете обрабатывать ошибки в основном потоке кода. Вам нужно было бы придумать способ правильно обрабатывать ошибки и даже знать о них.

В некоторых ситуациях вы можете захотеть узнать об ошибках (при разработке / отладке) с помощью какого-либо ведения журнала, но в рабочем коде на самом деле ничего не нужно делать с ошибками, поэтому вы просто игнорируете их. В других ситуациях вам нужен какой-то способ сообщения об ошибках, даже если он не находится в основном потоке кода.

Если пользователь переходит на другую страницу, когда у вас есть асинхронная операция «в процессе», такая как Ajaxвызов с данными телеметрии, вполне вероятно, что вызов Ajax уже отправлен и просто ожидает ответа, который не причинит вреда. Данные уже отправлены.

Если целевой сервер прерван, вызов Ajax завершится неудачно (вероятно, быстро), и вы вернетесь в первую ситуацию, описанную выше (что делать с ошибками).

Есть ли другие уловки / последствия, о которых наша команда должна знать?

Только те, о которых вы упомянули, и последствия обработки ошибок, характерные для конкретной ситуации икод. Если нет ничего страшного в том, чтобы позволить сбросить данные телеметрии, если что-то пойдет не так при передаче, то все в порядке. Если важно, чтобы он доставлялся надежно, тогда вам потребуется еще много кода, чтобы повторить ошибки передачи, предотвратить переход от страницы и т. Д. ... Даже тогда пользователь все еще может закрыть браузер или окно / вкладку браузера с помощьюнет гарантий успешной передачи.

Есть ли лучшие образцы для достижения того же результата?

В общем, нет - для этого нет универсального шаблона проектирования. Нам действительно нужно увидеть общую структуру вашего кода, понять требования к надежности передачи данных телеметрии и увидеть точный код передачи и где находится ваш кодовый поток, чтобы сделать более конкретные предложения.