ember-cli-mirage in Alt-App

Question

Wir haben Anwendung, die Pretender verwendet, um Vorrichtungen für Tests bereitzustellen. Jetzt versuchen wir, auf ember-cli-mirage zu migrieren. Wir können nicht alle Geräte gleichzeitig migrieren. Was im Grunde dort passiert, ist, dass wir unseren eigenen Pretender Server starten und ember-cli-mirage startet seinen eigenen. Whic rendert folgende Warnung:

Sie haben eine zweite Pretender-Instanz erstellt, während bereits eine ausgeführt wurde. Das gleichzeitige Ausführen von zwei Pretender-Servern führt zu unerwarteten Ergebnissen und wird in einer zukünftigen Hauptversion vollständig entfernt. Rufen Sie für Ihre Instanzen ".shutdown()" auf, wenn Sie sie nicht mehr benötigen.

Da es nur eine Warnung ist, sollte es kein Problem für die Übergangszeit sein. Problem: Sobald Mirage in unsere Anwendung geladen wird, reagieren alte Pretender-Routen nicht mehr. Ich denke, das ist, was "... zu unerwarteten Ergebnissen führt".

Sie haben die Möglichkeit, neben den manuell erstellten Pretender-Routen auch die Ember-Cli-Mirage zu verwenden? Oder einfach den Mirage Server benutzen und diese Routen dort einspeisen?

Answer 1

Ich würde den Mirage-Server verwenden und dann Ihre Pretender-Routen darin laden. (Mirages Server ist eigentlich nur ein Objekt, das new eine Pretender-Instanz hochfährt). Wenn Leute mirage Ordner sehen, würden sie wahrscheinlich erwarten, dass die Routen dort definiert werden. Außerdem räumt Mirage seine Pretender-Instanz während des Testens auf.

In mirage/config.js können Sie Ihre vorhandenen Pretender Routen importieren und sie dort aufrufen. Mirage hat Zucker oben auf Pretender aber man kann immer die zugrunde liegende Prätendenten Instanz zugreifen über this.pretender innerhalb der config Funktion:

// mirage/config.js 
import setupYourOldRoutes from 'somewhere'; 

export default function() { 
    this.get('users'); // new Mirage shorthand 

    setupYourOldRoutes(this.pretender); 
} 

So setupYourOldRoutes eine Funktion sein könnte, die eine Prätendenten Instanz nimmt und definiert dann alle vorhandenen Route Handler mit es.

Answer 2

Basierend auf @samselikoff Antwort fand ich eine Lösung für meinen Fall. Wir haben bereits einen zentralen Punkt, der die Erstellung der Pretender-Instanz behandelt. So war das Update nur statt Mirage Pretender passieren schaffen neue:

// somewhere.js 
export default function() { 
    // initPretender: function() { 
    // this.pretender = new Pretender(); 
    // } 
    initPretender: function (pretender) { 
    this.pretender = pretender; 
    }, 
    getPretender: function() { 
    return this.pretender; 
    } 
} 

// mirage/config.js 
import pretenderWrapper from 'somewhere'; 

export default function() { 
    this.get('users'); // new Mirage shorthand 

    pretenderWrapper.initPretender(this.pretender); 
} 

Tricky Teil sicher zu machen war, dass initPretender()aufgerufen wird, bevor einem unserer Legacy-Code versucht getPretender() zu nennen. I denke, normalerweise ist das kein Problem. In unserem Fall haben wir tests/helpers/start-app.js gepatcht, so dass bei jedem Test einige Fixtures injiziert wurden. Und das hat getPretender() zu früh aufgerufen.