Open rauschma opened 6 years ago
25.2.6. Object literals: methods The following code shows how to create the method .describe() via an object literal:
const jane = {
first: 'Jane', // data property
says(text) { // method
return `${this.first} says “${text}”`; // (A)
}, // comma as separator (optional at end)
};
assert.equal(jane.says('hello'), 'Jane says “hello”');
During the method call jane.says('hello'), jane is called the receiver of the method call and assigned to the special variable this. That enables method .says() to access the sibling property .first in line A.
At the first line, a method .describe() is mentioned but never seen after that.
@navigalia I went back and forth on this. But the simpler version is probably better. It’ll be in the next release.
@VernonHawk Good catch! It’ll be fixed in the next release.
25.5.1.1 Handling defaults via nullish coalescing
Description mentions '(no street)'
value, but code use '(no name)'
.
25.6.9.4 A polyfill for Object.fromEntries()
The npm package object.fromentries is a polyfill for Object.entries()
Object.entries()
-> Object.fromEntries()
?
28.5.6 states: Object.values()
lists the values of all enumerable properties of an object
This follows discussion of how property keys can be either strings or symbols, and either enumerable or not.
So the following result was not expected:
const enumerableSymbolKey = Symbol('enumerableSymbolKey');
const obj = {
enumerableStringKey: 1,
[enumerableSymbolKey]: 2,
}
console.log(Object.values(obj));
// expected output: Array [1, 2]
// actual output : Array [1]
28.5.7 is similar - Object.entries()
only seems to list pairs for enumerable property names, not the enumerable property symbols.
Clearly I have misunderstood something, but I am not clear what I have misunderstood.
Update: I have the 2019 print book but the 2020 ebook - the issue raised in the comment above seems to persist in 28.6.6 and 28.6.7 of the newer version.
@wgmyers Good catch! Object.keys()
, Object.values()
and Object.entries()
ignore properties whose keys are symbols. The next edition will explain this properly.
@vsemozhetbyt
Object.fromEntries()
is now, I’m not mentioning the polyfill anymore.'(no name)'
in descriptionIn 28.4.5.1, elem.addEventListener('click', this.handleClick.bind(this));
is a bit of an anti-pattern since there would be no way to remove that event listener afterwards. I think it's necessary to mention that since consecutive calls to a.b.bind(a)
resolve to a different function object, it's necessary to store the result somewhere unless the caller is certain that there's absolutely no need to call removeEventListener
later. I've seen people getting this wrong on several occasions with consequences being very easy to observe.
@eeror Good point. The next release will mention this.
pretty great chapter. I previously just care about OOP , classes, and connections btw classes. that's how OOAD and OOP works. but JS doesn't , the author talked a lot about an object. actually JS syntax makes me mad(I am programmer for many years). but reading this book is charming, very clear. appreciate it
Hello!
There it a callout about missing the deep copy functionality in JS.
JavaScript doesn’t have built-in support for deep copying Deep copies of objects (where all levels are copied) are notoriously difficult to do generically. Therefore, JavaScript does not have a built-in operation for them (for now). If we need such an operation, we have to implement it ourselves.
Probably, this is outdated info after the structuredClone() has appeared.
So I suggest to link your [other post ](https://2ality.com/2022/01/structured-clone.html#copying-objects-deeply-via-structuredclone())about structuredClone() instead of this warn.
Very didactic implementation of
Object.fromEntries()
.Why not:
instead:
Thanks.