NodeJS Необработанный отказ от обещания

Прежде всего, я бы сказал, что динамическое require - это способ попасть в беду. Позвольте мне структурировать свой ответ в двух частях, чтобы подчеркнуть причины, по которым его следует избегать, и предлагать несколько решений вместо этого.

Основные проблемы

1. Синхронная загрузка во время выполнения

   require - это синхронная операция, и, как мы все знаем, такие операции блокируют Event Loop. Представьте себе относительно огромное количество пользователей, потребляющих ваше приложение одновременно, и задержку цикла, которая сказывается выше разумных значений или, по крайней мере, начинает вызывать проблемы с производительностью.

2. Трудно тестировать такие динамические модули

   Как вы можете гарантировать, что ваше приложение достаточно стабильно, без надлежащего тестирования? С динамическим требованием это становится нетривиальной задачей. Это приводит к другому вопросу - действительно ли у вас такое количество моделей данных, которые они должны быть созданы и загружены динамически? А если нет, вы можете сделать вашу работу намного более комфортной с четко определенными и явно требуемыми моделями данных, а не "магической" загрузкой, подверженной ошибкам. А также не забывайте о круговых зависимостях и других ужасающих мерзостях, которые будут молчать до момента импорта.

3. Общий дизайн такого приложения

   Стоит прочитать тему ESLint для global-require и понять, почему она не разрешена в разных наборах правил по умолчанию (например, Airbnb). Но вы на самом деле упомянули о себе:

   Я сделал простой тип o в getModel(kind) и обнаружил основную проблему с нечетким обещанием.

   Если этого достаточно, чтобы разорвать ваше приложение, можно ли считать это приложение надежным? Это то же самое, что и с сырыми строками в качестве параметров: нужно скорее сделать их константами или присутствовать в качестве самой функции, избавиться от трудно отлаживаемых ошибок времени выполнения в обмен на простые синтаксические ошибки при запуске.

Возможные решения

Явно требуемые модели

Создавайте четко определенные структуры объектов, которые представляют структуры данных и загружают их явно из одного агрегированного файла index.js:

// models/transfer-request.js
class TransferRequest {
  create(instance, cb) {
    // Implementation...
  }
}

module.exports = TransferRequest;

// models/index.js
const TransferRequest = require('./transfer-request.js');
// Other models requires...

module.exports = {
  TransferRequest,
  // Other models exports...
};

Создайте экземпляры с помощью Factory:

Если вы все еще хотите придерживаться того, что у вас есть, создайте модель Factory с использованием стандартного шаблона:

class ModelFactory {
  constructor(model){
    switch(model) {
      case 'transferrequest':
        // Implementation of TransferRequest object creation...
      break;

      case 'othertransferrequest':
        // Implementation of OtherTransferRequest object creation...
      break;

      default:
        throw new Error('Unknown class');
    }
  }
}

Время и время лучше создавать реальные объекты модели четким и видимым способом, четко определенным в коде, чем скрывать возможные варианты с динамической загрузкой.

И да, если вы все еще хотите require во время выполнения, просто используйте try/catch для обработки отказов.