Ember.js: Nettoyer les URL désirées après un abandon

Je suis d'accord avec cette question. Je le vois maintenant, même si je fais un transition.abort() dans le hook willTransition de la route. L'URL reflète la page vers laquelle elle se serait rendue si la transition n'avait pas été abandonnée.

: +1:

@ ef4 J'adorerais que vous

Je peux y travailler, mais probablement pas tout de suite.

: +1: a rencontré ceci en suivant l' exemple de code willTransition dans la documentation de l'API. L'URL est modifiée même si abort été appelé.

J'ai le même problème. J'ai créé un jsbin le recréant pour les curieux: http://emberjs.jsbin.com/tijebi/1

@ ef4 prévoit toujours de regarder cela?

Désolé, il est bas sur ma liste de priorité ces derniers temps.

Pour mémoire, je viens de rencontrer le même problème

Nous nous débarrassons des URL désireuses, fermant en faveur si # 9919

Juste au cas où quelqu'un aurait toujours ce problème et aurait besoin d'une solution _droite maintenant_:

// app/routes/your-route.js

export default Ember.Route.extend({
    // ...
    actions: {
        willTransition(transition) {
            var model = this.controller.get('model');
            if (
                model.get('hasDirtyAttributes') && 
                !confirm("You're going to discard all unsaved changes. Are you sure?")
            ) {
                transition.abort();

                // Custom revert of Back button result
                var oldURL = this.router.generate(this.routeName, model);
                var newURL = this.router.location.getURL();
                if (oldURL != newURL) {
                    this.router.location.setURL(oldURL);
                }
            } else {
                return true;
            }
        }
    }
});

Je n'aime pas utiliser directement les méthodes this.router.location mais c'est comme la seule façon de le faire maintenant (pour gérer _tous les types d'emplacements_)

Je viens de mettre à jour mon jsbin de l'année dernière vers la 1.13.4 et ce problème existe toujours: http://emberjs.jsbin.com/lohekasuhu/edit?html , css, js

Je peux confirmer que c'est toujours un problème avec la version 1.13.11 également.

L'appel de abort() lors d'une transition dans afterModel entraîne la mise à jour de l'URL et l'application dans un état cassé.

Les appels transitionToRoute n'ont pas réussi à mettre à jour correctement l'itinéraire et la solution de contournement ci-dessus ne fonctionne plus car router.location n'a pas setURL méthodes getURL et setURL .

S'i mis à jour @bcardarella [jsbin à 2.5.0]. Toujours en cours.

Cela a été corrigé par https://github.com/tildeio/router.js/pull/197 (dans 2.10.0-beta.3 +).

Démo contre v2.10.0-beta.3: http://emberjs.jsbin.com/yeqisuh/1

@rwjblue Je ne suis pas sûr que cela soit encore résolu pour le cas d'abandon. Je vois ce problème en décembre 2.12.0. Lorsque je passe à une route qui est abandonnée dans le hook de modèle, l'URL reflète l'état de l'application comme si la transition n'avait pas été abandonnée. Les autres rencontrent-ils toujours ce comportement de transition#abort ?

@kanderek Oui, je viens de

Salut,
avec le 2.14 de novembre, le problème semble toujours présent

Rencontrer ce problème avec 2.11.3

J'utilise actuellement cette vilaine solution de contournement que j'ai trouvée sur stackoverflow

//right after an aborted transition
if (window.history) {
  window.history.forward();
}

S'il vous plaît ne me faites pas honte pour ça ^

+1

Je vois toujours ce problème! Je suis sur 2.12.2

Quelqu'un peut-il fournir un exemple d'échec pour cela?

@wagenet voici un exemple utilisant Ember 3.1.1:
https://github.com/btecu/ember-issues/tree/5210

@SirZach @adamreisnz @bcardarella @bschouwerwou @btecu @cibernox @dkorenblyum @ EF4 @kanderek @kanongil @kottenator @machty @mutewinter @pixelhandler @ rafael-Paiva @rwjblue @stefanpenner @wagenet @woprandi est - ce encore un problème, peut - être que nous devrions fermer ou créer une nouvelle reproduction de ceci, qu'en pensez-vous?

@btecu pourriez-vous mettre à jour votre exemple vers Ember 3.5?

+1 Se heurter à ça maintenant aussi (je pense). Dans notre cas, nous effectuons une transition vers une page, puis revenons en utilisant window.history.go (-1) - il semble simplement continuer à charger la page actuelle (terminer la transition, etc. et charger le reste du contenu asynchrone), ce qui prend un certain temps, puis finalement fait la transition en arrière. L'URL est cependant mise à jour immédiatement. Peut-être parce que nous utilisons directement l'API historique?

Je viens de vivre cela avec 3.9.1

Cette question est confuse parce que le bug d' origine sans aucun doute ne se fixe. Nous ne faisons plus de mises à jour d'URL. Je vais terminer car il y a beaucoup d'histoire non pertinente ici.

@miguelcobain si vous pouvez s'il vous plaît partager votre reproduction sur 3.9.1 comme un nouveau problème, cela l'aidera à attirer l'attention.

C'était le meilleur résultat lorsque j'ai recherché ce problème qui semble toujours être un problème, alors j'ai pensé coller un extrait de code mis à jour avec une solution de contournement pour quiconque trébucherait sur ce problème (s'il vous plaît laissez-moi savoir s'il existe une solution réelle qui Je ne suis pas au courant de):

  <strong i="6">@service</strong> router

  <strong i="7">@action</strong> 
  willTransition(transition) {
    if (!transition.to.find(route => route.name === this.routeName) && !confirm('confirm?')) {
      transition.abort()
      let oldURL = this.router.currentURL;
      let newURL = this.router.location.getURL();
      if (oldURL != newURL) {
          this.router.location.setURL(oldURL);
      }
    }
    return true;
  }

Ceci est une version simplifiée de la suggestion donnée par @kottenator ci-dessus (https://github.com/emberjs/ember.js/issues/5210#issuecomment-122033542).