What are "class fields" in JavaScript?

Question

I was reading about JavaScript classes, and came across this term "public class fields syntax". On digging a bit deeper into it I came across this Babel's documentation on class properties.

Can someone please explain - implementation-wise what are the use-cases for this new syntax? (What solutions/benefits does it offer to JavaScript, which were missing so far?)

Here's an example below (ran without errors in Google Chrome):

class Person {
    firstName = "Mike";
    lastName = "Patel";
    
    // this is a public class field syntax
    getName = () => {
      return this.firstName + " " + this.lastName;
    };
}

var p = new Person();

console.log(p.firstName); // Mike
console.log(p.lastName); // Patel
console.log(p.getName); // () => { return this.firstName + " " + this.lastName; }
console.log(typeof p.getName); // function
console.log(p.getName()); // Mike Patel

Answer 1

Simply put, the reason to use this is ease of understanding the code. Without class field declarations, you would do something like:

class Person {
  constructor() {
    this.firstName = "Mike";
    this.lastName = "Patel";

    this.getName = () => {
      return this.firstName + " " + this.lastName;
    };
  }
}

var p = new Person();

console.log(p.firstName); // Mike
console.log(p.lastName); // Patel
console.log(p.getName); // () => { return this.firstName + " " + this.lastName; }
console.log(typeof p.getName); // function
console.log(p.getName()); // Mike Patel

This works but now you have both the callable getName() and the rest of the plain instance properties all collected in the constructor. You could have even more which means that your class definition would look rather meaningless overall:

class MyClass() {
  constructor(someArg) {
    this.foo1 = 1;
    this.foo2 = 2;
    this.foo3 = 3;
    this.foo4 = someArg;

    this.bar1 = () => {}
    this.bar2 = () => {}
    this.bar3 = () => {}
    this.bar4 = () => {}
  }
}

and so on. Again, everything is in the constructor. If you have a lot of code, it becomes harder to read what is what. And if the constructor takes any arguments, then you have the extra overhead of keeping track of those. Therefore, it is hard to read, hard to maintain, all for no real benefit. You are stuffing everything in the same place.

With class field declarations, you separate them and you get

class MyClass() {
  /* properties - do not depend on the constructor*/
  foo1 = 1;
  foo2 = 2;
  foo3 = 3;
  foo4; /* this is a property that this class will have - 
          I do not need to look at the constructor to know about it */

  /* easy to see what the constructor does that is only about *constructing* the object */
  constructor(someArg) {
    this.foo4= someArg;
  }

  /* callable field are separated from the rest of the simple properties and construction logic */
  bar1 = () => {}
  bar2 = () => {}
  bar3 = () => {}
  bar4 = () => {}
}

So, all in all, it is not revolutionary but it is slightly nicer syntax that makes it easier to express what a class has.

Answer 2

To quote from the class fields proposal

By declaring fields up-front, class definitions become more self-documenting; instances go through fewer state transitions, as declared fields are always present.

The introduction of class fields also allows for private class fields, which also come with a few benefits:

By defining things which are not visible outside of the class, ESnext provides stronger encapsulation, ensuring that your classes' users don't accidentally trip themselves up by depending on internals, which may change version to version.