JS Objects - Silent Mutation Broke User Sessions

Every real-world app you use — Instagram, Spotify, your bank's website — is built on data. A song has a title, an artist, a duration, and a genre. A user has a name, an email, and an age. If you tried to store all of that in separate, disconnected variables, your code would become impossible to manage before you even got started. JavaScript objects are the solution to this exact problem, and they're at the heart of almost everything you'll ever build on the web.

Before objects, imagine needing to track five pieces of information about 100 users. That's 500 variables. And when you pass data to a function, you'd need to pass all five separately every single time. Objects let you wrap all related data into one tidy package and hand it around your code as a single unit. They reflect how we naturally think about things in the real world — as entities with multiple characteristics.

By the end of this article you'll know how to create objects from scratch, read and update their properties using both dot notation and bracket notation, add and delete properties on the fly, loop over an object's contents, and understand the difference between primitive values and objects (a concept that trips up almost every beginner). You'll be ready to use objects confidently in real projects.

What Is a JavaScript Object and How Do You Create One?

An object in JavaScript is a collection of key-value pairs. The 'key' is the name of a piece of information (like 'firstName'), and the 'value' is the actual data stored under that name (like 'Sarah'). Together, each key-value pair is called a property.

The most common and readable way to create an object is with curly braces {}. This is called an object literal, and it's the go-to syntax for most JavaScript developers.

Inside the curly braces, you list your properties separated by commas. Each property is written as key: value. The key is usually written without quotes (unless it contains spaces or special characters), and the value can be any data type — a string, a number, a boolean, an array, or even another object.

Notice how grouping related data this way instantly makes your code more readable. Instead of six separate variables floating around, everything about a user lives in one place. That's the core win objects give you.

// Creating an object using object literal syntax — the most common approach
const userProfile = {
  firstName: 'Sarah',          // string property
  lastName: 'Okonkwo',         // string property
  age: 28,                     // number property
  isPremiumMember: true,       // boolean property
  favouriteGenres: ['jazz', 'lo-fi', 'classical'], // array as a property value
};

// Let's see the whole object printed to the console
console.log(userProfile);

// You can also create an empty object first, then add properties later
const emptyCart = {};
console.log(emptyCart); // prints an empty object — useful when you build data dynamically

Reading and Updating Object Properties — Dot vs Bracket Notation

Once you have an object, you need to get data out of it and put new data in. There are two ways to access a property: dot notation and bracket notation. Both do the same job — pick the right one for the situation.

Dot notation (object.propertyName) is cleaner and the one you'll use 90% of the time. Bracket notation (object['propertyName']) is more flexible — it lets you use a variable as the key, which is powerful when you don't know the property name until the code actually runs.

Updating a property is just as simple — you access it the same way and assign a new value with =. If the property doesn't exist yet, this same syntax creates it. There's no separate 'add property' command. Assignment does it all.

Deleting a property uses the delete keyword. It completely removes the key-value pair from the object, not just sets it to null. Use this with care — deleting properties can sometimes affect performance in JavaScript engines that optimise objects.

const bookListing = {
  title: 'The Pragmatic Programmer',
  author: 'David Thomas',
  pageCount: 352,
  isAvailable: true,
};

// --- DOT NOTATION --- clean and readable when you know the key name upfront
console.log(bookListing.title);       // reading the title property
console.log(bookListing.pageCount);   // reading the page count

// --- BRACKET NOTATION --- use this when the key is stored in a variable
const propertyToLookUp = 'author';    // we only know the key at runtime
console.log(bookListing[propertyToLookUp]); // bracket notation reads the variable's value as the key

// --- UPDATING a property --- same syntax, just assign a new value
bookListing.isAvailable = false;      // the book has been checked out
console.log(bookListing.isAvailable); // now false

// --- ADDING a new property --- just assign to a key that doesn't exist yet
bookListing.rating = 4.8;             // this property didn't exist before
console.log(bookListing.rating);      // JavaScript creates it on the spot

