Лучшие практики для внедрения перехватчиков в Аурелии

Question

Каков рекомендуемый (общий) подход для реализации логики перехватчика в Аурелии?

Aurelia doc сообщает следующее для метода запроса выборки перехватчика:

request [метод] принимает запрос, который будет передан window.fetch() после запуска перехватчиков. Он должен вернуть тот же запрос или создать новый. Он также может вернуть ответ, чтобы замкнуть вызов функции fetch () и немедленно завершить запрос. Ошибки, сгенерированные в перехватчиках запросов, будут обрабатываться перехватчиками requestError.

Имея это в виду, давайте рассмотрим 3 примера использования:

1. Добавьте некоторую информацию к выполняемому запросу, например, маршрут, по которому этот запрос был инициирован.

   request(requestMessage) {
       requestMessage.urlHash = window.location.hash;
   
       return requestMessage;
   }
   

   a) Это хороший подход, чтобы добавить некоторые данные в объект конфигурации requestMessage - изменить текущую конфигурацию и вернуть ее?

   б) Может быть, лучше вернуть новый объект, содержащий конфиг, поэтому requestMessage является неизменным? Что-то вроде кода ниже. Я полагаю, что fetch не будет работать с пропущенным объектом вместо самого requestMessage.

   return { 
       request: requestMessage,
       urlHash: window.location.hash,
       someOtherData: data
   };
   

2. Отклонить запрос до его создания, т.е. истек срок действия пользовательского токена, поэтому нет необходимости выполнять запрос, который не будет выполнен на стороне API и просто отклонит запрос.

   request(requestMessage) {
       if (authenticationService.isTokenExpired()) {
           requestMessage.tokenExpired = true;
   
           // We can use reject or throw here
           // Let's be explicit and return promises as applying interceptors logic
           // is based on promise chaining
           return Promise.reject(requestMessage); 
       }
   
       return Promise.resolve(requestMessage);
   }
   

   a) В этом случае те же вопросы, что и выше, рекомендуется ли изменить requestMessage, чтобы добавить некоторые данные в отклоненный запрос? Может быть, мы должны вернуть пользовательскую ошибку здесь в отклоненном обещании, что-то вроде нового TokenExpiredError(requestMessage)?

   б) Это хорошо, чтобы вернуть другой объект в отклоненном обещании? Например:

   return Promise.reject({
       request: requestMessage,
       error: new TokenExpiredError('User token expired!')
   }); 
   

3. Пример использования такой же, как в пункте 1, но давайте рассмотрим метод перехватчика ответа. Логика заключалась бы в блокировании запроса, который был сделан по другому маршруту (фрагмент хеша) и был разрешен в текущем маршруте - в основном разрешен после перехода к новому маршруту.

   response(responseMessage) {
       const currentUrlHash = window.location.hash;
       const requestMessage = responseMessage.requestMessage;
   
       if (requestMessage.urlHash !== currentUrlHash) {
           responseMessage.blockedRequest = true;
   
           return Promise.reject(responseMessage);
       }
   
       return Promise.resolve(responseMessage);
   }
   

   а) Как решить этот случай, когда мы используем информацию, установленную до того, как был сделан запрос?

   б) Где разместить такие данные?

   c) Как справиться с блокировкой, возможно, будет достаточно отклонить пользовательскую ошибку, например, новый BlokedReuqestError(responseMessage)?

И последнее: как возвращение пользовательского объекта из метода перехватчика (не запроса или ответа) может повлиять на перехватчик по умолчанию, добавленный с использованием стандартной конфигурации - rejectErrorResponses?

Заранее спасибо за любые советы и предложения:)