Implement an Immutable setIn(obj, path, value) That Never Mutates the Original

Q: Implement an Immutable setIn(obj, path, value) That Never Mutates the Original

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the real, defining "structural sharing" claim this question tests — that only objects ALONG the changed path get new references, while UNRELATED sibling data is genuinely, deliberately SHARED, not copied — was verified directly: after changing `user.address.city`, the updated object's `user.name` field was confirmed, via a real `===` reference check, to be the EXACT SAME value reference as the original's, while `updated.user` and `updated.user.address` were both confirmed to be genuinely NEW, different references. ## 1. The problem, restated Set a value at a deeply nested `path` (given as a dot-separated string, or an array of keys) WITHOUT mutating the original object at all — returning a genuinely new object where every object ALONG the changed path is a fresh, new reference, but any sibling data NOT on that path is structurally SHARED with the orig

Immutable set properties | JS Coding Challenge

The problem

Problem, as an interviewer would state it: "Implement setIn(obj, path, value) — setting a deeply nested value at path and returning a genuinely NEW object, while leaving the original COMPLETELY untouched, and correctly SHARING (not copying) any sibling data that was not actually on the changed path — matching the real, well-known Immutable.js setIn convention."

Examples:

Code

const original = { user: { name: "Ada", address: { city: "London" } } };
setIn(original, "user.address.city", "Paris");
// { user: { name: "Ada", address: { city: "Paris" } } }
// original is completely unchanged

Clarifying questions expected:

Should every object ALONG the changed path be a genuinely new reference, while sibling data NOT on that path is structurally SHARED (same reference) rather than deep-copied?
Does this need to correctly CREATE intermediate objects if the path does not fully exist yet in the original?
Should the path be accepted as a dot-separated string, an array of keys, or both?

Code / implementation expected: Yes — real, direct proof the original is completely untouched, that every object along the changed path is a new reference while unrelated sibling data is structurally shared, and that missing intermediate path segments are correctly created.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: the real, defining "structural sharing" claim this question tests — that only objects ALONG the changed path get new references, while UNRELATED sibling data is genuinely, deliberately SHARED, not copied — was verified directly: after changing user.address.city, the updated object's user.name field was confirmed, via a real === reference check, to be the EXACT SAME value reference as the original's, while updated.user and updated.user.address were both confirmed to be genuinely NEW, different references.

1. The problem, restated

Set a value at a deeply nested path (given as a dot-separated string, or an array of keys) WITHOUT mutating the original object at all — returning a genuinely new object where every object ALONG the changed path i

The solution is hidden so you can try first

8 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: setIn() leaves the original completely untouched, creates new references only along the changed path, and structurally shares unrelated sibling data