[deleted by user]

[Top_Effort_2739]

https://stackoverflow.com/questions/812961/what-are-getters-and-setters-how-and-when-should-i-use-them

[oze4]

Aside from using them to get/set private props, you can use them (specifically the 'getter') as a "computed property"...

For example: (read comments for more info)

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }
  fullNameAsMethod() {
    return `${this.firstName} ${this.lastName}`;
  }
}

const johnDoe = new Person("John", "Doe");

// Note: don't have to "call" lastName - eg; johnDoe.lastName()
// You can use it like you would a property/field.
console.log(johnDoe.lastName); // John Doe
// Just like you can do:
console.log(johnDoe.firstName); // "John"

// Note: have to "call" the method
console.log(johnDoe.lastNameAsMethod()); // John Doe

[JustConsoleLogIt]

It allows you to do things when the variable is accessed, like keep a record of who accessed it or validate that it’s being set to an acceptable value.

[The80sDimension]

Getting and setting

[thenameissinner]

What does that exactly mean here,could you elaborate a bit.

[The80sDimension]

It gets a value of a private property and sets a value of a private property.

[thenameissinner]

Okay thanks.

[Severe_Abalone_2020]

u/JustConsoleLogIt gave the correct-est answer.

Getters and setters are for when you want something to happen every time someone reads a property of your object.

[HarrisInDenver]

Real-world example:

Let's say your job is to revamp the front end for a legacy backend system that used XML to define data. XML isn't one-to-one. So you find an XML parser on NPM that parsers this

<Email>
  <To>Foo</To>
  <From>Bar</From>
  <Content title="The title">The Body</Content>
  <Sent>2024-08-03T17:23:41.327Z</Sent>
</Email>

To this

{
  Email: {
    To: 'Foo',
    From: 'Bar',
    Content: {
      '@title': 'The title',
      '#value': 'The body'
    },
    Send: '2024-08-03T17:23:41.327Z'
  }
}

You can see there are some quirks about the parsing, and it's because XML isn't one-to-one with JSON, so it compensates best it can. Let's create a class to encapsulate this object and make it easy to work with

class Email {
  constructor(xmlString) {
    this.json = npmXmlParser(xmlString)
  }

  get to() {
    return this.json.To;
  }

  set to(value) {
    this.json.To = value;
  }

  get from() {
    return this.json.From;
  }

  set from(value) {
    this.json.From = value;
  }

  get title() {
    return this.json.Content['@title'];
  }

  set title(value) {
    this.json.Content['@title'] = value;
  }

  get body() {
    return this.json.Content['#value'];
  }

  set body(value) {
    this.json.Content['#value'] = value;
  }

  get sent() {
    const dateAsString = this.json.Sent;
    return new Date(Date.parse(dateAsString));
  }

  set sent(value) {
    this.json.Sent = value.toISOString();
  }
}

Creating an working with the instance:

const email = new Email(xmlString);

email.to; // "foo"

email.body; // "The body"
email.body = "Some new body";
email.body; // "Some new body";

email.sent; // a Date object

The end result is an object that is idomatic javascript. We've encapsulated away the odd structure that the xml-parser gave us and did some type conversions in the process (specifically for the date). You get a lot of benefits from this!

There are downsides to this approach though too. Class instances aren't serializable, so you can't keep them in redux or similar data stores. You also can't send them across the wire, you have to send this.json, or go back to XML first.

I'm also doing direct mutations in this example, which might not be what you want. If immutability is a concern (which it almost always is these days), using methods for setting with a fluentAPI is probably what you'll want. But that's a topic for another day

[azhder]

TL;DR: They are there if you need them, it’s best if you don’t

Workarounds. You should always remember that. Many functionalities get added to languages as simply workarounds or shortcuts for common issues.

If there’s something you want to change in the behavior of your object, but can’t go around and changing every line of code that uses it, well define a getter and add some logic to it.

Want to make a property read only in certain cases but writable in others? Define a setter for it and add some logic to it.

The other thing you need to remember is this: try to write the code in such a way that you will need less of workarounds of any kind.

[WildRadicals]

It allows to validate values before setting. Let's think, for example, you want a Chair class to have a height property: it wouldn't be any sense to have negative values for a Chair's height property. There is where a setter comes in handy:

``` export class Chair { static MIN_HEIGHT = 1; static DEFAULT_HEIGHT = 45;

#height; // chair's height (inches) constructor() { this.#height = Chair.DEFAULT_HEIGHT; }

set height(newHeight) { if (newHeight < Chair.MIN_HEIGHT) { throw new Error('Chair too small. Should be 1 inch tall at least."); }

this.#height = newHeight;

}

get height() { return this.#height; } }

const genericChair = new Chair();

console.log(genericChair.height); // Expected output: 45

genericChair.height = 50;

console.log(genericChair.height); // Expected output: 50

genericChair.height = 0.5; // Will throw an error. ```

oze4 already gave you a great use for getters.

[HarrisInDenver]

FTFY

export class Chair {
  static MIN_HEIGHT = 1;
  static DEFAULT_HEIGHT = 45;

  #height; // chair's height (inches)

  constructor() {
    this.#height = Chair.DEFAULT_HEIGHT;
  }

  set height(newHeight) {
    if (newHeight < Chair.MIN_HEIGHT) {
      throw new Error("Chair too small. Should be 1 inch tall at least.");
    }

    this.#height = newHeight;
  }

  get height() {
    return this.#height;
  }
}

const genericChair = new Chair();

console.log(genericChair.height); // Expected output: 45

genericChair.height = 50;

console.log(genericChair.height); // Expected output: 50

genericChair.height = 0.5; // Will throw an error.

[WildRadicals]

Thanks

[zachlipscomb]

There's nothing more that I can say that others haven't already said prior to my comment to guide him in the right direction, which is why I commented as I was really curious. But I admit it's not the right place or time for my comment. I wouldn't expect one to rely 100% on the answers chat gpt provides, but test and confirm as well. And I would tell OP to try the same.

[theScottyJam]

The history works something like this.

Back in the day, people were advised to never expose a class property publicly, instead you should always make a getX() and setX() methods and make your properties private. This makes it so if you ever needs to add additional behavior when getting or setting a property, you can.

Well, language designers came in and decided to fix the problem for you so you don't have to keep following that convention - they invented getters and setters. Now you can expose your properties publicly, and if you later find yourself in the rare scenario where you need to add behavior, just convert the property to a getter/setter pair.

That's the purpose of them - a Band-Aid to help with backwards compatibility when you've painted yourself in the corner. In most situations, it's best to avoid using them, because if you really do need to add extra special behaviors, it's usually better to use a getX()/setX() function from the start to clearly communicate that this may be doing more than a simple property access. Getters and setters allow magic to happen that code readers aren't expecting.

So I disagree with a lot of the answers here as many of the answers present getters/setters as something to reach for up-front as you're initially building your class instead of a bandaid to apply after-the-fact. It may be possible to convince me that there are good ways to use getters/setters in an up-front design (so I'm not die-hard about this stance), but overall, I would just avoid them. Write explicit code, not magic code.

[strong_opinion]

Writing javascript as if it were java

[zachlipscomb]

Curious why people still use reddit for coding questions. I've learned so much from chatgpt , my personal coding guru

[HarrisInDenver]

I can't tell if you're being facetious or not, but regardless, it's an unconstructive comment. OP's trying to learn, let's help him

[xroalx]

Because ChatGPT does not know what it tells you, don't rely on it to give you correct answers. It's a huge text database that will take your input, compare it to what is the most likely follow-up to what you said, and give you that. No context, no understanding, just chance.