// --- DELETING a property ---
delete bookListing.pageCount;         // remove the pageCount property entirely
console.log(bookListing.pageCount);   // undefined — the property is gone

Looping Over an Object and Nesting Objects Inside Objects

Most real-world objects contain more properties than you'd want to type out one by one. JavaScript gives you a for...in loop specifically designed to iterate over every key in an object. On each iteration, the loop gives you the current key as a string, and you use bracket notation to get the value.

Objects can also be nested — meaning a property's value can itself be an object. This is how real data is structured. Think of a user profile that has an address: the address has a street, a city, and a postcode. It makes sense to group those three inside their own nested object rather than flattening everything into one level.

To access deeply nested properties, you just chain dot notation: user.address.city. Read it left to right — start at user, go into the address object, then grab the city property inside it.

Be careful with for...in — it can loop over inherited properties from the object's prototype chain in some situations. Using hasOwnProperty() is a defensive habit that guarantees you only touch properties you actually defined.

// A nested object — the address is an object living inside userAccount
const userAccount = {
  username: 'galaxy_dev',
  email: 'alex@example.com',
  followersCount: 1240,
  address: {                        // nested object starts here
    street: '42 Maple Avenue',
    city: 'Bristol',
    postcode: 'BS1 4AA',
  },
};

// Accessing a nested property — chain dot notation
console.log(userAccount.address.city);     // drill into address, then grab city
console.log(userAccount.address.postcode); // same idea, different property

console.log('--- Looping over top-level properties ---');

// for...in loops over every key in the object
for (const key in userAccount) {
  // hasOwnProperty guards against accidentally looping over inherited properties
  if (userAccount.hasOwnProperty(key)) {
    console.log(`${key}: ${userAccount[key]}`); // bracket notation uses the key variable
  }
}

// Object.keys() is a modern alternative — returns an array of own keys only
console.log('--- Using Object.keys() ---');
const keys = Object.keys(userAccount);
console.log(keys); // clean array of just the property names

Objects Are Reference Types — the Concept That Trips Everyone Up

Here's the thing that bites almost every beginner at some point: objects in JavaScript don't behave like numbers or strings when you copy or compare them.

With a number or string (primitive types), when you assign one variable to another, you get a true independent copy. Change one and the other is unaffected.

With objects, when you assign one variable to another, you don't copy the object — you copy the reference to it. Both variables now point at the exact same object in memory. So if you change a property through one variable, the other variable reflects that change too, because they're both looking at the same thing.

This also means two objects that look identical are NOT equal when you compare them with ===, because === checks whether they're the same reference (the same object in memory), not whether they have the same content.

To make a true shallow copy of an object, use the spread operator ({...originalObject}) or Object.assign(). For deeply nested objects, you need a deep clone, which JSON.parse(JSON.stringify(obj)) handles for simple cases.

// --- Demonstrating the reference behaviour ---

const originalOrder = {
  item: 'Mechanical Keyboard',
  quantity: 1,
  dispatched: false,
};

// This does NOT create a copy — both variables point at the same object
const orderReference = originalOrder;

orderReference.dispatched = true; // we change it through orderReference...
console.log(originalOrder.dispatched); // ...but originalOrder reflects the change too!

// --- Making a true shallow COPY using the spread operator ---
const orderCopy = { ...originalOrder }; // spread creates a new object with the same properties

orderCopy.quantity = 3;               // changing the copy
console.log(originalOrder.quantity);  // original is untouched — they're now separate
console.log(orderCopy.quantity);      // the copy has the updated value

// --- Equality check on objects ---
const cartA = { product: 'Notebook', price: 4.99 };
const cartB = { product: 'Notebook', price: 4.99 };

console.log(cartA === cartB); // false — same content, but different objects in memory
console.log(cartA === cartA); // true — same reference, pointing at the exact same object

Object Spreading and Merging – Combining Objects Safely

When you need to combine multiple objects into one, or create a new object from an existing one with modifications, the spread operator (...) is your best friend. Introduced in ES6, spread allows you to copy properties from one object into another elegantly.

