Ember.js: Bereinigen Sie eifrige URLs nach dem Abbruch

Ich stimme diesem Problem zu. Ich sehe es jetzt, auch wenn ich einen transition.abort() im willTransition -Haken der Route mache. Die URL gibt die Seite wieder, zu der sie gegangen wäre, wenn der Übergang nicht abgebrochen worden wäre.

: +1:

@ ef4 Ich würde mich versuchen, wenn Sie die Neigung dazu haben. Ich kenne Ihr Interesse / Ihre Verfügbarkeit

Ich kann daran arbeiten, aber wahrscheinlich nicht sofort.

: +1: Dies wurde ausgeführt, wenn der Beispielcode willTransition in den API-Dokumenten befolgt wurde. Die URL wird geändert, obwohl abort aufgerufen wurde.

Ich habe das gleiche Problem. Ich habe ein jsbin erstellt, das es für Neugierige neu erstellt: http://emberjs.jsbin.com/tijebi/1

@ ef4 hast du noch vor, dir das anzuschauen?

Entschuldigung, es steht in letzter Zeit auf meiner Prioritätenliste.

Für die Aufzeichnung habe ich gerade das gleiche Problem erlebt

Wir werden eifrige URLs los und schließen zugunsten von # 9919

Nur für den Fall, dass jemand noch dieses Problem hat und eine Lösung benötigt - genau jetzt:

// 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;
            }
        }
    }
});

Ich mag es nicht, this.router.location Methoden direkt zu verwenden, aber es ist die einzige Möglichkeit, dies jetzt zu tun (um _ alle Arten von Standorten_ zu behandeln).

Ich habe gerade mein jsbin vom letzten Jahr auf 1.13.4 aktualisiert und dieses Problem besteht immer noch: http://emberjs.jsbin.com/lohekasuhu/edit?html , css, js

Ich kann bestätigen, dass dies auch mit 1.13.11 immer noch ein Problem ist.

Wenn Sie abort() einem Übergang in afterModel aufrufen, wird die URL aktualisiert und die Anwendung wird in einen fehlerhaften Zustand versetzt.

Nachfolgende transitionToRoute -Aufrufe konnten die Route nicht korrekt aktualisieren, und die oben beschriebene Problemumgehung funktioniert nicht mehr, da router.location nicht über die Methoden getURL und setURL .

Ich habe @bcardarellas [jsbin auf 2.5.0] aktualisiert. Immer noch passiert.

Dies wurde durch https://github.com/tildeio/router.js/pull/197 (in 2.10.0-beta.3 +) behoben.

Demo gegen v2.10.0-beta.3: http://emberjs.jsbin.com/yeqisuh/1

@rwjblue Ich bin mir nicht sicher, ob dies für den transition#abort ?

@kanderek Ja, ich bin gerade auf dieses Verhalten

Hallo,
Mit Glut 2.14 scheint das Problem immer noch vorhanden zu sein

Erleben Sie dieses Problem mit 2.11.3

Derzeit verwende ich diese hässliche Problemumgehung, die ich bei Stackoverflow gefunden habe

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

Bitte beschäme mich nicht dafür ^

+1

Ich sehe immer noch dieses Problem! Ich bin am 2.12.2

Kann jemand ein fehlerhaftes Beispiel dafür liefern?

@wagenet hier ist ein Beispiel mit 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 Vielleicht sollten wir dieses Problem noch schließen oder erstellen Sie eine neue Reproduktion davon, was denken Sie?

@btecu Könnten Sie Ihr Beispiel auf Ember 3.5 aktualisieren?

+1 Ich stoße jetzt auch darauf (glaube ich). In unserem Fall wechseln wir in eine Seite und kehren dann mit window.history.go (-1) zurück. Es scheint nur, die aktuelle Seite weiter zu laden (Übergang usw. abzuschließen und den Rest des asynchronen Inhalts zu laden), was dann eine Weile dauert macht den Übergang zurück. Die URL wird jedoch sofort aktualisiert. Möglicherweise, weil wir die History-API direkt verwenden?

Habe das gerade mit 3.9.1 erlebt

Dieses Problem ist verworren , weil die ursprünglichen Fehler definitiv repariert haben. Wir führen keine eifrigen URL-Updates mehr durch. Ich werde schließen, weil es hier eine Menge irrelevanter Geschichte gibt.

@miguelcobain Wenn Sie bitte Ihre Reproduktion auf 3.9.1 als neues Problem teilen können, wird dies dazu beitragen, die richtige Aufmerksamkeit zu erhalten.

Dies war das beste Ergebnis, als ich nach diesem Problem gesucht habe, das immer noch eine Sache zu sein scheint. Daher dachte ich, ich würde ein aktualisiertes Snippet mit einer Problemumgehung für jeden einfügen, der darüber stolpert (bitte lassen Sie mich wissen, ob es eine tatsächliche Lösung dafür gibt Mir ist nicht bewusst):

  <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;
  }

Dies ist eine vereinfachte Version des oben gegebenen Vorschlags von