A class instance is passed to `JSON.stringify` and the class's getters and methods are missing from the output, while the constructor-assigned fields are there. Explain the enumerability rule behind that, and how you would get a computed value into the JSON.

## The rule, stated exactly When `JSON.stringify` serializes an object it takes that object's **own, enumerable, string-keyed** properties, in the standard own-key order. Three filters, and a class instance fails two of them for everything declared in the class body. ```js class User { constructor(first, last) { this.first = first; this.last = last; } get fullName() { return `${this.first} ${this.last}`; } greet() { return `hi ${this.first}`; } } const u = new User('Ada', 'Lovelace'); Object.keys(u); // ["first", "last"] JSON.stringify(u); // {"first":"Ada","last":"Lovelace"} ``` - `first` and `last` were created by plain assignment in the constructor: **own** and **enumerable**. They serialize. - `fullName` and `greet` were declared in the class body, so they live on `User.prototype`: **not own**. They also carry `enumerable: false`, so even asking `Object.keys(User.prototype)` returns `[]`. They fail twice. ## The important distinction candidates get wrong The common wrong answer is "JSON.stringify can't serialize getters" or "functions are dropped". Neither is the real rule. An accessor defined on the **instance itself** with `enumerable: true` is serialized, and the getter is invoked to produce the value: ```js const o = {}; Object.defineProperty(o, 'computed', { get: () => 42, enumerable: true }); JSON.stringify(o); // {"computed":42} ``` So accessors are not special-cased at all. What was special about the class case is **where the accessor lives**. Functions *are* dropped — a function-valued own enumerable property is omitted from an object — but that is a separate rule about unsupported value types, not the reason class methods vanish. ## The other invisible categories The same own-and-enumerable filter explains a family of related surprises in one go: - **`Object.defineProperty` defaults.** Every descriptor flag you omit defaults to `false`, so `Object.defineProperty(obj, 'x', { value: 1 })` creates a non-enumerable property. It reads back fine, it just never serializes and never appears in `Object.keys`. - **Symbol keys.** Never string-keyed, therefore never serialized. Useful when you deliberately want state that does not travel. - **Private `#` fields.** Not properties at all, so no enumeration API sees them and JSON never contains them. - **Inherited data.** An object created with `Object.create(defaults)` serializes only its own overrides; the defaults sitting on the prototype are silently absent — a genuinely nasty one when a config object is built that way. ## Diagnosing it in production The reported symptom is usually "the API response is missing a field" or "`{}` came back from an object that clearly has data". The three-step triage: 1. `Object.keys(value)` — if it is empty or short, the data is not own-enumerable. 2. `Reflect.ownKeys(value)` — this adds non-enumerable and symbol keys, which distinguishes "hidden on the object" from "not on the object at all". 3. `Object.getPrototypeOf(value)` — if the data is up the chain, it was inherited, and no serializer will pick it up. The same reasoning applies to structural copying: anything that copies by enumerating own enumerable keys sees exactly the JSON set, so a copy made that way loses hidden and inherited state and freezes getter results into static values. If a value survives `Object.keys` but not your copy, you are looking at a different bug; if it fails both, it is this one. ## Getting the computed value in **`toJSON()`** is the language's designated hook: if the value being serialized has a callable `toJSON`, `JSON.stringify` calls it and serializes the return value instead of the object. It is a method on the class, so it inherits normally and every instance gets it. ```js class User { constructor(first, last) { this.first = first; this.last = last; } get fullName() { return `${this.first} ${this.last}`; } toJSON() { return { first: this.first, last: this.last, fullName: this.fullName }; } } JSON.stringify(new User('Ada', 'Lovelace')); // {"first":"Ada","last":"Lovelace","fullName":"Ada Lovelace"} ``` **Explicit mapping** to a plain DTO is the alternative, and often the better one at a service boundary: the wire shape is then written down in one place instead of being an accident of which fields happened to be assigned in a constructor. It also stops the reverse hazard — a field added to the class silently appearing in a public API response. **Making the value an own enumerable property** (compute it in the constructor, or define it with `enumerable: true`) works too, but you lose laziness and the value can go stale as the object mutates. Reach for it only when the derived value really is fixed at construction time.