Як боротися з циклічними залежностями в 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, ви фактично створюєте новий об'єкт, якого у необхідного модуля немає спосіб доступу.

[EDIT] це не 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 - точка входу програми та модуль, який використовує метод, який виконується з 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 - модуль, метод використання якого виконується з 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();

Таким чином на наступній ітерації класів циклу подій буде визначено правильно, і ті, хто вимагає операцій, працюватимуть, як очікувалося.

Насправді я зрештою вимагав своєї залежності

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

не дуже, але це працює. Це зрозуміліше і чесніше, ніж зміна b.js (наприклад, лише розширення модулів.експорт), що в іншому випадку ідеально, як є.

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