Ember.js: Les transitions abandonnées propagent l'erreur à Ember.RSVP.on ('error', ...)

@ofbriggs ma meilleure supposition est que ce commit - https://github.com/emberjs/ember.js/commit/94e1035a0eb66cc4d2a6624ff2557a331524f663 il y a environ 28 jours corrige le comportement autour de TransitionAborted peut-être @chancancode ou @rwjblue peut répondre à cela question.

Je doute que mon engagement ait changé ce comportement particulier, mais je suis personnellement d'accord qu'il semble préférable de ne pas le propager à RSVP, même si je ne suis pas sûr de ce qui a exactement changé.

Je suis peut-être en train de chercher quelque chose en rapport la semaine prochaine (instrumentation des routes), donc si personne d'autre ne l'a compris d'ici là, je pourrais peut-être découvrir pourquoi dans le cadre de ce travail.

Il semble que certains internes ne gèrent pas le rejet, cela devrait être considéré comme un bogue.

Si le rejet est traité dans le même tour, il ne se propage pas à on('error

Une mise à jour pour ceci? Je le vis également dans Ember 2.2.0.

Pour l'instant, je suis juste en train de coder en dur le nom de l'erreur comme solution de contournement.

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

Des progrès à ce sujet? Nous expérimentons également cela sur Ember 2.3.

+1

Nous avons rencontré ce même problème avec notre plateforme de suivi des erreurs Sentry et l'avons résolu avec une solution de contournement vue dans ce commit . Peut-être que ça aide quelqu'un :)

+1

+1

+1

Merci @stravid , c'est exactement ce dont j'avais besoin. Des mois de ce bogue et j'ai finalement trouvé ce fil et votre solution de contournement après beaucoup de Google-fu. 🙇

Merci pour les aimables paroles @devinus , j'essaierai d'écrire un petit article de blog, donc à l'avenir, il ne sera pas nécessaire de faire beaucoup de Google-fu :)

Merci @stravid , mais ce n'est toujours pas une solution, peut-être pouvons-nous ajouter plus d'arguments sur le rappel d'erreur pour vérifier si la requête du modèle échoue.

Je viens de fusionner un correctif dans ember-cli-sentry https://github.com/damiencaselli/ember-cli-sentry/pull/67

Je l'ai expérimenté dans Ember 2.5 (nous sommes en train de mettre à jour la version Ember).
Pour référence future, je recommande l'utilisation de ember-cli-sentry ^.

Avant de trouver l'origine de l'erreur, nous avons même dû mettre à niveau notre abonnement sentinelle en raison du nombre de fausses alarmes ... plus un après-midi / soir ...

Je perds aussi du temps pour comprendre qu'il s'agissait d'une fausse erreur positive.

l'utilisation de transitionTo intérieur de redirect est documentée dans le guide et dans l'API:
https://emberjs.com/api/ember/2.18/classes/Route/methods/redirect?anchor=redirect

Néanmoins, cela produit toujours une erreur:
https://ember-twiddle.com/41c21d19e962b4981c967e46228452bb

Cela ferait gagner du temps à beaucoup de nouveaux arrivants d'emberjs

@chancancode ou @rwjblue Vous envisagez de modifier ce comportement?
Nous voyons cela lorsque nous avons un garde dans un beforeModel() qui passe à une route différente.
Nous le voyons toujours sur Ember 2.16

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak problème @stianpr @stravid , Qu'est-ce que tu penses?

J'utilise à peine Ember de nos jours, mais je suppose que vous pourriez essayer de le reproduire en forçant ceci et en mettant à jour la version d'Ember?
http://emberjs.jsbin.com/wiruqobiqe/1/edit?output

Comme @bichotll , j'ai fini par faire des travaux de backend ces derniers temps et pas beaucoup plus dans Ember. Je vais vous laisser décider de ce qui est bon pour cela. :)

Je n'ai pas la chance de le tester

J'ai arrêté d'utiliser Ember, donc je ne peux pas confirmer qu'il s'agit toujours d'un problème.

Cela semble toujours un problème: https://ember-twiddle.com/fe0e87339fd079e212d5713f5288ce58

Oui, c'est toujours un problème (testé avec ember-3.5.0).

Toujours voir cela en 3.8

Reproduction sur 3.10.0: https://github.com/robgarden/ember-transition-aborted-reproduction

+1 sur 2.18.2

