Ember-Cli-Mirage в устаревшем приложении
У нас есть приложение, которое использовало Pretender для предоставления приспособлений для испытаний. Теперь мы пытаемся перейти на угасающий мир. Мы не можем перенести все приборы одновременно. Так что в основном происходит то, что мы запускаем наш собственный сервер Pretender, а ember-cli-mirage запускает его собственный. Который выдает следующее предупреждение:
Вы создали второй экземпляр Pretender, когда он уже был запущен. Запуск сразу двух серверов Pretender приведет к неожиданным результатам и будет полностью удален в будущей основной версии. Пожалуйста, вызывайте.shutdown() для ваших экземпляров, когда они больше не нужны, чтобы они отвечали.
Поскольку это всего лишь предупреждение, оно не должно быть проблемой для переходного периода. Проблема в том, что после загрузки Mirage в наше приложение старые маршруты Pretender перестают отвечать. Я думаю, что это то, что "... приведет к неожиданным результатам" относится к.
Есть ли шанс запустить ember-cli-mirage вместе с созданными вручную маршрутами Pretender? Или просто использовать сервер Mirage и вводить туда эти маршруты?
2 ответа
Я бы использовал сервер Mirage, а затем загрузил бы ваши маршруты Pretender внутри него. (Сервер Миража на самом деле просто объект, который new
с экземпляром претендента). Если люди видят mirage
папку, которую они, вероятно, ожидают, что маршруты будут определены там. Кроме того, Mirage очищает свой экземпляр Pretender во время тестирования.
В mirage/config.js
Вы можете импортировать ваши существующие маршруты Pretender и вызвать их там. Mirage имеет сахар поверх Pretender, но вы всегда можете получить доступ к базовому экземпляру Pretender через this.pretender
в пределах config
функция:
// mirage/config.js
import setupYourOldRoutes from 'somewhere';
export default function() {
this.get('users'); // new Mirage shorthand
setupYourOldRoutes(this.pretender);
}
Так setupYourOldRoutes
может быть функцией, которая принимает экземпляр претендента, а затем определяет все ваши существующие обработчики маршрутов, используя его.
На основе ответа @samselikoff я нашел решение для своего случая. У нас уже есть один центральный пункт, который занимается созданием экземпляра претендента. Таким образом, исправление состояло в том, чтобы просто передать Претендент Миража вместо создания нового:
// 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);
}
Сложно было убедиться, что initPretender()
вызывается до того, как любой из наших устаревших кодов попытается вызвать getPretender()
, Я думаю, что обычно это не проблема. В нашем случае мы залатали tests/helpers/start-app.js
так что некоторые приспособления были введены в каждом тесте. И это вызвало призыв getPretender()
слишком рано.