Как бороться с циклическими зависимостями в Node.js

В последнее время я работал с nodejs и до сих пор разбираюсь с системой модулей, поэтому извиняюсь, если это очевидный вопрос. Я хочу код примерно так, как показано ниже:

a.js (основной файл запускается с узлом)

var ClassB = require("./b");

var ClassA = function() {
    this.thing = new ClassB();
    this.property = 5;
}

var a = new ClassA();

module.exports = a;

b.js

var a = require("./a");

var ClassB = function() {
}

ClassB.prototype.doSomethingLater() {
    util.log(a.property);
}

module.exports = ClassB;

Кажется, моя проблема в том, что я не могу получить доступ к экземпляру ClassA из экземпляра ClassB.

Есть ли правильный / лучший способ структурировать модули для достижения того, что я хочу? Есть ли лучший способ поделиться переменными между модулями?

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

Попробуйте установить свойства module.exportsвместо полной замены. Например, module.exports.instance = new ClassA()в a.js, module.exports.ClassB = ClassBв b.js. Когда вы создаете циклические зависимости модуля, запрашиваемый модуль получает ссылку на неполное module.exportsиз требуемого модуля, к которому вы можете добавить другие свойства, но при установке целого module.exportsвы фактически создаете новый объект, которого у запрашивающего модуля нет способ доступа.

[РЕДАКТИРОВАТЬ] это не 2015, и большинство библиотек (т.е. экспресс) сделали обновления с лучшими шаблонами, поэтому циклические зависимости больше не нужны. Я рекомендую просто не использовать их .

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

Это сломается:

var ClassA = function(){};
var ClassB = require('classB'); //will require ClassA, which has no exports yet

module.exports = ClassA;

Это будет работать:

var ClassA = module.exports = function(){};
var ClassB = require('classB');

Я постоянно использую этот шаблон для доступа к express.js appв других файлах:

var express = require('express');
var app = module.exports = express();
// load in other dependencies, which can now require this file and use app

Иногда очень сложно ввести третий класс (как советует JohnnyHK), поэтому в дополнение к Ianzz: если вы хотите заменить module.exports, например, если вы создаете класс (например, файл b.js в В приведенном выше примере) это также возможно, просто убедитесь, что в файле, который запускает циклическое требование, оператор 'module.exports = ...' происходит перед оператором требования.

a.js (основной файл запускается с узлом)

var ClassB = require("./b");

var ClassA = function() {
    this.thing = new ClassB();
    this.property = 5;
}

var a = new ClassA();

module.exports = a;

b.js

var ClassB = function() {
}

ClassB.prototype.doSomethingLater() {
    util.log(a.property);
}

module.exports = ClassB;

var a = require("./a"); // <------ this is the only necessary change

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

// Module exports forward declaration:
module.exports = {

};

// Controllers:
var other_module = require('./other_module');

// Functions:
var foo = function () {

};

// Module exports injects:
module.exports.foo = foo;

Решение, которое требует минимальных изменений, расширяется module.exports а не переопределяет его.

a.js - точка входа и модуль приложения, которые используют метод do из b.js *

_ = require('underscore'); //underscore provides extend() for shallow extend
b = require('./b'); //module `a` uses module `b`
_.extend(module.exports, {
    do: function () {
        console.log('doing a');
    }
});
b.do();//call `b.do()` which in turn will circularly call `a.do()`

b.js - модуль который использует метод do из a.js

_ = require('underscore');
a = require('./a');

_.extend(module.exports, {
    do: function(){
        console.log('doing b');
        a.do();//Call `b.do()` from `a.do()` when `a` just initalized 
    }
})

Будет работать и производить:

doing b
doing a

Пока этот код не будет работать:

a.js

b = require('./b');
module.exports = {
    do: function () {
        console.log('doing a');
    }
};
b.do();

b.js

a = require('./a');
module.exports = {
    do: function () {
        console.log('doing b');
    }
};
a.do();

Вывод:

node a.js
b.js:7
a.do();
    ^    
TypeError: a.do is not a function

Как насчет ленивых, требующих только тогда, когда это необходимо? Итак, ваш b.js выглядит следующим образом

var ClassB = function() {
}
ClassB.prototype.doSomethingLater() {
    var a = require("./a");    //a.js has finished by now
    util.log(a.property);
}
module.exports = ClassB;

Конечно, хорошей практикой является размещение всех требуемых операторов в верхней части файла. Но бывают случаи, когда я прощаю себя за то, что выбрал что-то из другого, не связанного с этим модуля. Называйте это хаком, но иногда это лучше, чем вводить дополнительную зависимость или добавлять дополнительный модуль или добавлять новые структуры (EventEmitter и т. Д.)

Другой метод, который, как я видел, делают люди, - это экспорт в первой строке и сохранение его как локальной переменной, например:

let self = module.exports = {};

const a = require('./a');

// Exporting the necessary functions
self.func = function() { ... }

Я склонен использовать этот метод, знаете ли вы о его недостатках?

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

classA.js

class ClassA {

    constructor(){
        ClassB.someMethod();
        ClassB.anotherMethod();
    };

    static someMethod () {
        console.log( 'Class A Doing someMethod' );
    };

    static anotherMethod () {
        console.log( 'Class A Doing anotherMethod' );
    };

};

module.exports = ClassA;
var ClassB = require( "./classB.js" );

let classX = new ClassA();

classB.js

class ClassB {

    constructor(){
        ClassA.someMethod();
        ClassA.anotherMethod();
    };

    static someMethod () {
        console.log( 'Class B Doing someMethod' );
    };

    static anotherMethod () {
        console.log( 'Class A Doing anotherMethod' );
    };

};

module.exports = ClassB;
var ClassA = require( "./classA.js" );

let classX = new ClassB();

Как и в ответах Lanzz и Setect, я использовал следующую схему:

module.exports = Object.assign(module.exports, {
    firstMember: ___,
    secondMember: ___,
});

В Object.assign()копирует член в exportsобъект , который уже был дан к другим модулям.

=Назначение логически излишним, так как он просто установив module.exportsдля себя, но я использую его , потому что это помогает мой IDE (WebStorm) признать , что firstMemberэто свойство этого модуля, так что «Go To -> Декларация» (Cmd-B) и другие инструменты будут работать из других файлов.

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

Вот быстрый обходной путь, который я нашел полным.

В файле «a.js»

let B;
class A{
  constructor(){
    process.nextTick(()=>{
      B = require('./b')
    })
  } 
}
module.exports = new A();

В файле «b.js» напишите следующее

let A;
class B{
  constructor(){
    process.nextTick(()=>{
      A = require('./a')
    })
  } 
}
module.exports = new B();

Таким образом, на следующей итерации классы цикла событий будут определены правильно, а операторы require будут работать как положено.

На самом деле я в конечном итоге требует моей зависимости с

 var a = null;
 process.nextTick(()=>a=require("./a")); //Circular reference!

не красиво, но это работает. Это более понятно и честно, чем изменение b.js (например, только расширение модуля. Экспорт), который в остальном идеален как есть.

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