Ember.js: Прерванные переходы распространяют ошибку на Ember.RSVP.on ('error', ...)

@ofbriggs, я предполагаю, что этот коммит - https://github.com/emberjs/ember.js/commit/94e1035a0eb66cc4d2a6624ff2557a331524f663 около 28 дней назад обращается к поведению около TransitionAborted возможно, @chancancode или @rwjblue могут ответить на этот вопрос вопрос.

Я сомневаюсь, что моя фиксация изменила это конкретное поведение, но я лично согласен с тем, что, кажется, лучше не распространять это на RSVP, хотя я не уверен, что именно изменилось.

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

Похоже, что некоторые внутренние устройства не обрабатывают отклонение, это следует рассматривать как ошибку.

Если отклонение обрабатывается в тот же ход, оно не распространяется на on('error

Есть новости по этому поводу? Я испытал это и в Ember 2.2.0.

На данный момент я просто жестко запрограммировал имя ошибки в качестве временного решения.

export default function onServerError(cb) {
  Ember.RSVP.on('error', (reason) => {
    // An aborted transition propogates an error to RSVP
    if(reason.name !== 'TransitionAborted') {
      cb(reason);
    }
  });
}

Есть ли в этом прогресс? Мы тоже сталкиваемся с этим на Ember 2.3.

+1

Мы столкнулись с той же проблемой с нашей платформой отслеживания ошибок Sentry и решили ее с помощью обходного пути, описанного в этой фиксации . Может кому поможет :)

+1

+1

+1

Спасибо @stravid , это именно то, что мне нужно. Месяцы этой ошибки, и я наконец нашел эту ветку и ваш обходной путь после долгого гугл-фу. 🙇

Спасибо за добрые слова @devinus , постараюсь написать в блоге небольшой пост, чтобы в будущем не так уж много гугл-фу понадобилось :)

Спасибо @stravid , но это все еще не решение, возможно, мы можем добавить больше аргументов в обратный вызов ошибки, чтобы проверить, не

Я только что слил исправление в ember-cli-sentry https://github.com/damiencaselli/ember-cli-sentry/pull/67

Испытал это в Ember 2.5 (мы находимся в процессе обновления версии Ember).
На будущее я рекомендую использовать ember-cli-sentry ^.

Прежде чем мы обнаружили причину ошибки, нам даже пришлось обновить нашу подписку на охрану из-за количества ложных срабатываний ... плюс один день / вечер ...

Я также теряю время, чтобы понять, что это ложная ошибка.

использование transitionTo внутри redirect задокументировано в руководстве и в API:
https://emberjs.com/api/ember/2.18/classes/Route/methods/redirect?anchor=redirect

Тем не менее, он все равно выдает ошибку:
https://ember-twiddle.com/41c21d19e962b4981c967e46228452bb

Это сэкономило бы время многим новичкам emberjs

@chancancode или @rwjblue Планируете какие-либо изменения в этом поведении?
Мы наблюдаем это, когда у нас есть охранник в beforeModel() который переходит на другой маршрут.
Мы все еще видим его в Ember 2.16.

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @tchak , что ты думаешь?

В настоящее время я почти не использую Ember, но я полагаю, вы могли бы попытаться воспроизвести его, создав форк и обновив версию Ember?
http://emberjs.jsbin.com/wiruqobiqe/1/edit?output

Как и @bichotll , в последнее время я занимался бэкэнд-работой и больше не занимался Ember. Я позволю вам решать, что для этого подходит. :)

У меня нет возможности проверить это

Я прекратил использовать Ember, поэтому не могу подтвердить, что это все еще проблема.

Кажется, это все еще проблема: https://ember-twiddle.com/fe0e87339fd079e212d5713f5288ce58

Да, это все еще проблема (проверено с помощью ember-3.5.0).

Все еще вижу это в 3.8

Воспроизведение 3.10.0: https://github.com/robgarden/ember-transition-aborted-reproduction

+1 в 2.18.2

Для ошибок браузера это скорее проблема шума. Однако с Fastboot это становится немного сложнее, так как throw все остановит. Мне не удалось найти способ отловить эту конкретную ошибку, и я подозреваю, что проблема заключается в том, что исключение создается внутри обработчика ошибок обещания.

Из любопытства, какова ценность этого конкретного броска? Мне интересно, можно ли его удалить или обработчик ошибок можно переместить, чтобы его можно было переопределить.

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @stefanpenner @stianpr @stravid @tchak , что ты думаешь?

@pixelhandler это все еще проблема - я могу воспроизвести ее на Ember 3.8.3. Я думаю, нам следует подумать об удалении ярлыка inactive , особенно @robgarden, предоставляющего репо для воспроизведения.

Я согласен. Это очень неприятная проблема. Он также блокирует тесты, если вы проверяете, был ли переход прерван.

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

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

Во многих случаях вам следует подумать о том, куда идет пользователь, прежде чем приступить к его перенаправлению, и использовать перенаправления в крайнем случае. Я думаю, что те «ложные» ошибки, о которых сообщают, на самом деле указывают на плохой дизайн UX.

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

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

@ezpuzz Многоуровневая авторизация (не аутентификация) - это область, с которой мы всегда сталкиваемся. Мы сохраняем переход на потом, чтобы мы могли обеспечить хороший UX и облегчить разработчикам боль при реализации маршрутов. Мы не знаем, для каких маршрутов требуется повышенное разрешение, пока они не будут обнаружены, и в этом случае мы прерываем работу и запрашиваем повышенные учетные данные перед повторной попыткой. Общее заявление о том, что во многих случаях это плохой UX, неверно.

Также к сведению, эта ошибка возникает в блоке асинхронным, не выгружаются в rsvp.on ( «ошибка»

Также, если вы не переопределяете RSVP.on('error') запускается этот код, который принимает ошибку: https://github.com/emberjs/ember.js/blob/master/packages/@ember/ -internals / runtime / lib /ext/rsvp.js

@ James1x0 извините, я имел в виду, что есть полезные случаи

В этом случае мы могли бы улучшить полезность ошибки здесь: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition-aborted-error.ts

передавая дополнительную информацию о переходе здесь: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition.ts#L401

В противном случае это можно было бы проигнорировать, как упоминалось в моем последнем комментарии.