Pour les erreurs de navigateur, cela semble être davantage un problème de bruit. Cependant, avec Fastboot, cela devient un peu plus difficile, car le lancer arrêtera tout. Je n'ai pas été en mesure de trouver un moyen d'attraper cette erreur particulière, et je soupçonne que le problème est que l'exception est lancée à l'intérieur d'un gestionnaire d'erreurs de promesse.

Par curiosité, quelle est la valeur de ce lancer particulier? Je me demande s'il pourrait être supprimé ou si le gestionnaire d'erreurs pourrait être déplacé afin qu'il puisse être remplacé.

@Boubalou @bichotll @binoculars @bkCDL @bugduino @cbou @chancancode @devinus @dschmidt @dtropp @gertjanwytynck @ jbryson3 @jemware @olivia @remkoboschker @stefanpenner @stianpr @stravid @tchak problème @stianpr @stravid , Qu'est-ce que tu penses?

@pixelhandler c'est toujours un problème - je peux le reproduire sur Ember 3.8.3. Je pense que nous devrions envisager de supprimer inactive label, en particulier @robgarden fourni le repo pour la reproduction.

Je suis d'accord. C'est un problème très ennuyeux. Il bloque également les tests si vous testez si la transition a été abandonnée

Nos instructions catch pour les transitions susceptibles de provoquer un abandon vérifient explicitement cette erreur. Encore une douleur cependant ...

La question à laquelle il faut répondre est que si jamais nous nous soucions de TransitionAbortedError , cela peut-il arriver d'une manière dont nous voulons que l'exception soit signalée? Il peut être utile de savoir quand l'utilisateur est redirigé (il s'agit généralement d'un comportement inattendu pour l'utilisateur ou d'une mauvaise UX, l'utilisateur doit savoir où il va lorsqu'il clique sur quelque chose).

Dans de nombreux cas, vous devez tenir compte de la destination de l'utilisateur avant de le rediriger et d'utiliser les redirections en dernier recours. Ces erreurs "fausses" signalées sont en fait des indications d'une mauvaise conception UX, je pense.

Bien sûr, je suis concerné par ce problème car dans de nombreux cas, vous ne savez pas comment diriger l'utilisateur avant que le crochet de modèle ne se soit déclenché ... comme un champ ayant changé sur le backend. Il est toujours bon de donner des commentaires aux utilisateurs sur la transition au lieu de les rediriger silencieusement.

C'est pourquoi je pense que c'est une bonne chose qu'ils soient lancés, cela donne la possibilité d'alerter l'utilisateur d'une transition inattendue et de vous rappeler les endroits où votre expérience utilisateur peut être améliorée.

L' autorisation lequel nous nous trouvons toujours confrontés . Nous stockons la transition pour plus tard afin de pouvoir fournir une bonne UX et soulager la douleur des développeurs lors de la mise en œuvre des routes. Nous ne savons pas quelles routes nécessitent une autorisation élevée jusqu'à ce qu'elles soient atteintes, auquel cas nous abandonnons et demandons des informations d'identification élevées avant une nouvelle tentative. Une déclaration générale selon laquelle dans de nombreux cas, c'est une mauvaise UX est un abus de langage.

Également à noter, cette erreur est soulevée dans un bloc async, non débarquée à rsvp.on ( « erreur »

De plus, si vous ne remplacez pas RSVP.on('error') ce code s'exécute qui avale l'erreur: https://github.com/emberjs/ember.js/blob/master/packages/@ember/ -internals / runtime / lib /ext/rsvp.js

@ James1x0 désolé, ce que je voulais dire, c'est qu'il y a des cas utiles de lancement de l'exception (l'un étant l'identification des points de douleur des utilisateurs) mais l'erreur actuelle n'inclut pas assez d'informations pour le moment pour en faire un rapport de bogue utile. Dans votre cas d'utilisation, vous souhaiterez peut-être enregistrer à partir de quelle tentative de transition l'utilisateur a été invité à fournir des informations d'identification élevées et cela peut se produire à de nombreux endroits possibles dans votre application.

Dans ce cas, nous pourrions améliorer l'utilité de l'erreur ici: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition-aborted-error.ts

en passant plus sur la transition ici: https://github.com/tildeio/router.js/blob/604f7dfa246148a7737e1bb052b563c679b6d91a/lib/router/transition.ts#L401

Il pourrait être ignoré autrement, comme mentionné dans mon dernier commentaire.