Jak radzić sobie z cyklicznymi zależnościami w Node.js.

Ostatnio pracowałem z nodejs i wciąż mam do czynienia z systemem modułów, więc przepraszam, jeśli jest to oczywiste pytanie. Chcę kod mniej więcej taki jak poniżej:

a.js (główny plik uruchamiany z węzłem)

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;

Wydaje się, że moim problemem jest to, że nie mogę uzyskać dostępu do wystąpienia ClassA z poziomu wystąpienia ClassB.

Czy istnieje poprawny / lepszy sposób strukturyzacji modułów, aby osiągnąć to, czego chcę? Czy istnieje lepszy sposób udostępniania zmiennych między modułami?

Chociaż node.js zezwala na requirezależności cykliczne , jak zauważyłeś, może być dość niechlujny i prawdopodobnie lepiej będzie zreorganizować kod, aby go nie potrzebował. Może stwórz trzecią klasę, która wykorzysta pozostałe dwie, aby osiągnąć to, czego potrzebujesz.

Spróbuj włączyć właściwości module.exports, zamiast całkowicie je zastępować. Np. module.exports.instance = new ClassA()W a.js, module.exports.ClassB = ClassBw b.js. Kiedy tworzysz cykliczne zależności modułów, module.exportsżądany moduł otrzyma odwołanie do niekompletnego z wymaganego modułu, do którego możesz dodać inne właściwości, ale kiedy ustawisz całość module.exports, w rzeczywistości utworzysz nowy obiekt, którego żądany moduł nie ma sposób dostępu.

[EDYTUJ] to nie rok 2015 i większość bibliotek (np. Ekspresowych) dokonało aktualizacji z lepszymi wzorcami, więc zależności cykliczne nie są już potrzebne. Zalecam po prostu ich nie używać .

Po prostu upewnij się, że niezbędne eksporty są zdefiniowane, zanim będziesz potrzebować pliku z zależnością cykliczną.

To się zepsuje:

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

module.exports = ClassA;

To zadziała:

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

Cały czas używam tego wzorca, aby uzyskać dostęp do express.js appw innych plikach:

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

Czasami wprowadzenie trzeciej klasy jest naprawdę sztuczne (jak radzi JohnnyHK), więc oprócz Ianzza: Jeśli chcesz zamienić module.exports, na przykład jeśli tworzysz klasę (jak plik b.js w powyższy przykład), jest to również możliwe, po prostu upewnij się, że w pliku, który rozpoczyna cykliczne żądanie, instrukcja „module.exports = ...” występuje przed instrukcją require.

a.js (główny plik uruchamiany z węzłem)

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

Rozwiązaniem jest „zadeklarowanie dalej” obiektu eksportu przed zażądaniem jakiegokolwiek innego kontrolera. Więc jeśli uporządkujesz wszystkie swoje moduły w ten sposób i nie napotkasz żadnych takich problemów:

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

};

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

// Functions:
var foo = function () {

};

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

Rozwiązaniem wymagającym minimalnej zmiany jest rozszerzenie, module.exportsa nie nadpisanie.

a.js - punkt wejścia aplikacji i moduł używający metody do z 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 - moduł używający metody do z 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 
    }
})

Będzie działać i produkować:

doing b
doing a

Chociaż ten kod nie zadział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();

Wynik:

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

A co z leniwym wymaganiem tylko wtedy, gdy tego potrzebujesz? Więc twój b.js wygląda następująco

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

Oczywiście dobrą praktyką jest umieszczanie wszystkich wymaganych instrukcji na wierzchu pliku. Ale są sytuacje, w których wybaczam sobie wybieranie czegoś z niepowiązanego modułu. Nazwij to hackiem, ale czasami jest to lepsze niż wprowadzenie dalszej zależności lub dodanie dodatkowego modułu lub dodanie nowych struktur (EventEmitter itp.)

Inną metodą, którą widziałem, jest eksportowanie w pierwszym wierszu i zapisywanie jej jako zmiennej lokalnej w następujący sposób:

let self = module.exports = {};

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

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

Zwykle używam tej metody, czy znasz jakieś jej wady?

Możesz to łatwo rozwiązać: po prostu wyeksportuj swoje dane, zanim będziesz potrzebować czegokolwiek innego w modułach, w których używasz 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();

Podobnie jak w przypadku odpowiedzi Lanzza i Setecta, korzystam z następującego wzoru:

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

W Object.assign()kopiuje członków do exportsobiektu, który już został dany do innych modułów.

=Zadaniem jest logicznie zbędny, ponieważ jest po prostu ustawienie module.exportsna sobie, ale używam go, ponieważ pomaga moja IDE (WebStorm) uznać, że firstMemberjest własnością tego modułu, więc „przejść do -> Deklaracja” (Cmd-B) a inne narzędzia będą działać z innych plików.

Ten wzorzec nie jest zbyt ładny, więc używam go tylko wtedy, gdy trzeba rozwiązać problem cyklicznej zależności.

Oto szybkie obejście, które znalazłem w pełni.

W pliku „a.js”

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

W pliku „b.js” zapisz co następuje

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

W ten sposób w następnej iteracji klasy pętli zdarzeń zostaną poprawnie zdefiniowane, a te instrukcje będą działać zgodnie z oczekiwaniami.

Właściwie skończyło się na tym, że wymagałem mojej zależności od

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

nie ładne, ale działa. Jest to bardziej zrozumiałe i uczciwe niż zmiana b.js (na przykład tylko rozszerzenie modułów.export), która poza tym jest doskonała.

Jednym ze sposobów uniknięcia tego jest nie wymaganie jednego pliku w innym, po prostu przekazanie go jako argumentu funkcji, czego potrzebujesz w innym pliku. W ten sposób nigdy nie powstanie zależność cykliczna.