Why are no constants used in Node.js events?

Question

I am new to node, but I am from extensive programming experience. Everywhere I looked (both in textbooks and in the production code that I saw), the vast majority of people use hard-coded strings instead of constants to identify events.

I chose one random example from npm, which is most dependent on the list of packages, to illustrate what I mean: the "query" library - why they emit and consume the "data" event by entering the string 'data' each time, instead of defining permanent library?

Using constants will be considered good practice in any programming language that I know of, and yet the node developers seem completely pleased with the hard-coded approach. Why?

Answer 1

Because this does not work for Node.js due to the dynamic nature of JavaScript.

Suppose the module defines the constant data . Then he will need to export this as part of his event-generating API. Sort of:

 const data = 'data'; class Api extends EventEmitter () { constructor () { setTimeout(() => { this.emit(data); }, 2 * 1000); } } module.exports = { data, Api }; 

Then from the outside we will have something like:

 const foo = require('./foo'); const { Api, data } = foo; const api = new Api(); api.on(data, () => { // ... }); 

Basically, something like this. Now, what if you made a mistake at the beginning of data ? What if instead

 const { Api, data } = foo; 

you are mistaken:

 const { Api, data } = foo; 

This will work without errors. data will only be undefined . You will not get an error in JavaScript when you try to access an object that does not exist, you will simply return undefined .

So, you will not get a compiler error, but now you are emitting (under the hood) data, but what you are listening to is undefined . The constant does not help in any way, you still need to make sure that you are not mistaken in the name.

And this is no better or worse than using a string where you are not allowed to make any mistakes.

So, in order to shorten the long story, constants do not improve the situation, they simply lead to a larger typing and complicate the situation, but they do not solve any real problems.

Answer 2

The short answer is that strings are the best constants available for JavaScript. Hiding them behind some static library variable does not make the developer code more subtle, readable (my opinion) or executor; therefore, it never became a popular convention.

---

Fragility

Your question seemed to imply that hard-coded strings are somehow more "fragile" than using variable constants. However, I would say that this is true only when it is expected that the “constant” will change over time, and this is unlikely to apply to any type of event, because Node.js libraries (and browser APIs) also tend to maintain some degree of backward compatibility between releases. In addition, the likelihood that someone will make a mistake in a variable is the same as when using a hard-coded string, because JavaScript does not have a check on the lifetime of an object or anything else. No guarantees are made in any way.

---

Additional context

You may have noticed that JavaScript does not have an enum type, which is annoying in many ways.

Older APIs used integer values ​​to populate this void in the language, similar to how people used it in Java. For example, Node#nodeType and XMLHttpRequest#readyState are intended to be used as follows:

 var node = document.createTextNode('') console.log(node.nodeType) //=> 3 console.log(node.nodeType === Node.TEXT_NODE) //=> true var xhr = new XMLHttpRequest() console.log(xhr.readyState) //=> 0 console.log(xhr.readyState === XMLHttpRequest.UNSENT) //=> true 

This design pattern began to be considered archaic over time, because people understood (as it was in Java) how little information that a number like 4 gives when printing in error and not in the name of the semantic UNSENT property.

The best available alternative in JS was and remains a string of values. Modern APIs such as fetch() use them quite often to pass meaningful configuration parameters to each method.

The JS community seems to be leaning toward this approach over time, and I think there are some very good reasons for this. However, when you get a more traditional programming background (especially familiarity with strongly typed languages), it may take a little time for you to feel comfortable with this approach. Just keep an open mind and read as many books in this language as possible.