Umgang mit zyklischen Abhängigkeiten in Node.js.

Ich habe in letzter Zeit mit NodeJS gearbeitet und mich immer noch mit dem Modulsystem auseinandergesetzt. Ich entschuldige mich, wenn dies eine offensichtliche Frage ist. Ich möchte Code ungefähr wie folgt:

a.js (die Hauptdatei, die mit dem Knoten ausgeführt wird)

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;

Mein Problem scheint zu sein, dass ich innerhalb einer Instanz von ClassB nicht auf die Instanz von ClassA zugreifen kann.

Gibt es eine korrekte / bessere Möglichkeit, Module zu strukturieren, um das zu erreichen, was ich will? Gibt es eine bessere Möglichkeit, Variablen zwischen Modulen auszutauschen?

Während node.js zirkuläre requireAbhängigkeiten zulässt , kann es, wie Sie festgestellt haben, ziemlich chaotisch sein und Sie sollten Ihren Code wahrscheinlich besser umstrukturieren, um ihn nicht zu benötigen. Erstellen Sie möglicherweise eine dritte Klasse, die die beiden anderen verwendet, um das zu erreichen, was Sie benötigen.

Versuchen Sie, Eigenschaften festzulegen module.exports, anstatt sie vollständig zu ersetzen. ZB module.exports.instance = new ClassA()in a.js, module.exports.ClassB = ClassBin b.js. Wenn Sie kreisförmige Modulabhängigkeiten erstellen, erhält das erforderliche Modul einen Verweis auf ein unvollständiges module.exportsModul aus dem erforderlichen Modul, zu dem Sie andere Eigenschaften hinzufügen können. Wenn Sie jedoch das gesamte module.exportsModul festlegen , erstellen Sie tatsächlich ein neues Objekt, das das erforderliche Modul nicht hat Weg zum Zugang.

[BEARBEITEN] Es ist nicht 2015 und die meisten Bibliotheken (dh Express) haben Aktualisierungen mit besseren Mustern vorgenommen, sodass zirkuläre Abhängigkeiten nicht mehr erforderlich sind. Ich empfehle sie einfach nicht zu benutzen .

Stellen Sie einfach sicher, dass Ihre erforderlichen Exporte definiert sind, bevor Sie eine Datei mit einer zirkulären Abhängigkeit benötigen.

Dies wird brechen:

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

module.exports = ClassA;

Das wird funktionieren:

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

Ich benutze dieses Muster ständig für den Zugriff auf die appDatei express.js in anderen Dateien:

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

Manchmal ist es wirklich künstlich, eine dritte Klasse einzuführen (wie JohnnyHK empfiehlt), also zusätzlich zu Ianzz: Wenn Sie die module.exports ersetzen möchten, zum Beispiel, wenn Sie eine Klasse erstellen (wie die Datei b.js in Im obigen Beispiel ist dies ebenfalls möglich. Stellen Sie einfach sicher, dass in der Datei, in der das Rundschreiben erforderlich ist, die Anweisung 'module.exports = ...' vor der Anweisung require ausgeführt wird.

a.js (die Hauptdatei, die mit dem Knoten ausgeführt wird)

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

Die Lösung besteht darin, Ihr Exportobjekt weiterzuleiten, bevor Sie einen anderen Controller benötigen. Wenn Sie also alle Ihre Module so strukturieren und auf solche Probleme nicht stoßen:

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

};

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

// Functions:
var foo = function () {

};

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

Eine Lösung, die nur minimale Änderungen erfordert, wird erweitert, module.exportsanstatt sie zu überschreiben.

a.js - App-Einstiegspunkt und Modul, die die Methode do von b.js * verwenden

_ = 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 - Modul, das die Methode do von a.js verwendet

_ = 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 
    }
})

Es wird funktionieren und produzieren:

doing b
doing a

Während dieser Code nicht funktioniert:

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();

Ausgabe:

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

Was ist mit faulen Anforderungen nur, wenn Sie müssen? Ihr b.js sieht also wie folgt aus

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

Natürlich ist es empfehlenswert, alle erforderlichen Anweisungen über die Datei zu setzen. Aber es gibt Fälle, in denen ich mir vergebe, etwas aus einem ansonsten nicht verwandten Modul herausgesucht zu haben. Nennen wir es einen Hack, aber manchmal ist dies besser, als eine weitere Abhängigkeit einzuführen oder ein zusätzliches Modul hinzuzufügen oder neue Strukturen hinzuzufügen (EventEmitter usw.)

Eine andere Methode, die ich gesehen habe, ist das Exportieren in der ersten Zeile und das Speichern als lokale Variable wie folgt:

let self = module.exports = {};

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

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

Ich neige dazu, diese Methode zu verwenden. Kennen Sie die Nachteile?

Sie können dies einfach lösen: Exportieren Sie einfach Ihre Daten, bevor Sie etwas anderes in Modulen benötigen, in denen Sie module.exports verwenden:

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();

Ähnlich wie bei den Antworten von Lanzz und Setect habe ich das folgende Muster verwendet:

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

Das Object.assign()kopiert die Mitglieder in das exportsObjekt, das bereits anderen Modulen übergeben wurde.

Die =Zuweisung ist logisch redundant, da sie nur module.exportsauf sich selbst festgelegt wird. Ich verwende sie jedoch, weil sie meiner IDE (WebStorm) hilft, zu erkennen, dass dies firstMembereine Eigenschaft dieses Moduls ist. "Gehe zu -> Deklaration" (Cmd-B) und andere Werkzeuge funktionieren mit anderen Dateien.

Dieses Muster ist nicht sehr hübsch, daher verwende ich es nur, wenn ein zyklisches Abhängigkeitsproblem behoben werden muss.

Hier ist eine schnelle Problemumgehung, die ich als vollwertig empfunden habe.

In der Datei 'a.js'

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

Schreiben Sie in die Datei 'b.js' Folgendes

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

Auf diese Weise werden bei der nächsten Iteration der Ereignisschleifenklassen korrekt definiert und die erforderlichen Anweisungen funktionieren wie erwartet.

Eigentlich brauchte ich meine Abhängigkeit von

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

nicht schön, aber es funktioniert. Es ist verständlicher und ehrlicher als das Ändern von b.js (zum Beispiel nur das Erweitern von modules.export), was ansonsten so wie es ist perfekt ist.

Eine Möglichkeit, dies zu vermeiden, besteht darin, keine Datei in einer anderen zu benötigen. Übergeben Sie sie einfach als Argument an eine Funktion, was auch immer Sie in einer anderen Datei benötigen. Auf diese Weise entsteht niemals eine zirkuläre Abhängigkeit.