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() слишком рано.

Другие вопросы по тегам