For merging two objects, you can do: const merged = { ...objA, ...objB }. If both have the same property, the later source overwrites the earlier one. This is a shallow merge — nested objects are still shared references.

Object.assign() is the older alternative and does the same shallow merge. The spread syntax is generally preferred for readability.

Be careful with deep merging. A simple spread will not clone nested objects; they remain references. For a deep merge, you need to recursively merge or use a utility like Lodash's _.merge() or structuredClone() combined with spread.

// Shallow merge using spread
const defaults = { theme: 'light', notifications: true };
const userPrefs = { theme: 'dark', fontSize: 14 };
const config = { ...defaults, ...userPrefs };
console.log(config);
// { theme: 'dark', notifications: true, fontSize: 14 }

// Object.assign alternative
const config2 = Object.assign({}, defaults, userPrefs);

// Shallow copy and modify a property
const original = { a: 1, b: { c: 2 } };
const copy = { ...original, b: { ...original.b } }; // manually deep clone nested

// Deep merge using JSON (simple case, no functions/dates)
const deepCopy = JSON.parse(JSON.stringify(original));

Property Existence Checks: The Difference Between `in`, `hasOwnProperty`, and Optional Chaining

You'd think checking if a property exists is trivial. Then you ship a bug where undefined meant "property missing" but actually meant "value was legitimately undefined." Welcome to the real world.

Here's the deal: obj.prop === undefined fails when the property exists but holds undefined deliberately. 'prop' in obj checks the entire prototype chain, which can inherit properties from Object.prototype like toString. That's almost never what you want.

Object.hasOwn(obj, 'prop') is the modern fix. It checks own properties only, no prototype noise. It's faster than hasOwnProperty.call() and works even if someone overrides obj.hasOwnProperty (yes, I've seen it in legacy code).

Optional chaining (obj?.deep?.nested) doesn't check existence — it short-circuits on null or undefined. Use it for safe access, not existence checks. Mix the two and you'll suppress real bugs.

// io.thecodeforge — javascript tutorial

const config = {
  timeout: 0,
  retries: undefined,
  host: null,
};

// Trap: 0 is falsy, but property IS there
if (!config.timeout) {
  console.log('Trap: timeout is falsy, assuming missing');
}

// Using hasOwn to distinguish missing from falsy
console.log('timeout exists:', Object.hasOwn(config, 'timeout')); // true
console.log('retries exists:', Object.hasOwn(config, 'retries')); // true
console.log('missingProp exists:', Object.hasOwn(config, 'missingProp')); // false

// in operator includes prototype chain
console.log('toString in config:', 'toString' in config); // true — inherited
console.log('toString own:', Object.hasOwn(config, 'toString')); // false — safe

Deleting Properties: The `delete` Operator Isn't Free — And What It Can't Touch

Deleting a property sounds simple: delete obj.prop. But this operator changes the object's hidden class under the hood, forcing V8 to deopt and rebuild the object shape. Do this in a hot loop and watch your frame budget evaporate.

Worse: delete can't remove non-configurable properties. Try deleting Math.PI and you'll get a silent false. In strict mode, it throws. If you're deleting array elements with delete, you leave a hole — arr.length doesn't shrink. Use splice() or filter() instead.

The practical fix: if performance matters, set the property to undefined and add an existence guard. This preserves object shape. For dynamic cleanup, consider Map — Map.delete() is O(1) with no hidden-class penalties.

Only use delete when you genuinely need to drop the key from enumeration or serialization. Otherwise, undefined is your faster, safer alternative.

// io.thecodeforge — javascript tutorial

'use strict';

const userCache = {};
const userId = 'u42';
userCache[userId] = { name: 'Alice', session: 'abc123' };

// Hot path — processing 10k requests per second
for (let i = 0; i < 1000; i++) {
  // Don't do this: triggers hidden-class change
  // delete userCache[userId];
  
  // Do this instead: preserves object shape
  userCache[userId] = undefined;
}

