A Deep Dive Into JavaScript Objects
Explore the finer details of objects in JavaScript
JavaScript objects are fundamental. Taking the time to dig deeper into them will result in cleaner and more performant code.
Note: This article assumes that you know the basics of objects. If you want a quick refresher on objects, check out The Chronicles of JavaScript Objects by Arfat Salman.
Let’s get cracking!
Read-Only Objects
Suppose we want to create an enum to represent the cardinal directions:
However, existing properties/keys can be altered and new properties can be added into DIRECTIONS. This can be hazardous in larger code bases since the chances of accidentally editing enums/read-only objects will be greater.
DIRECTIONS.NORTH = "south"; //nothing stopping this from happeningEnter Object.freeze.
Object.freeze(DIRECTIONS);Object.freeze gets rid of the ability to add new properties and edit/remove existing properties.
Object.freeze(DIRECTIONS);/*The below either fail silently or a TypeError will be thrown*/
DIRECTIONS.NORTH = "south";
DIRECTIONS.UP = "up";
del DIRECTIONS.SOUTH;
Object.freeze also restricts the capability to alter the property descriptors of an object’s individual properties. A property descriptor is like the “settings” of a property. Here are the four fields it consists of:
value: The actual of the property.enumerable: Determines whether a property will appear when iterating/enumerating over the properties of an object. Ifenumerableistruefor a property, it will show up when we iterate over an object withfor _ inand it will be included inObject.keys().configurable: Determines whether a property can be deleted from an object or if an object’s property descriptor can be changed.writable: Determines whether a property’s value can be changed through assignment.
const obj = {'a': 1, 'b':2};
console.log(Object.getOwnPropertyDescriptors(obj));
/*
Here is the output of the property descriptors of obj:
{
a: {value: 1, writable: true, enumerable: true, configurable: true},
b: {value: 2, writable: true, enumerable: true, configurable: true}
}
*/Object.freeze will keep enumerable as is but will setconfigurable and writable to false for the properties in an object. As a result, we can no longer edit the property descriptor (we can no longer change writable, enumerable, or configurable) and can no longer alter the value of the property.
Caveat: Object.freeze only puts these restrictions on top-level properties.
const o = {a: 0, b: {c: 5}};
Object.freeze(o);o.b.c = 10; // this is valid
These mentioned restrictions will hold true for properties a and b, but not for property c. We can edit the value of c even after we freeze the object.
You may have to recursively call Object.freeze on child objects to ensure the entire object is frozen.
Shallow vs. Deep
Unlike primitives, JavaScript objects are passed around by reference, where a reference is a pointer to where the object “resides” in memory.
const myPet = {
name: "Doggie",
type: "Dog"
}myPet stores the reference to the object it is assigned to — not the object itself.
const yourPet = myPet;
yourPet.name = "Cattie";
console.log(myPet);/*
Here is the output of myPet:
{ name: 'Cattie', type: 'Dog' }
*/
Assignment in this fashion will copy the reference myPet stores to yourPet. As a result, yourPet and myPet still reference the same object.
Basically, if I edit a property in yourPet, that edit will be reflected in myPet since they are still referencing the same object.
When we have two variables storing references to the same object, we can call them shallow copies.
As seen above, one way of creating a shallow copy is through assignment.
const obj = {"a": 0};
const anotherObj = obj; // shallow copyWe can test for shallow equality by using Object.is. Object.is tests if both variables have a reference to the same object.
const obj = {"a": 0};
const anotherObj = obj;
Object.is(obj, anotherObj); // returns trueBut wait! Why does the following return false?
const histo1 = {"a": 0};
const histo2 = {"a": 0};
Object.is(histo1, histo2); // returns falseThough the contents of the objects of histo1 and histo2 are the same, this doesn’t mean histo1 and histo2 refer to the same object in memory. As a result, histo1 and histo2 are not shallow copies since their references point to different objects that happen to have the same contents.
histo1 and histo2 are deep copies.
There are a couple of options for creating deep copies.
Deep copy with JSON
const me = {"name": "Ramki"};
const you = JSON.parse(JSON.stringify(me));The idea is to convert the object to a string using JSON.stringify and then parse the string with JSON.parse to retrieve the encoded object. The main limitation is that objects with properties that are functions will not be copied properly, as JSON.stringify cannot encode functions (JSON.Stringify).
Deep copy with Lodash
We can import cloneDeep from lodash. It’s a method that recursively clones the properties of a passed-in object. The returned object will be a deep copy. The main drawback is that we must install an external library, adding to the total size of the application, in order to create a deep copy.
In cases where your object’s values are JSON-compatible, it might be simpler to use the JSON.stringify approach. Otherwise, lodash.cloneDeep is the best approach.
Objects As Primitives
Though the variables bound to an object store its reference, it is still possible to get primitive values of objects by overridingObject.prototype.valueOf.
Object.prototype.valueOf is a function that returns the primitive value of an object. By default, it returns the object itself, but it can be overridden to return something else.
const result = 1 + new Number(14);
console.log(result);// result: 15
Number is a wrapper object of numbers. Interestingly, when we add a primitive (1) to an object (new Number(14)), we still end up getting the correct result of 15.
When we add 1 to new Number(14), JavaScript will auto-convert new Number(14) to its primitive value, 14. This primitive value is retrieved from Number.prototype.valueOf(), which is overridden to provide the actual numerical value that the Number object stores.
Let’s look at another example: Suppose we have a StringBuilder object to efficiently concatenate strings.
Suppose we want to use it the following manner:
const builder = new StringBuilder();
builder.add("B");
builder.add("C");const result = "A" + builder;
//result: want it to be "ABC" but is "A[object Object]"
In order to have result equal to “ABC”, we can override StringBuilder.prototype.valueOf to provide the concatenation of builder.strings.
StringBuilder.prototype.valueOf = function() {
return this.concat();
}Whenever a StringBuilder object is converted into a primitive, the primitive will be the concatenation of all the strings we added into the object.
We can override Object.prototype.valueOf to provide custom primitive values for objects when they are converted into primitives.
Objects vs. Maps
Although JavaScript provides a Map class, many frequently use objects to map keys and values.
twoSumCount using the Map data structure:
Though their usage looks similar, there are a few differences.
Keys
The key of an object can only either be a string or a Symbol.
Wait a second. Didn’t we just use numbers as keys in twoSumCount?
const obj = {};
obj[1] = "Something";
console.log(Object.keys(obj));//output: ["1"]
The integer keys we are using will get auto-converted into strings. This can be problematic if we want to use other objects as keys.
obj = {};
obj[{}] = {};
console.log(Object.keys(obj));//output: ['[object Object]']
However, with Map, the key types will not be restricted to strings or Symbol. We can have objects, functions, numbers, etc. as keys.
In addition, objects can have default keys upon instantiation.
const map = {};
console.log(map['toString']); //output: [Function: toString]
Even though our obj is empty, it still inherits from Object.prototype. As a result, keys such as toString and valueOf exist in obj at initialization. In order to remove these default keys, it is best to use objects that don’t inherit from anything.
const map = Object.create(null);
console.log(map['toString']);//output: undefined
Using Object.create(null) ensures that there aren’t keys from prototypical inheritance in the object at initialization, reducing the chance of keys colliding.
Performance
According to the Mozilla docs, Map is said to perform better than objects in scenarios where frequent additions and removals occur. Despite that, I decided to performance-test both objects and maps.
The performance test is split into four parts: adding, retrieving, enumerating over, and deleting keys. The number of keys will be 1 million. The REPL link to the code is below:
Surprisingly, I found that the performance tests favored the object over the map when run in the REPL.
Node Version: 12.22.1Map: Adding Keys: 676.662ms
Map: Getting Keys: 437.161ms
Map: Enumeration: 4580.738ms
Map: Deleting Keys: 699.071ms
=============================
Object: Adding Keys: 135.423ms
Object: Getting Keys: 92.645ms
Object: Enumeration: 4123.763ms
Object: Deleting Keys: 266.606ms
Here are the results on Node version 14.16.0 on a Razor Stealth computer:
Node Version: 14.16.0Map: Adding Keys: 163.153ms
Map: Getting Keys: 130.77ms
Map: Enumeration: 53.908ms
Map: Deleting Keys: 212.994ms
=============================
Object: Adding Keys: 28.134ms
Object: Getting Keys: 9.936ms
Object: Enumeration: 157.712ms
Object: Deleting Keys: 61.353ms
Object seems to have Map beat in all areas other than enumeration, according to my benchmarks. Based on this, using Map when storing non-string keys and using objects otherwise would be the best approach.
I find it odd that a map was slower than an object in the performance tests. Please let me know if you have any data that suggests otherwise.
Conclusion
I hope you learned something new about JavaScript objects from this article.
Thank you for reading!
