How to avoid a functional cyclic dependency in JavaScript?

Question

There's a particular JavaScript pattern that has always bothered me, and I never really figured out the proper way to solve it. Instead I usually just ignore it because 99% of JavaScript interpreters support function hoisting so no run-time errors arise.

Consider the following:

function onOpen()
{
    console.log("Connected!");
    ws.removeEventListener("open", onOpen);
    ws.removeEventListener("error", onError);
}

function onError()
{
    console.log("Failed to connect!");
    ws.removeEventListener("message", onMessage);
    ws.removeEventListener("error", onError);
}

var ws = new WebSocket("...");
ws.addEventListener("open", onOpen);
ws.addEventListener("error", onError);

In this code, within the onOpen function, I'm referencing onError before onError has been defined lower in the code. This isn't actually a problem, because the onOpen method won't run until after onError has been defined, but it's still bad practice and trips up ESLint's no-use-before-define rule

In a more general sense, this is an error that will arise whenever two functions exist that each need to reference each other:

function a(x) {
    return x === 1 ? b(x) : 2;
}
function b(x) {
    return x === 2 ? a(x) : 1;
}

Is there a design pattern for eliminating this circular dependency? In my simple generic example the easy solution is "only have one function":

function a(x) {
    return x === 1 ? 1 : 2;
}

However when binding event listeners this doesn't always seem possible.

I don't want to get into a religious war, but… some eslint rules are not worth it. Relying on function hoisting is not a bad practice, especially in this case I'd say it is perfectly good and readable JavaScript, and you're wasting your time trying to work around a non-issue. — Touffy
– Touffy, Commented Dec 18, 2018 at 18:05
BTW, some recursive functional patterns need function hoisting. Enforcing that eslint rule simply makes your code less expressive, not better. — Touffy
– Touffy, Commented Dec 18, 2018 at 18:07
And finally, contrary to what you imply, function hoisting does allow you to actually call the function "before" (lexically) its declaration. As long as you don't redefine the same function multiple times or shadow the same identifier (and useful eslint rules should easily prevent that), there is no way to create a bug because of function hoisting. — Touffy
– Touffy, Commented Dec 18, 2018 at 18:13
"99% of JavaScript interpreters support function hoisting" - uh, if it doesn't support declarations then it's not a JavaScript interpreter. — Bergi
– Bergi, Commented Dec 18, 2018 at 19:41

Bergi · Accepted Answer · 2018-12-18 19:53:58Z

3

It's still bad practice and trips up ESLint's no-use-before-define rule

No, it's not a bad practice, it's very much a necessity. It is the preferred pattern when you have a circular functional dependency. Configure your ESLint accordingly (with { "functions": false }).

Is there a design pattern for eliminating this circular dependency?

Not really. There are several workarounds however, such as declaring the function up-front with a var (which is enough to make ESLint happy). Alternatively, you could pass a reference to the function around via parameters:

function _a(x, f) {
    return x === 1 ? f(x) : 2;
}
function b(x) {
    return x === 2 ? _a(x, b) : 1;
}
function a(x) {
    return _a(x, b);
}

Other crazy hacks with closures, following up on the Y combinator idea, are imaginable. This is not really suitable for your event listener scenario though.

answered Dec 18, 2018 at 19:53

Bergi

671k162 gold badges1k silver badges1.5k bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

stevendesu Over a year ago

I guess the reason I think it's bad practice is because in many other languages (for instance, in C++) you at least have to provide function signatures before you use them, even if the implementation comes later. That said, this is less of a "I can't do my job because ESLint is mad" and more of a "The fact that ESLint has a rule against this suggests there's a workaround, but I could never figure out what it was"

Bergi Over a year ago

@stevendesu That many other (older) languages have a deficiency doesn't make this bad practice :-) Most modern languages do not require forward declarations.

Alex Yokisama · Accepted Answer · 2018-12-18 17:57:31Z

2

I don't think this is a real problem, because usually everything works fine. Also you worry about the fact that you mention onError before it is declared, but you don't care about mentioning ws. But if yous still need to solve this, I hope this approach will do the work.

var eventListenerListOnOpen = [];
var eventListListenerOnError = [];
var eventListListenerOnMessage = [];

var ws;

function removeListedEventListeners(object, eventName, eventListenerList) {
  eventListenerList.forEach(function(listener) {
    object.removeEventListener(eventName, listener);
  });
}

function onOpen() {
  removeListedEventListeners(ws, "open", eventListenerListOnOpen);
  removeListedEventListeners(ws, "error", eventListenerListOnError);
}

function onError() {
  removeListedEventListeners(ws, "message", eventListenerListOnMessage);
  removeListedEventListeners(ws, "error", eventListenerListOnError);
}

ws = new WebSocket("...");
ws.addEventListener("open", onOpen);
eventListenerListOnOpen.push(onOpen);
ws.addEventListener("error", onError);
eventListenerListOnError.push(onError);

answered Dec 18, 2018 at 17:57

Alex Yokisama

1,0417 silver badges8 bronze badges

1 Comment

stevendesu Over a year ago

Nothing really prevents moving my instantiation of ws above the function definitions. That was just an oversight as I scribbled down the question. That said, I really like this answer since it provides a generic solution that could be applied in alternate scenarios, and actually looks like a design pattern.

Collectives™ on Stack Overflow

How to avoid a functional cyclic dependency in JavaScript?

2 Answers 2

2 Comments

1 Comment

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

2 Comments

1 Comment

Your Answer

Sign up or log in

Post as a guest

Linked

Related