// Checking existence properly
if (Object.hasOwn(userCache, userId) && userCache[userId] !== undefined) {
  console.log('User found:', userCache[userId]);
} else {
  console.log('User missing or expired');
}

// Non-configurable property trap
const config = {};
Object.defineProperty(config, 'apiKey', { value: 'secret', configurable: false });

console.log('Can delete apiKey?', delete config.apiKey); // false — silent failure
console.log('apiKey still exists:', Object.hasOwn(config, 'apiKey')); // true

Object.keys vs Object.values vs Object.entries — Pick the Right Weapon for the Job

New devs treat these three as interchangeable. They're not. Each one solves a different problem. Use Object.keys() when you need to do something with the keys themselves — like checking for a property, or hashing by key name. Use Object.values() when you only care about the data payload, like summing numbers or filtering a list. Use Object.entries() when you need both, like building a new object from a transform.

Performance? In modern V8, Object.keys() is micro-optimized. It's about 2x faster than Object.entries() for small objects because it avoids allocating key-value pairs. But don't micro-optimize prematurely — pick for readability first.

The real trap: for...in loops over enumerable properties, including inherited ones. The Object.* static methods only return own enumerable properties. Use them. Always. Unless you have a specific reason to walk the prototype chain (you probably don't).

Pro tip: destructure in for...of with Object.entries() for clean key-value iteration without the for...in headache.

// io.thecodeforge — javascript tutorial

const scoreboard = {
  alice: 250,
  bob: 180,
  charlie: 310,
};

// Need to sum scores? Use values.
const totalScore = Object.values(scoreboard).reduce((sum, score) => sum + score, 0);
console.log('Total score:', totalScore);

// Need to build a map of name -> category? Use entries.
const ranked = Object.entries(scoreboard)
  .sort(([, a], [, b]) => b - a)
  .map(([name, score], index) => `${index + 1}. ${name} — ${score}`);

console.log('Rankings:', ranked);

// Need to check if a player exists? Use keys.
const target = 'bob';
if (Object.keys(scoreboard).includes(target)) {
  console.log(`${target} is in the board`);
}

// Trap: for...in leaks prototype
Array.prototype.foo = 'bad';
const arr = [1, 2, 3];
for (const key in arr) {
  console.log('for...in sees:', key); // logs 'foo' too
}
// Safe: Object.keys(arr) only returns [0, 1, 2]
console.log('Object.keys:', Object.keys(arr));

OOP Pillars Through JavaScript Objects — Abstraction, Inheritance, Polymorphism, Encapsulation

Most devs think OOP is only for classes. That's marketing fluff. JavaScript objects are the original OO citizens, and they nail all four pillars without a single class keyword. Why? Because you need code that hides complexity (abstraction), owns its data (encapsulation), reuses structure (inheritance), and bends behavior at runtime (polymorphism). Without these, your objects become leaky bags of state.

Encapsulation happens by keeping data behind closure walls or private # fields. Abstraction means exposing a clean method like .pay() while the tax logic stays hidden. Inheritance works through prototypes — Object.create() links objects cheaply. Polymorphism? Objects override inherited methods on the fly. One speak() method, ten different animals, zero if-else chains.

Stop treating objects as dumb containers. Apply the pillars and watch your code become self-documenting, testable, and resistant to spaghetti refactors.

// io.thecodeforge — javascript tutorial

// Encapsulation + Abstraction via closure
function createBankAccount(owner, initialBalance) {
  let balance = initialBalance; // private
  return {
    owner,
    deposit(amount) { if (amount > 0) balance += amount; },
    getBalance() { return balance; } // abstraction
  };
}

// Inheritance via prototype
const animal = { speak() { return '...'; } };
const dog = Object.create(animal);
dog.speak = function() { return 'Woof'; }; // polymorphism

const acc = createBankAccount('Zara', 1000);
acc.deposit(500);
console.log(acc.getBalance()); // 1500
console.log(dog.speak()); // Woof